Цитата:
Сообщение от
SEKL
По поводу впечатлений о DAX 2012 - было бы интересно услышать ваше мнение по пунктам. Что нравится, что не нравится.
Очень надеюсь написать статейку на эту тему к новому году. (Правда не уверен что времени хватит).
По поводу закрытия склада - так там только одна принципиальная проблема осталась, упомянутая Logger'ом. Надо (точнее говоря - можно) привязать себестоимость (и мгновенную себестоимость списания, и истинную себестоимость рассчитываемую при закрытии склада) не к лоту, а к сочетанию лот+аналитика финансового склада (чтобы себестоимость не ехала при переносах). Только в таком случае, вам еще придется ограничить возможности слияния/расщепления партий в обычном журнале переноса (чтобы не получалось что 3 партии списали и 2 других партии оприходовали) и сделать какой-то специальный журнал слияния/разделения аналитик, который позволял бы только операции вида 1:n или n:1 (Но никак не n:m).
Из более мелкого (но полезного) - надо бессмысленную проверку остатков на текущую дату, заменить на проверку остатков по каждой номенклатуре в течении всего закрываемого периода. Если у меня номенклатуру продали чуть раньше чем купили (хотя сейчас остаток положительный или нулевой), система должна выводить в отчет сообщение о том что по такой-то номенаклатуре была нарушена хронология событий и точной себестоимости рассчитать невозможно.
Наконец, говоря о проблеме корректировок складских проводок задним числом, затронутой опять таки logger'ом, надо:
1. Наконец-то написать вместо продвинутого отчета по остаткам (из Rollup7), который конечно все партнеры благополучно проигноирировали, а внятную методичку, которая объясняла бы как и почему считается финансовый остаток по номенклатуре на дату, объясняла бы что рассчитывать остаток тупым суммированием inventTrans - нельзя, а также то, что считать денежный остаток по номенклатуре можно только в разрезе подмножества финансовой складской аналитики. Я просто ни разу не видел чтобы кто-то всерьез использовал стандартные отчеты по складским запасам, все пишут свои (просто потому что нужен красивенький отчет с экспортом и в том виде, в котором его привык видеть клиент). И большая часть партнеров не обладает пониманием того как правильно себестоимость складскую считать.
2. Надо сделать специальную галочку (в складской модели наверное) "Запрет корректировки закрытых проводок" и специальный счет "корректировки прошлых периодов" (в разноске по номенклатуре). Если эта галочка установлена, то надо будет при любой попытке прогнать себестоимость через закрытую проводку, немедленно списывать данную корректировку себестоимости на счет корректировок прошлых периодов. При этом надо ОЧЕНЬ тщательно расписать в методичке, что вообще говоря, корректировка прошлых периодов является признаком проблемы с первичными данными. Либо нарушена хронология приходов и расходов, и начисление накладных расходов на открытый приход, из за нарушения хронологии, протягивается через приходы прошлых периодов, либо бухгалтерша по ошибке повесила текущие накладные расходы на накладную прошлого месяца. Причем надо понимать, что подход этот поможет только в сложных ситуациях (когда у нас циклы в графе себестоимости есть или что-то подобное). Если у меня незакрытый расход прошлого месяца сопоставился с приходом текущего (просто потому что бардак в первичке), то никакие переоценки и счета корректировок прошлых периодов - не помогут, потому что списание это сможет работать только при корректировке ПРИХОДА прошлых периодов - а у нас в этом примере у прихода все впорядке с датой, не в порядке дата у расхода...
Наконец- надо сделать то что давно сделали в русской локализации -завести в настройках разносок специальный счет для списания ошибок и погрешностей округления при закрытии (обычных, а не связанных с корректировками прошлого периода) и опять таки написать в методичке как оно работает. Просто в английском стандарте для этого используется обычный счет прибылей и убытков по номенклатуре, и для среднего консультанта, понять по ваучеру закрытия, откуда у нас упало сколько-то там копеек на этот счет с какой-то аналитикой - выше понимания.
Ну и наконец - можно в inventSettlement занести новое поле (или расширить там какие-то из перечислимых полей с типом сопоставления), чтобы позволить легко вычленять в inventSettlement все эти служебные корректировки со списанием ошибок и округлений...
Вот - пожалуй все. Привет AEG'у
