Специалисты “Вест Концепт” завершили создание add-on модуля предварительного проведения документов

[asdf_imported]

Специалисты “Вест Концепт” завершили создание add-on модуля предварительного проведения документов

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

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

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

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

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

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

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

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

Модуль “Трассировщик” уже внедрен в филиале шведско-финского холдинга Kalmar Industries, а также в гостиничных комплексах “Бородино” и “Милан”. При этом специалисты “Вест Концепт” уверены, что данное решение может стать полезным и для других компаний-пользователей системы Microsoft Navision.

[Sitizen]

Эта "неразрешимая проблема" уже три года назад была разрешена.

А предосмотр проводок в IE выводится?

[IGG]

Наверное метода простая - перед COMMIT в CU12 выводится диалог? А потом либо COMMIT либо откат?

[rmv]

).
Порадовала фраза - "а также прогнозирование состояния предприятия".

[rmv]

IGHG
здесь обсуждалось:
http://forum.mazzy.ru/index.php?showtopic=...t=0&p=17857

Написать обертку для учетных кодеюнитов
Отломать где нужно коммиты.
Работы на 2-3 дня максимум.

[IGG]

Цитата:

Сообщение от rmv

IGHG
здесь обсуждалось:
http://forum.mazzy.ru/index.php?showtopic=...t=0&p=17857

Написать обертку для учетных кодеюнитов
Отломать где нужно коммиты.
Работы на 2-3 дня максимум.

Ага. И я там засветился тоже в том топике. У меня тогда на прошлой работе бухгалтер требовал видеть все проводки в паре Дебет-Кредит. Ей простой список записей книги финопераций не подходил. "Хочу чтоб все было как в 1С". :-)

[mazzy]

Цитата:

Сообщение от asdf

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

Жалко, что не указали, какие побочные эффекты появляются при таком разрешении этой "неразрешимой проблемы".

Цитата:

Сообщение от asdf

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

Жалко, что не объяснили почему "стандартно" заложено именно такое поведение
Возникает ощущение, что стандартный функционал писали какие-то недотыкомки, которые не могут нормально, по-пацански расширить функционал.

Цитата:

Сообщение от asdf

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

И проанализировать остаток на счетах, наверное

Цитата:

Сообщение от asdf

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

Угу. Вот так одним махом и перечеркнули расширили функционал.
Теперь все предприятие снова стоит и ждет одобрения бухгалтера.
Раньше то, ужас то какой, проводки делались без одобрения бухгалтера. Как так можно?

Цитата:

Сообщение от asdf

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

О! А такого действительно ни у кого не было. По крайней мере никто об этом не говорил.

Цитата:

Сообщение от asdf

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

Интересно, у кого такое окно появляется?
У бухгалтера или у того пользователя, который нажал на кнопку Учет?

Цитата:

Сообщение от asdf

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

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

Цитата:

Сообщение от asdf

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

Угу. Какая разница что там понавведено?
Зато бухгалтерские проводки правильные.
Ну, если бухгалтерские проводки и есть результат, то почему бы и нет?

[IGG]

Лично я посоветовал немножко думать головой что вводишь. Но конечно объявление падает на благодатную почву. Потому что в массе своей бухгалтеры пришли из 1С и все хотят чтобы ERP была как 1С с чистого листа: захотел - удалил что хочешь, захотел, отменил...
А поскольку за удаление и сторнирование в нормальных фирмах ругают и даже наказывают то им нужно нечто, чтобы просмотреть в удобном для них виде. Я вышел из положения тем что написал некий отчет где прописал дебет-кредит, правда в самом простом выражении, всего я не охватил бы. Перехватывать COMMIT - не подвиснет ли база на учете?

[mazzy]

Цитата:

Сообщение от IGHG

бухгалтеры ... все хотят чтобы...

Я согласен, что "бухгалтеры хотят".
И категорически не согласен, что "все хотят". Нет, далеко не всех хотят, чтобы "удалил что хочешь, отменил что хочешь".

[IGG]

Цитата:

Сообщение от mazzy

Я согласен, что "бухгалтеры хотят".
И категорически не согласен, что "все хотят". Нет, далеко не всех хотят, чтобы "удалил что хочешь, отменил что хочешь".

