AXForum  
Вернуться   AXForum > Рынок > Microsoft и системы Microsoft Dynamics
All
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск Все разделы прочитаны

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 03.07.2007, 20:00   #1  
asdf_imported is offline
asdf_imported
Участник
 
2 / 10 (1) +
Регистрация: 03.07.2007
Специалисты “Вест Концепт” завершили создание add-on модуля предварительного проведения документов

Модуль, выполненный внутри системы Microsoft Dynamics™ NAV, расширяет ее штатный функционал и великолепно решает практически неразрешимую ранее проблему, возникающую при необходимости просмотра результирующих бухгалтерских счетов.

Стандартно при работе в Microsoft Dynamics™ NAV пользователю может быть не понятно какие именно возникнут проводки в результате учета документа и чтобы их посмотреть непосредственно до учета необходимо открыть десятки групп, что зачастую является достаточно трудоемкой процедурой и отнимает много времени. При этом единственным способом “исправления” некорректных учтенных операций является сторнирование.

Модуль “Трассировщик” позволяет увидеть результат, который формирует документ в книге операций без его реального учета.

Модуль предназначен для введения в Navision возможности предварительного проведения документов и строк журналов, при этом данную процедуру можно проводить многократно и по любым учетным книгам операций.

Действие трассировщика основано на перехватывании момента внесения проводок в книгу операций, что дает возможность бухгалтеру оценить какие проводки создаст система, проведя полноценную процедуру учета за исключением самого последнего действия.

Перед началом работы с трассировщиком необходимо сделать несложные настройки по пользователям, для которых данный модуль будет задействован. При включенном модуле во время учета операций (кнопка “Учет”) появляется окно трассировщика и после определения отображаемых проводок у пользователя есть возможность выбрать следующие дальнейшие действия:
- трассировка – вывод формируемых проводок по учетным таблицам, отмеченным галочками (без реального учета);
- учет – непосредственно учет, без отображения формируемых проводок;
- отмена – отказ от дальнейшей работы по учету.

Данная функциональность предоставляет возможность как конечным пользователям отслеживать возможные ошибки, позволяя в результате уменьшить количество сторно-операций, так и консультантам при внедрении производить настройку блоков системы не вводя большое количество повторяющихся документов и данных, а учитывая один и тот же документ.

Таким образом, проводя документы предварительно, существует возможность тестового учета, коррекции данных вплоть до полной уверенности в правильности результата, а также прогнозирование состояния предприятия.

Модуль “Трассировщик” уже внедрен в филиале шведско-финского холдинга Kalmar Industries, а также в гостиничных комплексах “Бородино” и “Милан”. При этом специалисты “Вест Концепт” уверены, что данное решение может стать полезным и для других компаний-пользователей системы Microsoft Navision.
Старый 03.07.2007, 21:36   #2  
Sitizen is offline
Sitizen
Участник
Аватар для Sitizen
 
305 / 10 (1) +
Регистрация: 10.01.2006
Эта "неразрешимая проблема" уже три года назад была разрешена.

А предосмотр проводок в IE выводится?
Старый 04.07.2007, 09:49   #3  
IGG is offline
IGG
Участник
 
665 / 29 (2) +++
Регистрация: 24.08.2005
Адрес: СПб/Москва
Наверное метода простая - перед COMMIT в CU12 выводится диалог? А потом либо COMMIT либо откат?
Старый 04.07.2007, 09:49   #4  
rmv is offline
rmv
Участник
 
481 / 11 (1) +
Регистрация: 15.02.2005
).
Порадовала фраза - "а также прогнозирование состояния предприятия".
Старый 04.07.2007, 09:55   #5  
rmv is offline
rmv
Участник
 
481 / 11 (1) +
Регистрация: 15.02.2005
IGHG
здесь обсуждалось:
http://forum.mazzy.ru/index.php?showtopic=...t=0&p=17857

Написать обертку для учетных кодеюнитов
Отломать где нужно коммиты.
Работы на 2-3 дня максимум.
Старый 04.07.2007, 10:19   #6  
IGG is offline
IGG
Участник
 
665 / 29 (2) +++
Регистрация: 24.08.2005
Адрес: СПб/Москва
Цитата:
Сообщение от rmv Посмотреть сообщение
IGHG
здесь обсуждалось:
http://forum.mazzy.ru/index.php?showtopic=...t=0&p=17857

