"Управление затратами" в следующей версии Dynamics AX - ваши пожелания

[fed]

Цитата:

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

Наконец, говоря о проблеме корректировок складских проводок задним числом, затронутой опять таки logger'ом, надо:
1. Наконец-то написать вместо продвинутого отчета по остаткам (из Rollup7), который конечно все партнеры благополучно проигноирировали, а внятную методичку, которая объясняла бы как и почему считается финансовый остаток по номенклатуре на дату, объясняла бы что рассчитывать остаток тупым суммированием inventTrans - нельзя, а также то, что считать денежный остаток по номенклатуре можно только в разрезе подмножества финансовой складской аналитики. Я просто ни разу не видел чтобы кто-то всерьез использовал стандартные отчеты по складским запасам, все пишут свои (просто потому что нужен красивенький отчет с экспортом и в том виде, в котором его привык видеть клиент). И большая часть партнеров не обладает пониманием того как правильно себестоимость складскую считать.
2. Надо сделать специальную галочку (в складской модели наверное) "Запрет корректировки закрытых проводок" и специальный счет "корректировки прошлых периодов" (в разноске по номенклатуре). Если эта галочка установлена, то надо будет при любой попытке прогнать себестоимость через закрытую проводку, немедленно списывать данную корректировку себестоимости на счет корректировок прошлых периодов. При этом надо ОЧЕНЬ тщательно расписать в методичке, что вообще говоря, корректировка прошлых периодов является признаком проблемы с первичными данными. Либо нарушена хронология приходов и расходов, и начисление накладных расходов на открытый приход, из за нарушения хронологии, протягивается через приходы прошлых периодов, либо бухгалтерша по ошибке повесила текущие накладные расходы на накладную прошлого месяца. Причем надо понимать, что подход этот поможет только в сложных ситуациях (когда у нас циклы в графе себестоимости есть или что-то подобное). Если у меня незакрытый расход прошлого месяца сопоставился с приходом текущего (просто потому что бардак в первичке), то никакие переоценки и счета корректировок прошлых периодов - не помогут, потому что списание это сможет работать только при корректировке ПРИХОДА прошлых периодов - а у нас в этом примере у прихода все впорядке с датой, не в порядке дата у расхода...

После некоторых раздумий:
Хорошо бы еще завести какую-то анализируемую таблицу протокола закрытия (ведение которой включается галочкой в форме закрытия). И писать туда о всех нехороших ситуациях при закрытии. Например если в ходе сопоставления сопоставились с расходом закрытого периода. Или информацию о списанных округлениях. Или ситуации когда не нашлось inventTransPosting и система взяла стандартные счета.
Еще неплохо бы после стадии сопоставления (но до стадии прогонки себестоимости), иметь возможность запускать (в качестве дополнительного, опционального шага) процедуру поиска циклов в графе сопоставлений. Правда мне кажется что этот алгоритм не распараллелить, а на одном хэлпере он может очень и очень долго выполняться. В общем - не уверен, хотя сама по себе идея интересная...