Это чисто бухгалтерский эгоизм. В большую корпорацию где стоит ERP система бухгалтеров берут зачастую из маленьких компаний где они были и цари и боги, финдиректора нету, полная свобода действий. Вот и получается некий групповой эгоизм, истерики. И не врубиться им что данные учета сразу видны всем - от директора до товароведа.

[artkashin]

По-моему, действительно полезный функционал, позволяющий избежать множества ошибок. Ведь проверить результат, всегда легче, чем его предсказать. Далеко не всегда, при выверке первичной информации, можно найти ошибку. Ведь есть же Тестовый отчет, и почему никто не ругает его за то, что он мало что тестит? Другое дело, что при реализации этого функционала, возможно, пришлось немало "полазить" в учетных кодюнитах. Но за это надо не разработчика функционала винить, а Микрософт, которая не предоставила в системе с отсутствующей системой удаления документов толковых проверок ДЛЯ ПОЛЬЗОВАТЕЛЯ, а что же он учитывает.

[artkashin]

И еще. Часто бывает так, что в документе 100 строк, в каждой строке 5-6 измерений (это еще мягкий пример). Для каждой строки свои настройки учета, как выверить такой документ? И сколько надо людей принять на работу на должность выверщика, если таких документов сотни в день? Тем более, станьте хоть раз на сторону пользователя, это же не демон, а человек, а он, ошибается, если плохо понимает почему так делать, и что он получит. Мне, например, становится страшно, если бы мне пришлось быть "простым" менеджером по продажам или бухгалтером, сидящем на выписке документов, ведь всегда есть нестандартные ситуации, в которых приходится менять автоматически подставляемые системой значения, а проверить, все ли я правильно заполнил не представляется возможным, только как учесть и проверить. Или это не так?

[artkashin]

Цитата:

Сообщение от mazzy

Цитата:

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

Жалко, что не объяснили почему "стандартно" заложено именно такое поведение
Возникает ощущение, что стандартный функционал писали какие-то недотыкомки, которые не могут нормально, по-пацански расширить функционал.

У меня возникает. Может мне кто-то объяснит, почему "стандартно" заложено именно такое поведение?

[rmv]

Цитата:

У меня возникает. Может мне кто-то объяснит, почему "стандартно" заложено именно такое поведение?

Предполагаю по причине того, что большинство пользователей системы (операторы call-центра, менеджеры по продажам, складские работники.. список можно продолжить) понятия не имеют о принципах бухучета и тем более учетной политике организации.
Честно гря я слабо себе представляю оператора склада, который выбирает Общую Бизнес Группу во Акте Списания, запускает тестовый учет и анализирует проводки.
Можно конечно на каждый участок посадить по буху... но зачем когда проще настроить базу и написать должностные инструкции?

[mazzy]

абсолютно согласен с rmv.

[artkashin]

Цитата:

Сообщение от rmv

Предполагаю по причине того, что большинство пользователей системы (операторы call-центра, менеджеры по продажам, складские работники.. список можно продолжить) понятия не имеют о принципах бухучета и тем более учетной политике организации.

Да, согласен, но именно большинство этих пользователей ведут справочники, а не бухгалтерия. Менеджеры ведут клиентов(часто именно они настраивают в карточке общие и ндс бизнес группы, так как у них написано в инструкции, не понимая, а зачем эта настройка нужна вообще), на производстве заводят товары, опять же не бухгалтеры! Можно сколь угодно перекладывать работу на того, кто в курсе об учетной политике и принципах бухучета, но это не решает главного вопроса УЧИТЫВАЮЩЕГО пользователя - как проверить, введенная информация правильна или нет? Ведь в любом случае, учет будет возможен! В тех же инструкциях описано, что ПОСЛЕ учета, вы можете просмотреть, какие операции УЖЕ произвела программа используя функции навигатора. Отличная возможность получить нагоняй от руководства.

Цитата:

Сообщение от rmv

Честно гря я слабо себе представляю оператора склада, который выбирает Общую Бизнес Группу во Акте Списания, запускает тестовый учет и анализирует проводки.
Можно конечно на каждый участок посадить по буху... но зачем когда проще настроить базу и написать должностные инструкции?

Да, но я хорошо представляю себе вечно виноватого бухгалтера, который выбирает Общую Бизнес Группу в Акте Списания.

[mazzy]

Цитата:

Сообщение от Kashin

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

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

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

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

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

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

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

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

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