Написать обертку для учетных кодеюнитов
Отломать где нужно коммиты.
Работы на 2-3 дня максимум.
Ага. И я там засветился тоже в том топике. У меня тогда на прошлой работе бухгалтер требовал видеть все проводки в паре Дебет-Кредит. Ей простой список записей книги финопераций не подходил. "Хочу чтоб все было как в 1С". :-)
Старый 04.07.2007, 10:24   #7  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от asdf Посмотреть сообщение
Модуль, выполненный внутри системы Microsoft Dynamics™ NAV, расширяет ее штатный функционал и великолепно решает практически неразрешимую ранее проблему, возникающую при необходимости просмотра результирующих бухгалтерских счетов.
Жалко, что не указали, какие побочные эффекты появляются при таком разрешении этой "неразрешимой проблемы".

Цитата:
Сообщение от asdf Посмотреть сообщение
Стандартно при работе в Microsoft Dynamics™ NAV пользователю может быть не понятно какие именно возникнут проводки в результате учета документа и чтобы их посмотреть непосредственно до учета необходимо открыть десятки групп, что зачастую является достаточно трудоемкой процедурой и отнимает много времени. При этом единственным способом “исправления” некорректных учтенных операций является сторнирование.
Жалко, что не объяснили почему "стандартно" заложено именно такое поведение
Возникает ощущение, что стандартный функционал писали какие-то недотыкомки, которые не могут нормально, по-пацански расширить функционал.

Цитата:
Сообщение от asdf Посмотреть сообщение
Модуль “Трассировщик” позволяет увидеть результат, который формирует документ в книге операций без его реального учета.
И проанализировать остаток на счетах, наверное

Цитата:
Сообщение от asdf Посмотреть сообщение
Действие трассировщика основано на перехватывании момента внесения проводок в книгу операций, что дает возможность бухгалтеру оценить какие проводки создаст система, проведя полноценную процедуру учета за исключением самого последнего действия.
Угу. Вот так одним махом и перечеркнули расширили функционал.
Теперь все предприятие снова стоит и ждет одобрения бухгалтера.
Раньше то, ужас то какой, проводки делались без одобрения бухгалтера. Как так можно?

Цитата:
Сообщение от asdf Посмотреть сообщение
Перед началом работы с трассировщиком необходимо сделать несложные настройки по пользователям, для которых данный модуль будет задействован.
О! А такого действительно ни у кого не было. По крайней мере никто об этом не говорил.

Цитата:
Сообщение от asdf Посмотреть сообщение
При включенном модуле во время учета операций (кнопка “Учет”) появляется окно трассировщика и после определения отображаемых проводок у пользователя есть возможность выбрать следующие дальнейшие действия:
- трассировка – вывод формируемых проводок по учетным таблицам, отмеченным галочками (без реального учета);
- учет – непосредственно учет, без отображения формируемых проводок;
- отмена – отказ от дальнейшей работы по учету.
Интересно, у кого такое окно появляется?
У бухгалтера или у того пользователя, который нажал на кнопку Учет?

Цитата:
Сообщение от asdf Посмотреть сообщение
Данная функциональность предоставляет возможность как конечным пользователям отслеживать возможные ошибки, позволяя в результате уменьшить количество сторно-операций, так и консультантам при внедрении производить настройку блоков системы не вводя большое количество повторяющихся документов и данных, а учитывая один и тот же документ.

В россии очень странно вывернутая логика: Первичные данные не проверяются, зато проверяются бухгалтерские проводки.
Проверять надо первичные данные.
Если первичные данные правильны и правильно выполнена настройка реконсиляции, то бухгалтерские проводки тоже будут правильны.

Цитата:
Сообщение от asdf Посмотреть сообщение
Таким образом, проводя документы предварительно, существует возможность тестового учета, коррекции данных вплоть до полной уверенности в правильности результата, а также прогнозирование состояния предприятия.
Угу. Какая разница что там понавведено?
Зато бухгалтерские проводки правильные.
Ну, если бухгалтерские проводки и есть результат, то почему бы и нет?
__________________
полезное на axForum, github, vk, coub.
Старый 04.07.2007, 10:34   #8  
IGG is offline
IGG
Участник
 
