denisfed: Обновление статьи о закрытии склада.

[Blog bot]

Источник: http://blogs.technet.com/denisfed/ar...7/3236804.aspx
==============

Выложил обновленную версию статьи о принципах работы с себестоимостью в Dynamics AX. Обновление сделано с учетом новых возможностей Dynamics AX 2009.

Источник: http://blogs.technet.com/denisfed/ar...7/3236804.aspx


**** обсуждение предыдущей версии: Denis Fedotenko: Себестоимость и закрытие склада ****

[mazzy]

Денис, появись здесь пожалуйста.
Позволь тебе респектов накидать.

[fed]

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

[mazzy]

Цитата:

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

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

Эк, как заковыристо сказал. Видимо, чтобы избежать ответственности за "обещания".

Я думаю, что вполне можно утверждать, что новая схема закрытия по средней позволит значительно повысить производительность по сравнению со старой схемой закрытия по среднему. В первую очередь за счет того, что в ax2009 число записей в inventSettlement имеет линейную зависимость от числа складских проводок O(n), а раньше имело квадратичную зависимость O(n^2).

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

=============
Надо отметить, что FIFO всегда имело линейную зависимость. Поэтому раньше выполнялось значительно быстрее, чем закрытие по среднему.

[mazzy]

Пожелание: можно в таблицах все числа выровнять вправо, чтобы читать было удобнее?

[mazzy]

Цитата:

Для версии DAX 2009 это соображение по прежнему справедливо. При закрытии склада по средней - у нас по прежнему все приходы сопоставляются со всеми расходами. То что теперь это делается не через множество складских сопоставлений, а через фиктивный перенос экономической смысл проблемы не изменяет.

По-моему, неправда.
Здорово меняет экономический смысл. Особенно для номенклатуры с маленькой или округленной ценой.

Пример ax4:
Приход1, 60 шт, сумма 100 руб, цена единицы 1.6666(6). В аксапте записывается как 1.67
Приход2, 60 шт, сумма 70 руб, цена единицы 1.1666(6). В Аксапте записывается как 1.17
Классическое среднее, рассчитанное котловым методом: 1.41666(6) = (100+70)/120.

Расход1, 80шт, сумма = 123.6 = 1.67*60 + 1.17*20. Цена единицы 1.545.
Расход2, 20шт, сумма = 23.4 = 1.17*20. Цена единицы 1.17.

Т.е. раньше алгоритм "по среднему" на самом деле означал смесь между FIFO и средним.
============

Пример ax2009:
Приход1, 60 шт, сумма всего 100 руб, цена единицы 1.6666(6). В аксапте записывается как 1.67
Приход2, 60 шт, сумма всего 70 руб, цена единицы 1.1666(6). В Аксапте записывается как 1.17
Классическое среднее, рассчитанное котловым методом: 1.41666(6) = (100+70)/120.

Фиктивный расход: 100шт, сумма = 147 = 1.67*60+1.17*40, цена единицы 1.47
Фиктивный приход: 100шт, сумма = 147, цена единицы 1.47

Расход1, 80шт, сумма всего = 117.6 = 1.47*80. Цена единицы 1.47.
Расход2, 20шт, сумма всего = 29.4 = 1.47*20. Цена единицы 1.47.

Т.е. теперь экономический смысл кардинально поменялся:
1. в течение периода закрытия себестоимость списания будет одинаковой у всех проводок списания
2. ошибки округления существенно меньше, чем раньше. Даже при маленьких ценах. Даже когда цена за единицу меньше 1 копейки.
3. Хотя алгоритм по-прежнему является смесью между FIFO и средней, но он выдает результаты гораздо более близкие к классическому среднему, которое считается котловым методом.

[mazzy]

Самое интересное действительно в конце
Но там маловато примеров, таблиц и диаграм - воспринимать очень трудно. придется оставить на выходные. Можно дополнить примерами?

[mazzy]

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

[fed]

Цитата:

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

По-моему, неправда.
Здорово меняет экономический смысл. Особенно для номенклатуры с маленькой или округленной ценой.

Имеется в виду - от циклов в себестоимости это все равно не избавляет...

[petr]

Вопрос по статье, насчет обновленного механизма закрытия по средней в DAX2009

У нас такая ситуация возникла. Настроили группу складских аналитик примерно так:
Склад: обязательная аналитика и финансовая
Ячейка: первичная
Номер партии: финансовая

Получается так. При закрытии склада создаются "фиктивные переносы", и создаются они для комбинации склад+номер партии и ячейка в этих переносах остается незаполненной. И закрытие склада выдает ошибку, что ячейка не заполнена.

Получется нельзя использовать такие комбинации аналитик, когда есть нефинансовая, но обязательная для заполнения складская аналитика и одновременно финансовая, но не обязательная (след. проставленная не на всех проводках).

Или с этим можно как-то жить?

Добавлено позже:

И еще более простой сценарий: Имеем обязательную аналитику склад и она нефинансовая (хотим иметь среднюю по всему предприятию). В процессе закрытия склада получает сообщение о том, что аналитика должна быть заполнена (для новой "фиктивной" проводки переноса). Как можно получить среднюю по предприятию в таком случае?

[fed]

Цитата:

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

И еще более простой сценарий: Имеем обязательную аналитику склад и она нефинансовая (хотим иметь среднюю по всему предприятию). В процессе закрытия склада получает сообщение о том, что аналитика должна быть заполнена (для новой "фиктивной" проводки переноса). Как можно получить среднюю по предприятию в таком случае?

В общем - я бы попробовал это зарегистрировать как ошибку. Из самых лучших побуждений авторы закрытия решили использовать inventUpdate/inventMovement для создания этого фиктивного переноса. А о том что эти классы много лишних действий делают - не подумали.