Цитата:

Сообщение от Kashin

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

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

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

Цитата:

Сообщение от Kashin

Да, но я хорошо представляю себе вечно виноватого бухгалтера, который выбирает Общую Бизнес Группу в Акте Списания.

Бухгалтер выбирает?
Если бухгалтер действительно выбирает Общую бизнес группу, то он конечно и виноват.
Если в списке Общих бизнес групп внедренец закодировал что-то никому не понятное, то это проблема внедренца.

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

Вместо печати будущих проводок лучше расширьте тестовые отчеты в журналах и документах.
Пусть печатаются строки с ПЕРВИЧНОЙ информацией, с теми полями которые ввел пользователь.
А лучше не печатайте, а добавляйте специфичные бизнес-проверки полей журнала ДО учета.
Если пользователь ввел первичку правильно, то и бухгалтерские проводки должны быть правильными, чего их проверять то?

[RedFox]

Цитата:

Сообщение от rmv

Предполагаю по причине того, что большинство пользователей системы (операторы call-центра, менеджеры по продажам, складские работники.. список можно продолжить) понятия не имеют о принципах бухучета и тем более учетной политике организации.
Честно гря я слабо себе представляю оператора склада, который выбирает Общую Бизнес Группу во Акте Списания, запускает тестовый учет и анализирует проводки.

А для этого и существуют базовые настройки в функционале, чтобы это не делать (а нем более не учить пользователей) вручную....
Их просто нужно знать или ДОДЕЛАТЬ!!!

Цитата:

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

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

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

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

[artkashin]

Кстати, возможно это баг, но нажав кнопку цитировать, в окне редактирования сообщения но не отображаются цитаты второго уровня.

Цитата:

Сообщение от mazzy

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

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

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

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

Цитата:

Сообщение от mazzy

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

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

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

Цитата:

Сообщение от mazzy

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

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

Цитата:

Сообщение от mazzy

Вместо печати будущих проводок лучше расширьте тестовые отчеты в журналах и документах.
Пусть печатаются строки с ПЕРВИЧНОЙ информацией, с теми полями которые ввел пользователь.
А лучше не печатайте, а добавляйте специфичные бизнес-проверки полей журнала ДО учета.

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

Цитата:

Сообщение от mazzy

Если пользователь ввел первичку правильно, то и бухгалтерские проводки должны быть правильными, чего их проверять то?

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

[artkashin]

Цитата:

Сообщение от IGHG

Это чисто бухгалтерский эгоизм. В большую корпорацию где стоит ERP система бухгалтеров берут зачастую из маленьких компаний где они были и цари и боги, финдиректора нету, полная свобода действий. Вот и получается некий групповой эгоизм, истерики. И не врубиться им что данные учета сразу видны всем - от директора до товароведа.

Вот я представляю себя на месте бухгалтера. Раньше я мог удалять документы и править как хотел и когда хотел, был царь и бог. Пришел в крупную корпорацию, где нет удаления. Я еще плохо понимаю систему и мне потребуется месяц (полгода, год), чтобы въехать в нее и в бизнес-процессы компании, и не совершать глупых ошибок. Я прекрасно понимаю, что за меня решают большинство управленческих вопросов. Фин дир. говорит сколько денег куда перевести, менеджеры совершили кучу отгрузок, которые необходимо зарегистрировать в системе и распечатать для них документы. Отдел закупок подготовил огромное количество новых товаров, с которыми фирма до этого не работала. Мне остается фактически ввод этих данных в систему и/или их учет. Моя обязанность в финальном контроле правильности этих данных и подготовке бухгалтерской отчетности. Но! Я бухгалтер ( специалист по контролю правильного заполнения аналитик) оперирую на своем уровне логики, меня врядли посвещают во все тонкости бизнес-процессов компании. Для меня важны проводки (разнос аналитик). Но! Инструмента проверки "чтоже получится" нет! Зато, ошибки, совершенные мной есть повод для выговора. Естественно, будут истерики, и в большинстве случаев, к эгоизму никакого отношения не имеющие. Всего лишь получив в подобный механизм, я, зная бухгалтерию, или прочитав принципы корпоративного учета аналитик, могу гарантировать, что хотябы могу отследить большинство ошибок до факта учета. А так попахивает отсутствием ресурсов при наличии ответственности.