665 / 29 (2) +++
Регистрация: 24.08.2005
Адрес: СПб/Москва
Лично я посоветовал немножко думать головой что вводишь. Но конечно объявление падает на благодатную почву. Потому что в массе своей бухгалтеры пришли из 1С и все хотят чтобы ERP была как 1С с чистого листа: захотел - удалил что хочешь, захотел, отменил...
А поскольку за удаление и сторнирование в нормальных фирмах ругают и даже наказывают то им нужно нечто, чтобы просмотреть в удобном для них виде. Я вышел из положения тем что написал некий отчет где прописал дебет-кредит, правда в самом простом выражении, всего я не охватил бы. Перехватывать COMMIT - не подвиснет ли база на учете?
Старый 04.07.2007, 10:39   #9  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от IGHG Посмотреть сообщение
бухгалтеры ... все хотят чтобы...
Я согласен, что "бухгалтеры хотят".
И категорически не согласен, что "все хотят". Нет, далеко не всех хотят, чтобы "удалил что хочешь, отменил что хочешь".
__________________
полезное на axForum, github, vk, coub.
Старый 04.07.2007, 10:46   #10  
IGG is offline
IGG
Участник
 
665 / 29 (2) +++
Регистрация: 24.08.2005
Адрес: СПб/Москва
Цитата:
Сообщение от mazzy Посмотреть сообщение
Я согласен, что "бухгалтеры хотят".
И категорически не согласен, что "все хотят". Нет, далеко не всех хотят, чтобы "удалил что хочешь, отменил что хочешь".
Это чисто бухгалтерский эгоизм. В большую корпорацию где стоит ERP система бухгалтеров берут зачастую из маленьких компаний где они были и цари и боги, финдиректора нету, полная свобода действий. Вот и получается некий групповой эгоизм, истерики. И не врубиться им что данные учета сразу видны всем - от директора до товароведа.
Старый 04.07.2007, 15:35   #11  
artkashin is offline
artkashin
Участник
MCBMSS
 
519 / 18 (2) ++
Регистрация: 06.12.2006
По-моему, действительно полезный функционал, позволяющий избежать множества ошибок. Ведь проверить результат, всегда легче, чем его предсказать. Далеко не всегда, при выверке первичной информации, можно найти ошибку. Ведь есть же Тестовый отчет, и почему никто не ругает его за то, что он мало что тестит? Другое дело, что при реализации этого функционала, возможно, пришлось немало "полазить" в учетных кодюнитах. Но за это надо не разработчика функционала винить, а Микрософт, которая не предоставила в системе с отсутствующей системой удаления документов толковых проверок ДЛЯ ПОЛЬЗОВАТЕЛЯ, а что же он учитывает.
Старый 04.07.2007, 17:27   #12  
artkashin is offline
artkashin
Участник
MCBMSS
 
519 / 18 (2) ++
Регистрация: 06.12.2006
И еще. Часто бывает так, что в документе 100 строк, в каждой строке 5-6 измерений (это еще мягкий пример). Для каждой строки свои настройки учета, как выверить такой документ? И сколько надо людей принять на работу на должность выверщика, если таких документов сотни в день? Тем более, станьте хоть раз на сторону пользователя, это же не демон, а человек, а он, ошибается, если плохо понимает почему так делать, и что он получит. Мне, например, становится страшно, если бы мне пришлось быть "простым" менеджером по продажам или бухгалтером, сидящем на выписке документов, ведь всегда есть нестандартные ситуации, в которых приходится менять автоматически подставляемые системой значения, а проверить, все ли я правильно заполнил не представляется возможным, только как учесть и проверить. Или это не так?
Старый 04.07.2007, 17:36   #13  
artkashin is offline
artkashin
Участник
MCBMSS
 
519 / 18 (2) ++
Регистрация: 06.12.2006
Цитата:
Сообщение от mazzy Посмотреть сообщение
Цитата:
Стандартно при работе в Microsoft Dynamics™ NAV пользователю может быть не понятно какие именно возникнут проводки в результате учета документа и чтобы их посмотреть непосредственно до учета необходимо открыть десятки групп, что зачастую является достаточно трудоемкой процедурой и отнимает много времени. При этом единственным способом “исправления” некорректных учтенных операций является сторнирование.
Жалко, что не объяснили почему "стандартно" заложено именно такое поведение
Возникает ощущение, что стандартный функционал писали какие-то недотыкомки, которые не могут нормально, по-пацански расширить функционал.
У меня возникает. Может мне кто-то объяснит, почему "стандартно" заложено именно такое поведение?
Старый 04.07.2007, 18:36   #14  
rmv is offline
rmv
Участник
 
