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

[rmv]

Цитата:

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

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

[artkashin]

Цитата:

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

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

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

Цитата:

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

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

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

[mazzy]

Цитата:

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

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

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

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

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

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

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

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

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

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

Цитата:

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

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

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

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

Цитата:

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

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

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

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

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

[artkashin]

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

Цитата:

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

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

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

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

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

Цитата:

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

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

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

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

Цитата:

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

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

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

Цитата:

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

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

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

Цитата:

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

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

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

[RedFox]

Цитата:

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

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

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

Цитата:

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

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

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

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