Axapta 3.0 SP2 пересчет себестоимости без закрытия склада

[AKIS]

Здравствуйте,

Не знаю, как "это" называется в русской версии, но в международной "оно" проходит под именем <i>Recalculation</i> (<i>Inventory Management -> Periodic -> Closing and adjustment...</i>)

Для некоторых кодов номенклатуры этот самый пересчет дает довольно странные результаты - коррекция в размере нескольких десятков/сотен тысяч долл., себестоимость при этом повышается в 10-20 раз.

Всего таких кодов у меня 4, все типа "сырье", соответственно неверная себестоимость оказывается и у всей продукции, что это сырье использует.

Выглядит это так: система пересчитывает себестоимость в "бесконечном цикле", т.е. завершение процедуры происходит по достижению максимального числа транзакций (Maximum throughputs), что, по-моему, само по себе неправильно, т.к. система предупреждает, мол не надо ли увеличить это самое Maximum... А оно у меня уже и так - тысяча, при стандартных десяти...

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

Как всегда - безмерно благодарен за советы и помощь.

[AKIS]

И еще. Уж не знаю, связано это как-то или нет, но именно у тех самых кодов наблюдается еще одна странность. "Цена списания" (цена единицы номенклатуры, поставляемая при операциях "списание со склада в производство") у некоторых транзакций с участием этих материалов - выше "нормальной в сто раз. Обычная цена - 4-5 центов, но иногда вдруг проскакивает четыре доллара. Происходить это стало с тех пор как перешли с 2.5 на 3.0. Причина уже тоже выяснена: различие в алгоритмах определения этой цены в 2.5 и 3.0.

Было:

Если

PHP код:

((this.postedQty  + (inventModelGroup.inclPhysicalValueInCost ? this.received - this.deducted : 0)) <= 0 ||
 (this.postedValue    + (inventModelGroup.inclPhysicalValueInCost ? this.physicalValue: 0))) <= 0))) 


то берем standard cost, иначе считаем среднюю.

Стало:

Если

PHP код:

((this.postedQty      + (inventModelGroup.inclPhysicalValueInCost ? this.received - this.deducted : 0)) * 
 (this.postedValue    + (inventModelGroup.inclPhysicalValueInCost ? this.physicalValue : 0))) <= 0))) 


то берем standard cost, иначе считаем среднюю.

Т.е. раньше, если postedQty и postedValue были оба отрицательными - все равно бралась standard cost, а теперь в этом случае считается средняя...

Изменение - точно в стандартном функционале, т.е. by Microsoft. Вроде бы оно выглядит логично - только вот почему ж у нас все-таки вылезают ошибки...

[Ser]

Цитата:

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

посмотрите здесь:
AX-300-TIP-007-V.01.00-ENUS
"Recalculation: Simulated Inventory Closing"

[Valery]

Самое подробное описание алгоритма перерасчета я встречал в документе по 2.5 под названием "Методические рекомендации. Рачет себестоимости. Теория и практика". DocID: AX-250-IMP-001-v01.00-RURU

[AKIS]

Спасибо за ссылку.

В общем, из документа следует, что коррекция <b>и должна быть</b> такой большой - раз цена списания <b>до</b> коррекции прыгает в диапазоне 4 цента.. 4 доллара... Т.е. система пытается привести цену к некоей средней...

Остается вопрос, как так получается что цена списания до коррекции так сильно изменялась... И можно ли теперь, постфактум, это как-то побороть, и пересчитать ее всю из расчета 4 цента...

[LCh]

В 2.5 закрытие склада вообще неверно работает в каком-то случае. В каком - я уже не помню. Где-то на partnersguide описывается.

Вообще, пересчёт не подходит. С его помощью не получить среднюю стоимость человеческой без функциональных изменений. Это как предварительный расчёт, и работает он медленнее (там все проходы - как нулевой при закрытии склада).

Стоимость прыгает по разным причинам. Всё в итоге очень просто - если не стоит стандартная себестоимость, то расходная проводка всегда идёт по средней мнгновенной на момент списания. Например, оприходование по закупке по цене $10, перемещение тоже на $10 (если включается физическая стоимость в расчёт средней). Затем фактурирование по цене $20, и уже следующее перемещение\списание будет идти по $20, а старое останется по $10. До закрытия, разумеется.

И ещё по 2.5, что скорее всего относится и к 3.0. Если, допустим, у вас склад включен в расчёт средней цены, а ячейка - нет, то если вы закроете склад, накинете накладной расход на счёт-фактуру в закрытом периоде датой следующего, и закроете следующий период, результат ошеломит, но в целом стоимость будет правильно рассчитана (зы - исправляется ручным закрытием проводок по движениям между ячейками внутри склада - обнуляется стоимость и проводки сопоставляются, т.е. qty = qtysettled).

[FishLog]

2 LCh

"Стоимость прыгает по разным причинам. Всё в итоге очень просто - ..."

Указанный вами пример - может объяснить почему цена скачет раза в 2. Но не в 100 раз !

Вы описали ситуацию когда скачут реальные цены и из за этого скачут коррекции в аксапте. Но в случае AKIS - цена скакнула в 100 раз. А это уже плохо, так как скорее всего не реальная цена так подскочила, а Аксапта сглючила.

[LCh]

2 FishLog

Скажем так - случаи бывают различные. Возможно, дело в "Сырье" или в закрытии склада. Я лишь обьясняю, что зачастую по проводкам при наличии большого вида движений консультанты упускают какие-то детали. Цены могут прыгать хоть в миллион раз. Коэффициент прямо пропорционален ошибкам пользователей, консультантов, программистов И закрытия склада (правда, опять же, Microsoft божится, что в 3.0 ошибки по закрытию исправлены). И ещё говорю, что результат пересчёта и результат закрытия буду РАЗЛИЧНЫ, и причём очень существенно.

2 AKIS

Советую попробовать закрыть эти четыре номенклатуры и сравнить результат с пересчётом. Так же обратить внимание на включённый\выключенный флажок включения физической стоимости и даты каких-бы-то-ни-было коррекций (от накладного расхода до коррекции "в наличии").

А ещё, если найдёте проблему, поделитесь с братьями меньшими, дюже интересно, что же там всё-таки мешает.

[Андре]

Цитата:

правда, опять же, Microsoft божится, что в 3.0 ошибки по закрытию исправлены.....

Будьте осторожны. Может Microsoft и божится, однако в sp2 механизм закрытия склада вновь переписывается, а в документации AX-300-TIP-043-v1.00-RU mbs признается в двух ошибках, которые все-таки были, но теперь исправлены:

Цитата:

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