481 / 11 (1) +
Регистрация: 15.02.2005
Цитата:
У меня возникает. Может мне кто-то объяснит, почему "стандартно" заложено именно такое поведение?
Предполагаю по причине того, что большинство пользователей системы (операторы call-центра, менеджеры по продажам, складские работники.. список можно продолжить) понятия не имеют о принципах бухучета и тем более учетной политике организации.
Честно гря я слабо себе представляю оператора склада, который выбирает Общую Бизнес Группу во Акте Списания, запускает тестовый учет и анализирует проводки.
Можно конечно на каждый участок посадить по буху... но зачем когда проще настроить базу и написать должностные инструкции?
Старый 05.07.2007, 01:31   #15  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
абсолютно согласен с rmv.
__________________
полезное на axForum, github, vk, coub.
Старый 05.07.2007, 10:16   #16  
artkashin is offline
artkashin
Участник
MCBMSS
 
519 / 18 (2) ++
Регистрация: 06.12.2006
Цитата:
Сообщение от rmv Посмотреть сообщение
Предполагаю по причине того, что большинство пользователей системы (операторы call-центра, менеджеры по продажам, складские работники.. список можно продолжить) понятия не имеют о принципах бухучета и тем более учетной политике организации.
Да, согласен, но именно большинство этих пользователей ведут справочники, а не бухгалтерия. Менеджеры ведут клиентов(часто именно они настраивают в карточке общие и ндс бизнес группы, так как у них написано в инструкции, не понимая, а зачем эта настройка нужна вообще), на производстве заводят товары, опять же не бухгалтеры! Можно сколь угодно перекладывать работу на того, кто в курсе об учетной политике и принципах бухучета, но это не решает главного вопроса УЧИТЫВАЮЩЕГО пользователя - как проверить, введенная информация правильна или нет? Ведь в любом случае, учет будет возможен! В тех же инструкциях описано, что ПОСЛЕ учета, вы можете просмотреть, какие операции УЖЕ произвела программа используя функции навигатора. Отличная возможность получить нагоняй от руководства.
Цитата:
Сообщение от rmv Посмотреть сообщение
Честно гря я слабо себе представляю оператора склада, который выбирает Общую Бизнес Группу во Акте Списания, запускает тестовый учет и анализирует проводки.
Можно конечно на каждый участок посадить по буху... но зачем когда проще настроить базу и написать должностные инструкции?
Да, но я хорошо представляю себе вечно виноватого бухгалтера, который выбирает Общую Бизнес Группу в Акте Списания.
Старый 05.07.2007, 11:07   #17  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от Kashin Посмотреть сообщение
Менеджеры ведут клиентов(часто именно они настраивают в карточке общие и ндс бизнес группы, так как у них написано в инструкции, не понимая, а зачем эта настройка нужна вообще)
А это говорит только о качестве внедрения.
С какой стати в НДС бизнес группы вы затолкали какие-то непонятные менеджерам параметры?

В чем состоит великая идея Навижина?
Навижин автоматически делает разноску по исходным параметрам, которые задали менеджеры.
Это значит, что исходные параметры должны быть понятным менеджерам.
Это значит, что НДС бизнес группы должны быть заданы не в терминах бухгалтерии, а в терминах работы с клиентами.

Например, неправильные названия для НДС бизнес групп:
НДС18-19.10
НДС18-19.20
и т.п.

Правильные названия:
Россия
Украина
Буржуй
ИЧП
ЧастнЛицо
НашХитрый1
НашХитрый2
НашСуперХитрый

Неправильные названия для товарных групп:
ТМЦ10.1
ТМЦ10.2
ТМЦ43

Правильные названия товарных групп:
Материалы
МатериалыДерев
МатериалыПластик
ГотПрод

и т.п.
Главное, менеджеры должны вводить параметры на понятном для них языке.
И эти понятные для менеджеров параметры должны АВТОМАТИЧЕСКИ и ОДНОЗНАЧНО переводиться в бухгалтерские проводки.
Тогда дополнительный бухгалтер-контролер не нужен (в большинстве случаев).

Каждый должен вводить то, что знает.
Не больше!
Но и не меньше!

Цитата:
Сообщение от Kashin Посмотреть сообщение
Ведь в любом случае, учет будет возможен! В тех же инструкциях описано, что ПОСЛЕ учета, вы можете просмотреть, какие операции УЖЕ произвела программа используя функции навигатора. Отличная возможность получить нагоняй от руководства.
Но можно ДО учета проверить журнал и исходными параметрами.
Смотрите где корень вашей ошибки:
1. вы считаете НЕ существенной первичную информацию.
2. вы считаете существенной информацию о бухгалтерских. проводках