[petr]

Цитата:

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

В общем - я бы попробовал это зарегистрировать как ошибку. Из самых лучших побуждений авторы закрытия решили использовать inventUpdate/inventMovement для создания этого фиктивного переноса. А о том что эти классы много лишних действий делают - не подумали.

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

[fed]

Цитата:

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

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

Я думаю - будет правильно считать. Единственное доступное моему воображению негативное последствие отключенной проверки - это то что какие-то попроводочные отчеты съедут, поскольку они будут ожидать присутствия аналитики в проводке, а ее не будет. И то вряд ли...

[aidsua]

Опечатка в блоке:

Цитата:

Зачем вообще нужно закрытие склада?

..должна рассчитываться системы на основании сопоставления..

[belugin]

Может кому сэкономлю 10 минут при подготовки печати - загнал таблицы в A4

[Starling]

Огромное спасибо fed за статью
Подниму в очередной раз уже заезженную тему об усреднении себестоимости в пределах лота. С учетом этой особенности получить метод FIFO в компаниях, которые физически не в состоянии вести на складе учет по партиям не возможно.
Пример:
1. Финансовая аналитика Склад и Метод расчета FIFO
2. Список операций:

a. 01.01.09 зак1 ТМЦ1 1шт по 10 на сумму 10 склад1

b. 02.01.09 зак2 ТМЦ1 2шт по 20 на сумму 40 склад1

c. 03.01.09 перенос ТМЦ1 2 шт по 16,67 на сумму 33,34 со склада 1 на склад 2

d. 04.01.09 продажа ТМ1 1шт по 16,67 на сумму 16,67 со склада2

3. Закрытие склада приведет к коррекции себестоимости

a. 01.01.09 зак1 ТМЦ1 1шт по 10 на сумму 10 склад1

b. 02.01.09 зак2 ТМЦ1 2шт по 20 на сумму 40 склад1

c. 03.01.09 перенос ТМЦ1 2 шт по 15 на сумму 30 со склада 1 на склад 2

d. 04.01.09 продажа ТМ1 1шт по 15 на сумму 15 со склада2

Что мы имеем - корректировка себестоимости переноса была выполнена по методу FIFO, тут вопросов нет. Но себестоимость продажи по методу FIFO должна быть равна 10, а мы получили 15.

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

Итого – как из этой ситуации выходить, используя только стандартную функциональность?

[Logger]

Цитата:

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

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

Итого – как из этой ситуации выходить, используя только стандартную функциональность?

п.2 вас не спасет. То что будут финансовые остатки в разрезе складов на одним плюс, на других такой же минус - не проблема. Это можно обойти. Проблема в другом - выключение склада из финансовой аналитики не решает проблему усреднения и партии все равно придется бить руками в строки. Можете проверить.

Итого - используя стандартную функциональность - проблему не решить. Только п.1

[Starling]

Цитата:

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

п.2 вас не спасет. То что будут финансовые остатки в разрезе складов на одним плюс, на других такой же минус - не проблема. Это можно обойти. Проблема в другом - выключение склада из финансовой аналитики не решает проблему усреднения и партии все равно придется бить руками в строки. Можете проверить.

Итого - используя стандартную функциональность - проблему не решить. Только п.1

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

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

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

[fed]

Угу - можно было бы сделать элементарной единицой себестоимости не лот, а сочетание лот+аналитика финансового склада, но тогда было бы не совсем ясно что делать если мы все-таки хотим слить две партии в одну.

Вообще, мне кажется что любая попытка заставить систему автоматически подставлять аналитики финансового склада, говорит о попытке разрешить организационную проблему программистским путем. Получается что часть служб работает с аналитиками, себестоимость по ним считает или там сроки годности смотрит. А часть служб - плевать на все это хотела, и просто, не парясь, требует чтобы система там все подставляла. Так что надо либо ВСЕХ участников процесса заставлять руками подставлять аналитику финансового склада, либо просто отказаться от учета номера партии, себестоимость считать по FIFO, а номер партии водить по желанию и в качестве примечания...

[Starling]

Цитата:

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

Угу - можно было бы сделать элементарной единицой себестоимости не лот, а сочетание лот+аналитика финансового склада, но тогда было бы не совсем ясно что делать если мы все-таки хотим слить две партии в одну.

Ну осмелюсь предположить, что себестоимость в новой партии (читай в новом фин складе) должна быть одинаковой, т.е. она должна формироваться как сумма себестоимости всех партий, которые в нее вошли. Вроде как все логично.... Только что делеать когда в качестве партии источника указана одна из партий, которые будут списаны. Тоже наверно усреднять, так как для других вариантов мы просто "порвем" остатки в пазрезе партий.

Цитата:

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

Вообще, мне кажется что любая попытка заставить систему автоматически подставлять аналитики финансового склада, говорит о попытке разрешить организационную проблему программистским путем. Получается что часть служб работает с аналитиками, себестоимость по ним считает или там сроки годности смотрит. А часть служб - плевать на все это хотела, и просто, не парясь, требует чтобы система там все подставляла. Так что надо либо ВСЕХ участников процесса заставлять руками подставлять аналитику финансового склада, либо просто отказаться от учета номера партии, себестоимость считать по FIFO, а номер партии водить по желанию и в качестве примечания...

Вот с этим я как раз и не согласен. FIFO без партии - это не FIFO (см. пример). Очень похоже, но не FIFO. Т.е. для компаний, которые физически не могут вести учет по партиям на складе, но хотят считать себестоимость по FIFO аксапта не подходит. И говорить о том, что хотите считать по FIFO ведите учет по партиям это уж как-то совсем дико.

В чем я ошибаюсь?