А должно быть наоборот.

Цитата:
Сообщение от Kashin Посмотреть сообщение
Да, но я хорошо представляю себе вечно виноватого бухгалтера, который выбирает Общую Бизнес Группу в Акте Списания.
Бухгалтер выбирает?
Если бухгалтер действительно выбирает Общую бизнес группу, то он конечно и виноват.
Если в списке Общих бизнес групп внедренец закодировал что-то никому не понятное, то это проблема внедренца.

Но речь то идет о другом.
Как правило, выбирает не бухгалтер.
А проверку вы делаете бухгалтерскую.

Вместо печати будущих проводок лучше расширьте тестовые отчеты в журналах и документах.
Пусть печатаются строки с ПЕРВИЧНОЙ информацией, с теми полями которые ввел пользователь.
А лучше не печатайте, а добавляйте специфичные бизнес-проверки полей журнала ДО учета.
Если пользователь ввел первичку правильно, то и бухгалтерские проводки должны быть правильными, чего их проверять то?
__________________
полезное на axForum, github, vk, coub.
Старый 05.07.2007, 11:45   #18  
RedFox is offline
RedFox
Участник
 
1,441 / 10 (0) +
Регистрация: 28.12.2004
Адрес: Киев
Цитата:
Сообщение от rmv Посмотреть сообщение
Предполагаю по причине того, что большинство пользователей системы (операторы call-центра, менеджеры по продажам, складские работники.. список можно продолжить) понятия не имеют о принципах бухучета и тем более учетной политике организации.
Честно гря я слабо себе представляю оператора склада, который выбирает Общую Бизнес Группу во Акте Списания, запускает тестовый учет и анализирует проводки.
А для этого и существуют базовые настройки в функционале, чтобы это не делать (а нем более не учить пользователей) вручную....
Их просто нужно знать или ДОДЕЛАТЬ!!!

Цитата:
Можно конечно на каждый участок посадить по буху... но зачем когда проще настроить базу и написать должностные инструкции?
На самом деле функционал проверки ОЧЕНЬ нужен, так как исправлять всегда тяжелее ;-)
Не помню кто говорил, но "предотвратить проблему всегда проще, чем разгребать ее последствия". А в навике именно так и получается.

Я конечно понимаю разработчиков БД от Микохарда, но иногда складывется впечатление, что они программят куски того, что по идее бы нужно было. Но вот наличие СКВОЗНОЙ ИДЕИ слегка отсутвует...

Я вообще бы предложил сейчас разаботчикам любых системы создать сайт "предложений и пожеланий", если уж своих мыслей не хватает.....
Старый 05.07.2007, 12:28   #19  
artkashin is offline
artkashin
Участник
MCBMSS
 
519 / 18 (2) ++
Регистрация: 06.12.2006
Кстати, возможно это баг, но нажав кнопку цитировать, в окне редактирования сообщения но не отображаются цитаты второго уровня.

Цитата:
Сообщение от mazzy Посмотреть сообщение
А это говорит только о качестве внедрения.
С какой стати в НДС бизнес группы вы затолкали какие-то непонятные менеджерам параметры?

В чем состоит великая идея Навижина?
Навижин автоматически делает разноску по исходным параметрам, которые задали менеджеры.
Это значит, что исходные параметры должны быть понятным менеджерам.
Это значит, что НДС бизнес группы должны быть заданы не в терминах бухгалтерии, а в терминах работы с клиентами.

Каждый должен вводить то, что знает.
Не больше!
Но и не меньше!
Это верно, но
жизнь разная бывает, особенно, если в Наве ведется российская бухгалтерия. В этом случае, получается, менеджер просто обязан знать как работает предприятие, чтобы правильно выставить настройки, в конкретной ситуации. А он не хочет знать, что для этих товаров надо выбрать комиссионные настройки клиента, а для этих настройки клиента при продаже ему собственного товара. С точки зрения менеджера ему все равно что он продает, и какие имущественные отношения связывают те или иные виды товаров, ему важен спрос и предложение. И таких "мелочей" огромное количество.


Цитата:
Сообщение от mazzy Посмотреть сообщение
Но можно ДО учета проверить журнал и исходными параметрами.
Смотрите где корень вашей ошибки:
1. вы считаете НЕ существенной первичную информацию.
2. вы считаете существенной информацию о бухгалтерских. проводках

А должно быть наоборот.
Но иногда исходных строк журналов слишком много, чтобы в приемлемое время проверить журнал. Считаю существенной любую информацию, и поэтому жизненно необходимо иметь инструменты предварительного контроля всех видов информации, а не только какого-то куска, пусть и первичного.

Цитата:
Сообщение от mazzy Посмотреть сообщение
Но речь то идет о другом.
Как правило, выбирает не бухгалтер.
А проверку вы делаете бухгалтерскую.
Но в чем глубинный смысл существования бухгалтера? В учете и контроле. А не в сдаче отчетности налоговым органам. И бухгалтер имеет право на контроль введенной информации. Я только говорю о необходимости подобной проверки. Не только по финансовому журналу, но и по аналитическим измерениям и товарным журналам. И совсем не обязательно менеджеру запускать подобную проверку. Это надо для лица, ответственного за учет.

Цитата:
Сообщение от mazzy Посмотреть сообщение
Вместо печати будущих проводок лучше расширьте тестовые отчеты в журналах и документах.
Пусть печатаются строки с ПЕРВИЧНОЙ информацией, с теми полями которые ввел пользователь.
А лучше не печатайте, а добавляйте специфичные бизнес-проверки полей журнала ДО учета.
В данном случае это ведь и есть специфичная бизнес-проверка до учета (не полей правда) и тестовый отчет одновременно. Опять повторюсь. Я не за конкретную реализацию (я ее в глаза не видел), я за сам факт необходимости такой ДЕТАЛЬНОЙ проверки ДО учета, т.е. до оффициальной регистрации в системе. Ведь, фактически, учет в системе, где нельзя удалять данные, сравним с постановкой подписи под оффициальным документом. И ставя подпись, пользователь должен понимать о последствиях этого действия, ДО факта подписи.

Цитата:
Сообщение от mazzy Посмотреть сообщение
Если пользователь ввел первичку правильно, то и бухгалтерские проводки должны быть правильными, чего их проверять то?
Вот так и появляются ошибки в миллионы долларов в отчетности. Потому что, кто-то, где-то, упустил какую-то настройку в динамично меняющейся среде, неправильно ввел информацию или ошибся ноликом, не смог в сотнях строк документа все внимательно отследить и, следуя этому замечательному простому правилу, решил, что введеная первичная информация верна. Чего проверять-то результат?
Старый 05.07.2007, 13:03   #20  
artkashin is offline
artkashin
Участник
MCBMSS
 
519 / 18 (2) ++
Регистрация: 06.12.2006
Цитата:
Сообщение от IGHG Посмотреть сообщение
Это чисто бухгалтерский эгоизм. В большую корпорацию где стоит ERP система бухгалтеров берут зачастую из маленьких компаний где они были и цари и боги, финдиректора нету, полная свобода действий. Вот и получается некий групповой эгоизм, истерики. И не врубиться им что данные учета сразу видны всем - от директора до товароведа.
Вот я представляю себя на месте бухгалтера. Раньше я мог удалять документы и править как хотел и когда хотел, был царь и бог. Пришел в крупную корпорацию, где нет удаления. Я еще плохо понимаю систему и мне потребуется месяц (полгода, год), чтобы въехать в нее и в бизнес-процессы компании, и не совершать глупых ошибок. Я прекрасно понимаю, что за меня решают большинство управленческих вопросов. Фин дир. говорит сколько денег куда перевести, менеджеры совершили кучу отгрузок, которые необходимо зарегистрировать в системе и распечатать для них документы. Отдел закупок подготовил огромное количество новых товаров, с которыми фирма до этого не работала. Мне остается фактически ввод этих данных в систему и/или их учет. Моя обязанность в финальном контроле правильности этих данных и подготовке бухгалтерской отчетности. Но! Я бухгалтер ( специалист по контролю правильного заполнения аналитик) оперирую на своем уровне логики, меня врядли посвещают во все тонкости бизнес-процессов компании. Для меня важны проводки (разнос аналитик). Но! Инструмента проверки "чтоже получится" нет! Зато, ошибки, совершенные мной есть повод для выговора. Естественно, будут истерики, и в большинстве случаев, к эгоизму никакого отношения не имеющие. Всего лишь получив в подобный механизм, я, зная бухгалтерию, или прочитав принципы корпоративного учета аналитик, могу гарантировать, что хотябы могу отследить большинство ошибок до факта учета. А так попахивает отсутствием ресурсов при наличии ответственности.
 

Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск
Опции просмотра

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 17:38.