Denis Fedotenko: Себестоимость и закрытие склада

[Blog bot]

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


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

О чем все это?

По моему опыту общения с консультантами и разработчиками, внедряющими DAX, вопросы,связанные с закрытием склада и расчетом себестоимости, стали одними из самых больных на внедрениях. Люди относятся к закрытию склада как к черному ящику, который в зависимости от фазы луны выдает самые разнообразные результаты и отрабатывает за самое разное время. На мой взгляд – это вызвано тем, что информация по процедуре расчета себестоимости разбросана по разным местам документации, кроме того некоторые тонкости этой процедуры вообще нигде не описаны и их приходится изучать методом проб и ошибок или изучая исходные тексты процедуры закрытия склада.
В данной статье я попытался дать достаточно подробное объяснение того, как работает данная процедура и разобрать некоторые другие темы связанные с себестоимостью. Часть из приведенной информации собрана из различной документации по DAX, часть получена на основании опыта работы с Axapta 3.0 и разбора ее исходных текстов. На версии 4.0 я всю собранную информацию не перепроверял, но судя по анализу исходных кодов закрытия склада новой версии – серьезных изменений в алгоритме не произошло.
Документ рассчитан на достаточно опытных консультантов и архитекторов DAX, уже знакомых с основными идеями модуля торговли, уже потренировавшимися несколько раз в процедуре закрытия склада и накопивших вопросы по данной тематике.

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


Основной задачей процедуры закрытия склада является вычисление истинной себестоимости списания номенклатуры. DAX работает с себестоимостью следующим образом: В момент выполнения операции списания, система не пытается точно сосчитать себестоимость списания по данному складскому движению в соответствии с настройками складской модели. Вместо этого, система списывает некоторую оценочную себестоимость, в целом – более или менее похожую на истинную себестоимость. (Подробнее – в разделе "Оценочная себестоимость.”) Далее – при выполнении закрытия склада рассчитывается истинное значение себестоимости в соответствии с настройками складской модели. После выполнения расчета истинной себестоимости система рассчитывает коррекцию –разницу между оценочной себестоимостью и истинной. Эта коррекция записывается в таблицу складских проводок и разносится в ГК.Почему так сделано ? В общем случае, в момент выполнения списания, система может не содержать всех данных, необходимых для расчета истинной себестоимости. Например , при работе в режиме отрицательного склада, мы можем списывать номенклатуру до того как ее приход проведен по системе; при использовании модели "средняя за период» невозможно посчитать себестоимость до того момента, как период будет закончен и все приходы будут проведены по системе и так далее; по модели LIFO мы аналогичным образом не можем посчитать себестоимость расхода до тех пор пока у нас не будет проведен последний приход за период и т.д.
Время от времени, начинающие консультанты на внедрении, приходили ко мне с предложением как-то подправить аксапту, чтобы бухгалтера могли руками вводить в документы списания мгновенную себестоимость и в дальнейшем при закрытии склада, система не трогала такие складские проводки и не пыталась рассчитывать по ним истинную себестоимость. Так вот – подобный подход СИЛЬНЕЙШИМ образом противоречит идеологии метода расчета себестоимости, используемой в DAX. Истинная себестоимость списания ВСЕГДА должна рассчитываться системы на основании сопоставления приходных и расходных складских проводок.
После того как система посчитала истинную себестоимость за период, выполнение любых складских движений за этот период запрещается. Это вполне логично – поскольку вставка новых приходов или расходов задним числом, может привести к нарушению логики уже созданных сопоставлений приходов с расходами и появлению некорректной истинной себестоимости. Если нам нужно просто предварительно посчитать себестоимость списания для текущего состояния складских проводок, без блокировки дальнейших складских движений за период, достаточно вместо процедуры закрытия склада запустить процедуру пересчета.

Итак – закрытие склада состоит из следующих этапов:
1. Сопоставление приходных и расходный складских проводок. Расчет первичной себестоимости списания по расходным проводкам.
2. Прогон коррекции себестоимости по графу движения складских запасов
3. Разноска в ГК.
Рассмотрим каждый из этих этапов подробнее.

Сопоставление приходных и расходных проводок


Расчет истинной себестоимости списания в Аксапте всегда производится на основании сопоставления расходной складской проводки с приходной. При этом сопоставление происходит для проводок, с совпадающим кодом номенклатуры и аналитиками финансового склада.
Для модели FIFO или LIFO, правильность такого подхода вполне очевидна: Например если мы купили 2 штуки по 10 рублей и 5 штук по 14 рублей, то для того чтобы посчитать себестоимость списания 3 штук, надо сопоставить их с первым приходом общей суммой 20 рублей и одной штукой из второго прихода – суммой 14 рублей. Таким образом, в нашем примере, себестоимость списания по расходной проводке на 3 штуки составит 34 рубля. В дальнейшем ,я буду оперировать понятиями количества и суммы сопоставления. При этом сумма сопоставления рассчитывается как себестоимость приходной складской проводки на дату закрытия склада помноженная на отношения сопоставленного количества к количеству в исходной проводке. Естественно – сумма сопоставления округляется в соответствии с настройками округления в справочнике валют.
Как сопоставляются приходы и расходы по модели FIFO– интуитивно понятно, поэтому я не буду об этом подробно рассказывать. Единственное что стоит отметить - система не проверяет соответствие порядка приходов и расходов. Скажем – если мы провели по системе закупку изделия 15ым числом, а списание 5ым (предположим, что у нас никогда не было других движений по этому изделию). В этом случае – эти два прихода будут молча сопоставлены по модели FIFO, что вообще говоря – противоречит здравому смыслу. Подробнее о причинах появления отрицательного остатка и негативных последствиях этого явления я расскажу в разделах “Почему возникает отрицательный складской остаток?” и "Прогон себестоимости”
Модели LIFO или LIFO на дату в DAX было бы правильнее назвать LILO (Last In – Last out). Работают они как и FIFO , но только с точностью до наоборот. Система бежит по списку несопоставленных расходов, начиная с самого последнего и сопоставляет с каждым из них самый последний несопоставленный приход. “LIFO на дату” отличается от LIFO тем, что с расходом может сопоставляться только тот приход, который уже был на складе в момент выполнения расхода. Существование двух этих методов вызвано следующим соображением: Представим себе ситуацию, при которой у нас товар закупался 1ым,5ым и 31ым числами, а продавался, допустим, 10 и 18ым числами. С точки зрения строгой бухгалтерской идеи LIFO, у нас гарантировано должен быть списан товар, закупленный 31 числа (Поскольку по LIFO последние приходы списываются в первую очередь). С другой стороны – получается, что у нас отгрузка от 18 числа сопоставляется с приходом от 31ого – что выглядит как-то уж очень не интуитивно. Вот разработчики системы и реализовали эти два подхода, чтобы удовлетворить обе точки зрения. Первый из них – более правилен с бухгалтерской точки зрения , второй – с обывательской.

Теперь рассмотрим сопоставление в режиме "Средняя” и “Средняя на дату”. В давние былинные времена – до выхода версии Axapta 3.0 sp2 (В локализованной версии – этот service pack ,был выпущен под номером 3), в этом режиме КАЖДЫЙ расход периода сопоставлялся с КАЖДЫМ несопоставленным приходом (в случае Средней на дату – с каждым несопоставленным приходом, с датой меньшей или равной дате расхода). Получалось ,что если скажем у нас на начало месяца на складе уже лежали два несопоставленных прихода и еще 6 приходов пришло за месяц, то каждый из расходов (а их у нас, допустим было 40 штук) сопоставлялся с каждым из этих 8 приходов. В результате – у нас в таблице сопоставлений образовывалось 8*40*2 записей (на два результат умножен из за некоторых особенностей архитектуры сопоставления при которой на каждое сопоставление рождается две записи). Нетрудно сделать вывод, что такой рост таблицы не способствовал быстрому выполнению процедуры закрытия. Поэтому в Axapta 3.0Sp2 был реализован некий компромиссный вариант расчета средней себестоимости. Был введен порог для количества или суммы для каждого сопоставления. Грубо говоря - система, при сопоставлении каждого из расхода с приходами, начинает процесс с тех из несопоставленных приходов, у которых больше несопоставленное количество и стремиться сопоставить каждый раз не менее порогового количества. Если по данному приходу или расходу несопоставленным осталось меньше порогового количества – система сопоставляет столько, сколько осталось – независимо от порога. Пороговое количество может быть задано несколькими способами:
1. Можно указать минимальный процент сопоставляемого количества в параметрах закрытия. В этом случае – система будет стремиться сопоставлять в одном сопоставлении не менее чем N% данного прихода.
2. В поле “минимальное среднее количество” номенклатурной карточке
3. В поле "Минимальное среднее количество” параметров модуля управления запасами. Данный параметр работает только для тех номенклатур, у которых не указанное значение по пункту 2.
Наконец – существует еще один способ косвенно ограничить сопоставляемое количество: Указав при закрытии склада минимальную сумму сопоставления, можно заставить систему стремиться не создавать сопоставлений с суммой сопоставления (то есть – долей себестоимости прихода, сопоставленной с расходом в данном сопоставлении) меньше заданного порогового значения.
Таким образом – в обычных ситуациях (закупочная цена не очень сильно меняется за период, закупки происходят значительно реже, чем продажи), алгоритм расчета средней будет давать очень незначительные отклонения от истинной средней стоимости, рассчитанной, грубо говоря, с помощью Excel, делением себестоимости всех несопоставленных приходов на количество. Но если представить себе ситуацию при которой мы обычно закупаем за период 2-3 партии по тысяче штук, продаем несколько тысяч партий по 1-2 штуки, но почему-то в данном конкретном периоде мы внезапно закупили дополнительно одну партию из 5 штук по цене в два раза выше обычной, то есть большие шансы что те несколько расходов , которые будут сопоставлены с этой странной партией будут иметь завышенную себестоимость списания.
Особо отмечу, что при расчете себестоимости для сопоставления используется сальдо приходной проводки на дату закрытия. То есть – если мы закупили товар 15 числом, потом 25 числом доначислили накладные расходы на закупку, то при закрытии склада 20ым числом для расчета суммы сопоставлении будет использоваться себестоимость из исходной закупки – без суммы накладных расходов.

Прогон себестоимости

Итак – сопоставление и приходных и расходных проводок закончен. Истинная себестоимость посчитана. Зачем нужен какой-то дополнительный этап?
Представим себе, следующую ситуацию:
· 1 января закупили номенклатуру на сумму 2000 рублей
· 5 числа – перенесли ее на соседний склад. Очевидно, что мгновенная себестоимость расхода, а вместе с ней и себестоимость прихода на соседний склад составит 2000 рублей
· 10 числа – продали номенклатуру с соседнего склада. Мгновенная себестоимость списания опять-таки составит 2000 рублей
· 20 числа – на первоначальную закупку доначислили расходы за транспортировку в сумме 400 рублей
· Модель FIFO
Если мы закрываем склад 30ым числом, то система у нас сопоставит расход от 5 числа с приходом от 1ого и посчитает истинную себестоимость списания по складскому переносу, равную 2400 рублям. Естественно – возникает задача как-то добиться того, чтобы себестоимость прихода на соседний склад и себестоимость списания с такового по продаже также была скорректирована до 2400 рублей.
Эта задача решается следующим образом:
При любом обновлении расходной складской проводки, система проверяет – нет ли для данного списания, связанного с ним прихода? (Связанные приходы существуют для складских проводок списания, порожденных из журнала переноса;журнала карантинного заказа; заказа на перемещение; производственного заказа; журнала спецификаций. Кроме того – связанный приход существует для тех складских проводок прихода, у которых заполнен номер возвращаемого лота. ) Если данный расход действительно имеет связанный приход, то сумма коррекции записывается в таблицу “Коррекции уровня лота” (inventCostListTrans), вместе с номером лота связанного прихода и некоторой другой служебной информацией.
Далее на стадии прогона себестоимости, система считывает из этой таблицы информацию о корректируемых приходных проводках, проводит коррекцию себестоимости по этим приходным проводкам, а затем корректирует и себестоимости списания в расходных складских проводках, сопоставленных с корректируемой приходной проводкой. Если скорректированные подобным образом расходные проводки, в свою очередь также имеют связанные приходные проводки, то процесс прогона себестоимости повторяется.
Таким образом – процесс прогона себестоимости по сути, является итерационным. Фактически – система через таблицу складских сопоставлений строит граф движения материалов от их начального оприходования до окончательного списания, проходя при этом через все цепочки переноса и сборки номенклатуры.
Как определить число итераций прогона себестоимости, необходимое для полного закрытия склада ? Вопрос сложный. В теории – число итераций прогона себестоимости должно равняться максимальному числу переносов данной номенклатуры между разными складскими аналитиками через журнал переноса, плюс уровень вложенности спецификаций, плюс число переносов номенклатуры через журнал карантинного заказа и тп. В реальности – на число итерации кардинальным образом влияет наличие циклов в графе прогона себестоимости. Если их нет – закрытие отрабатывает за 5-7-10-15 итераций, если они есть, то время, требуемое для полной прогонки себестоимости становится труднопредсказуемым.
Почему в графе прогона себестоимости образуются циклы:
Представим себе следующую ситуацию
1 числа закупили 1 штуку номенклатуры по цене 200 рублей (зак1)
20 числа закупили еще 4 штуки - по цене 250 рублей (зак2)
Потом – задним числом провели 5ым числом перенос 2 штук со склада 1 на склад 2. (пер1)
Потом - задним числом перенесли 6ым числом эти две штуки обратно (пер2)
25 числа – все продали (зкз1)
Ну и наконец – 27ым числом доначислили 20 рублей накладных расходов на первую закупку.
Закрываем склад 31 числом по модели FIFO. Аналитика финансового склада - склад
До закрытия склада имеем следующую картину себестоимостей и количеств в проводках:

<...таблица в исходном сообщении...>

По итогам сопоставления по модели FIFO имеем следующую картину:

<...таблица в исходном сообщении...>

Обратим внимание на то, что у нас в грАфе прогона себестоимости образовался цикл: списание по первому переносу сопоставилось с приходом по второму переносу. А приход по второму переносу, в свою очередь зависит от списания по первому переносу. В поле "Коррекция” для приходов и расходов будет указана сумма коррекции себестоимости, накопленная на данной итерации закрытия склада. Посмотрим - к чему это приведет. Далее – каждая таблица будет соответствовать одной итерации прогона себестоимости:

<...таблица в исходном сообщении...>

Ну и так далее. Если бы у нас не было ситуации с переносом между складами при отсутствии товара на складе, то закрытие склада отработало бы за две итерации. В нашем же примере – на закрытие потребуется порядка 15-20 итераций. Кроме того – можно спрогнозировать, что в итоге у нас себестоимость списания по заказу так и не дотянет до правильного значения в 1270 рублей, при этом дельта будет списана с проводок по переносу в виде округления.
Таким образом, если возникла ситуация при которой в какой-то точке периода, за который мы закрываем склад, возникла ситуация отрицательного складского остатка, то это может привести к чрезмерно большому числу итераций по закрытию склада и недостаточной точности результата. Подробнее про причины этого явления написано в разделе "Почему возникает отрицательный складской остаток?”
Кроме того – стоит помнить, что при использовании модели средней себестоимости за период или на дату, у нас, в общем случае, КАЖДАЯ приходная проводка, сопоставляется с КАЖДОЙ расходной, соответственно - циклы в графе прогона себестоимости образуются даже если складской остаток не падал ниже ноля в течении закрываемого периода.
Поскольку ситуация, при которой закрытие склада длится неопределенно долгое время, случается, к сожалению не так уж редко, в процедуре закрытия склада имеются два параметра, которые позволяют явно или неявно ограничивать число итераций прогона себестоимости.



1. В параметрах закрытия склада имеется поле "максимальная пропускная способность”. Именно в этом поле и указывается максимальное число итераций, которое система может выполнить на стадии прогонки себестоимости. Если при выполнении процедуры прогонки себестоимости добрались до итерации, указанной в этом поле, то при выполнении этой итерации, коррекция себестоимости (пришедшая с предыдущей итерации в таблице InventCostListTrans) по данной приходной проводке не переносится на сопоставленный с данным приходом расход, а списывается с прихода на счет прибылей и убытков.
2. Также в параметрах закрытия склада имеется поле "Минимальная коррекция пропускной способности”. Если значение коррекции себестоимости, пришедшая с предыдущей итерации в таблице inventCostListTrans, меньше этого значения, то эта коррекция не переносится связанный с данным приходом расход, а просто списывается с прихода на счет прибылей и убытков. Хочу подчеркнуть, что этот параметр работает для КАЖДОЙ строки таблицы inventCostListTrans. То есть – если у нас в inventCostListTrans имеется три коррекции на 2,10 и 80 копеек, значение параметра "минимальная коррекция пропускной способности” установлена в 5 копеек, то списание в прибыли и убытки будет выполнено только для первой из коррекций. По остальным коррекциям итерации прогонки будут продолжаться.
Подробнее об списании коррекций – в разделе "О списании ошибок округления и корректировок при прогонке себестоимости.”

Разноска в ГК


Прежде всего, хочу отметить, что разноска в ГК выполняется только в том случае, если в параметрах закрытия склада была установлена галка "Обновить главную книгу». Смысла не устанавливать эту галку я не вижу, поскольку начиная еще с версии Axapta 2.5Sp1Hf1, разноска стала выполняться достаточно быстро по сравнению со всеми остальными этапами закрытия склада и отключение этой галки не приводит к серьезному повышению быстродействия этой процедуры.
На предыдущих этапах закрытия склада была заполнена таблица складских сопоставлений (InventSettlement) в которой помимо собственно сопоставленных количеств, сопоставленных сумм и сумм коррекций находится также информация, необходимая для создания бухгалтерских проводок по выполненной коррекции – счет, коррсчет, аналитика, разноска для счета и коррсчета. Поэтому процедура разноски закрытия склада работает достаточно просто. Она группирует суммы коррекции в разрезе этих бухгалтерских параметров, а потом делает соответствующие проводки в ГК. Поэтому – нет особой необходимости в процедуре, которая бы позволяла выверять проводки в ГК по закрытию склада со складскими проводками. Вся информация по счетам аналитикам и тп находится в таблице складских сопоставлений. Если у вас при закрытии склада сгенерировались проводки в ГК с какими-то неожиданными аналитиками или счетами – ищите эти счета и аналитики в таблице сопоставлений. Ну а из этой таблицы уже можно перейти к исходным складским проводкам и попытаться понять – на основании каких операций были сгенерированы эти странные проводки.
Кроме того – на разноску влияет параметр процедуры закрытия склада, называющийся спецификация. В оригинальной (нелокализованной) версии DAX, этот параметр позволял процедуре разноски группировать проводки не только по бухгалтерским параметрам, но и по коду номенклатуры, по которой была выполнена коррекция или коду ее номенклатурной группы. То есть – даже если операции с разными номенклатурами породили коррекции с одинаковыми аналитиками, счетами и корсчетами, в ГК эти коррекции попадали двумя отдельными проводками. К сожалению – этот режим оказался несовместимым с механизмом корреспонденции счетов, используемым в российской версии DAX. Поэтому – если режим корреспонденции счетов включен, то группировка проводок по номенклатуре или номенклатурным группам невозможна. У меня этот факт не смущает, , поскольку, как я уже сказал, выверять проводки в ГК по процедуре закрытия гораздо удобнее и легче с помощью таблицы складских сопоставлений (inventSettlement).
О параллельном закрытии склада с нескольких рабочих мест.


Наиболее значительным изменением в процедуре закрытия склада со времен выхода первой локализованной версии 2.1 в 2000ом году, стала реализация параллельного закрытия склада с нескольких рабочих станций впервые выпущенная в составе международного Service Pack 2 для Axapta 3.0. На мой взгляд - если до выхода этого пакета обновления низкая производительность процедуры закрытия склада иногда становилась неразрешимой проблемой, то с его выходом – большая часть проблем производительности была снята.
Итак – рассмотрим процедуру закрытия склада в многопользовательском режиме поподробнее:
Того клиента DAX, на котором была первоначально запущена процедура закрытия склада мы в дальнейшем будем называть мастер-клиентом. Всех остальных клиентов – клиентами – помощниками. Напомню, что запуск клиента-помошника выполняется нажатием кнопки Рассчет->Помошь в расчете. При этом в списке закрытий склада должно быть выбрано незаконченное закрытие склада.
В момент запуска процедуры закрытия склада на мастер-клиенте, он записывает параметры закрытия склада в таблицу “Закрытие запасов” (InventClosing) для того, чтобы эту информацию могли бы потом использовать клиенты-помощники. После этого мастер-клиент пишет в таблицу “Список рассчета”(inventCostList) коды той номенклатуры, по которой имеются незакрытые операции. Далее – и мастер-клиент и клиенты-помошники начинают сопоставлять открытые складские проводки по каждой из номенклатур, попавших в эту таблицу. Данный процесс считается нулевой итерацией закрытия склада. Как я уже написал в разделе "Прогон себестоимости”, во время сопоставления, система порождает записи в таблице InventCostListTrans, которые в дальнейшем будут использоваться для итераций прогона себестоимости. Надо сказать, что если в таблицу inventCostListTrans попала хотя бы одна запись для некоторой номенклатуре, то запись об этой номенклатуре попадает также и в таблицу InventCostList. Это необходимо для координации совместной работы нескольких клиентов на стадии прогона себестоимости.
На стадии прогона себестоимости, система действует по похожему алгоритму. Каждый клиент бежит по таблице InventCostList и по каждой из попавших в эту таблицу номенклатур обрабатывает коррекции себестоимости (прогоняет их по графу сопоставлений), попавшие в таблицу inventCostListTrans на прошлой итерации закрытия склада.

Разноска закрытия склада в ГК выполняется только с мастер-клиента.

Если во время выполнения закрытия склада нажать кнопку Рассчет->Останов расчета, то закрытие склада будет приостановлено. После этого можно будет повторно нажать кнопку Рассчет->Помощь в закрытии склада и закрытие склада будет продолжена. В этом случае – мастер-клиентом станет тот клиент, который первый присоединится к незавершенной процедуре закрытия склада.
Если вы используете при параллельном закрытии склада больше 2-3 клиентов, то стоит контролировать загрузку сервера БД и AOS. После того как одна из них добралась процентов до 60-70, подключать к закрытию новых клиентов уже не имеет смысла. Кроме того, опыт показывает, что хотя классы закрытия склада выполняются на клиенте, с одной рабочей станции можно запустить 2 или даже 3 клиента, поскольку часть времени они не создают нагрузку на процессор, поскольку ждут завершения операции на AOS или БД. Хочу также заметить, что на стадии сопоставления система создает значительно бОльшую нагрузку на сервер БД чем на стадии прогонки себестоимости. Поэтому – до момента начала прогонки себестоимости не стоит подключать к процедуре закрытия склада слишком большое количество клиентов.

Хотя авторы системы многопользовательского закрытия склада предназначали таблицы inventCostList и inventCostListTrans исключительно как некий внутрисистемный инструмент для взаимодействия между несколькими клиентами, в качестве побочного эффекта – эти таблицы являются прекрасным инструментом для мониторинга процесса закрытия склада. Поэтому прежде чем приступить к обсуждению того, как этот процесс мониторить – давайте посмотрим структуру данных таблиц:

<...таблица в исходном сообщении...>


Самый правильный способ мониторить закрытие склада –сразу после того как это закрытие было запущено, открыть в соседнем окне еще одного клиента DAX и залезть с помощью браузера таблиц в таблицу inventCostListTrans
Если отсортировать записи в этой таблице по номеру итерации, то сразу можно увидеть - какая итерация у вас сейчас идет. Как правило, при сколько-нибудь серьезной логистике, меньше чем итераций за 5-7 склад просто не закрывается. Если у вас склад закрывается за меньшее время, то скорее всего проблемы производительности этой процедуры вас просто не волнуют и вы можете пропустить остаток этого раздела. В течении этих самых первых 5-7 итераций, количество записей в таблице inventCostListTrans резко падает (обычно – с нескольких тысяч до пары сотен или даже нескольких десятков). После того, как эти итерации прошли – есть смысл начинать пристально следить за содержимым этой таблицы. Допустим – вы заметили пару лотов, по которым коррекция себестоимости в поле adjustment с каждой итерацией падает как-то уж слишком медленно. Скажем – если коррекция равняется 600 рублям и с каждой итерацией она уменьшается всего на 10 копеек – самое время попытаться понять – не случилось ли по данной номенклатуре какой-то беды с данными. Скорее всего – причина такого медленного прогона себестоимости состоит в том, что у вас остаток по данной номенклатуре в какой-то точке закрываемого периода падал ниже ноля, в результате чего в грАфе прогона себестоимости образовался цикл. Что делать в подобной ситуации ?
Если вы перфекционист или сумма прогоняемой коррекции как-то уж слишком высока (скажем – 6000 при месячном объеме продаж в 6000000), то нужно записать номера проблемных лотов на бумажку, после чего остановить процедуру закрытия склада, отменить незавершенное закрытие склада и начать разбираться с проблемными лотами. Если вы нашли ситуации отрицательного остатка, то нужно их аккуратно отсторнировать, примаркировать (или указать номер возвращаемого лота)неправильное списание к его сторно и попробовать повторить попытку закрытия склада. (Про маркирование и номера возвращаемых лотов подробнее написано в разделе "О возвратах”
Если же вы обнаружили что сумма прогоняемой коррекции небольшая по сравнению с оборотами за период (допустим 500 при обороте в 50000000, то можно просто подкорректировать (в браузере таблиц) поле MinTransferValue в таблице InventClosing. Это то самое поле, в котором хранится максимальная коррекция пропускной способности, заданная вами в начале процедуры закрытия склада. Если вы укажете там значение, большее чем максимальная из оставшихся в прогоне коррекций, то но очередной итерации прогонки себестоимости, зависшие коррекции просто будут списаны на счета прибылей и убытков. На реальный финансовый результат фирмы это не повлияет, но может слегка подпортить картину прибыльности (или убыточности) отдельных продаж.
Вот почему так важно, чтобы оценочная себестоимость списания не слишком сильно отличалась от истинной себестоимости. Ведь если разница была слишком большой, то в случае образования циклов в графе прогонки себестоимости, каждые несколько дополнительных рублей разницы могут обойтись вам в несколько минут дополнительного времени закрытия.
Кроме того, могу посоветовать разработать какой-нибудь отчет, который пробегал бы по открытым проводкам и выдавал сообщение о переходе остатка через ноль. Если вы будете запускать подобный отчет перед каждым закрытием, то у вас появится возможность привести данные в порядок, без необходимости ждать пока закрытие доберется до 20ой итерации.
В заключение хочу отметить, что существуют определенные ситуации, в которых переход остатков через ноль вызван не ошибками в вводе данных, а объективной спецификой бизнеса. В таком случае – единственный способ бороться с производительностью закрытия склада - это корректировка поля MinTransferValue, о которой я писал чуть выше. Конечно – в этом случае мы не сможем получить корректную себестоимость списания по каждой складской проводке, но по большому счету, в такой ситуации эта себестоимость и не будет иметь особого экономического смысла.

О пересчете склада


. В DAX имеется не только процедура закрытия склада, которая расчитывает окончательную себестоимость списания по каждой складской проводке за период (блокируя при этом дальнейшие складские движения в этом периоде), но и процедура пересчета склада. Эта процедура отличается от закрытия склада следующим образом:
1. Сопоставление приходов и расходов строится “в памяти”, то есть – данные о сопоставлении приходов и расходов не записываются в таблицу складских сопоставлений.
2. В случае необходимости корректировки себестоимости по расходной или приходной проводке, запись в inventSettlement создается, но в ней не заполняются сопоставленные количества и суммы. Происходит заполнение только суммы коррекции.
3. Как следствие первых двух пунктов –перед КАЖДОЙ итерацией прогонки себестоимости происходит операция сопоставления "в памяти” приходных и расходных проводок. Это логично – ведь если мы не пишем в таблицы БД данные о сопоставлении, то перед каждой прогонкой себестоимости нам нужно заново создать в памяти данные о сопоставлении, чтобы понять – с каким расходом сопоставлен корректируемый на данной итерации приход.
4. Можно проводить пересчет склада по отдельной номенклатуре или номенклатурной группе. Нужно только помнить о том, что если данная номенклатура списывалась по журналу спецификаций или журналу производства, то коррекция может затронуть и ту номенклатуру, в производство которой была списана данная номенклатура.
5. В отличие от закрытия склада – система не списывает при пересчете склада погрешности округления.
Если мы хорошенько подумаем о смысле 3 пункта, то можно сделать вывод о том, что пересчет склада будет почти гарантировано работать медленнее, чем закрытие. Ведь перед каждой итерацией прогонки себестоимости, мы вынуждены заново проходить стадию сопоставления приходных и расходных проводок. Мы конечно сэкономим немного времени за счет того что мы не тратим на каждой итерации время на запись данных по сопоставлению в таблицу БД, но скорее всего – сэкономленное время будет с лихвой перекрыто дополнительным временем, нужным на повторяющееся сопоставление.

Партионная себестоимость


Нигде в Dynamics AX нет специальной настройки для включения режима партионной себестоимости. Тем не менее – если в настройках группы складских аналитик поставить галку "Финансовый склад" для складских аналитик "Номер партии" или "Серийный номер", то при закрытии склада по ЛЮБОЙ модели мы и получим режим партионной себестоимости, поскольку сопоставление приходов и расходов будет идти только в рамках одного номера партии или серийного номера. Разумнее всего, для той номенклатуры, у которой включен партионный учет, ставить модель закрытия склада по FIFO, поскольку с технической точки зрения она быстрее всего работает.
Один лот – одна себестоимость


Архитектура модуля расчета себестоимости в DAX неявным образом предполагает что элементарной единицей списания или приходования себестоимости является один складской лот. То есть – даже если по одному лоту у нас имеется несколько строк в таблице складских проводок, при расчете с себестоимости система все равно будет считать все себестоимость по лоту в целом.
С первого взгляда – подход логичный, но он содержит в себе некую ловушку, в которую регулярно попадают начинающие внедренцы. Допустим – мы включили по одной из номенклатур партионный учет (включаем нужную галку в настройках групп складской аналитики) и у нас имеется две партии товара по 10 рублей (2шт) и 15 рублей (3шт).
Далее, создаем журнал переноса на 5 штук. Как известно, если мы не указали в настройках групп складской аналитики номер партии, как первичную аналитику, то мы можем не вводить номер партии в строки журнала переноса. При выполнении резервирование по такому журналу, система автоматически разобьет приходные и расходные складские проводки, подставив в каждую из них нужный номер партии. Это удобно для пользователей, поскольку позволяет им не задумываться над подбором номера партии, если в данной ситуации нас не волнует то, какие именно партии будут списаны.
Только вот после разноски такого журнала, мы обнаружим, что во всех приходных проводках стоит одинаковая цена - 13 рублей. В момент разноски журнала, система использует себестоимость списания ЛОТА с первого склада в качестве себестоимости прихода на второй склад. Себестоимость списания лота с первого склада – 65 рублей. Соответственно – при расчете себестоимостей прихода по двум складским проводкам данного лота будет использоваться эта сумма, которая будет распределена между приходными складскими проводками пропорционально их количествам. Закрытие склада не исправит ситуацию, поскольку коррекция себестоимости в таблице InventCostListTrans также привязана к номеру лота, соответственно – на стадии закрытия коррекция будет распределена по приходным проводкам пропорционально их количествам. Вот именно в такой ситуации и возникают жалобы на тему "Аксапта испортила мою себестоимость".
Когда я первый раз столкнулся с подобной ситуацией, я с наскока пытался решить ее, переделав процедуру разноски журнала переноса и закрытия склада. Только вот оказалось, что не очень понятно – как решать эту задачу в общем случае. Например – мы ведь можем по переносу списывать несколько партий и создавать из них одну. Как мы вообще должны обрабатывать ситуацию, при которой у нас в результате переноса меняется не только аналитика физического склада (например - склад или номер ячейки), но и аналитика финансового склада?
Возникновение подобной ситуации, говорит о попытке решить бизнес-проблему айтишным путем. Ведь если вдуматься – ситуация абсурдная: С одной стороны - бухгалтерия пытается вести партионный учет. С другой стороны – бизнес-процессы организованы так, что логистики не знают или не хотят знать – какой номер партии им подставлять и пытаются добиться, чтобы эти номера система подставляла автоматически. В такой ситуации, существует два варианта решения проблемы:
1. Можно настаивать на том, чтобы пользователи вводили номера партий в ручную. В такой ситуации спонсор проекта со стороны заказчика должен жестко разъяснить пользователям – почему так важна партионная себестоимость.
2. Можно настаивать на том, чтобы бухгалтера перешли на использование модели FIFO. Если уж все так хотят чтобы система автоматически подставляла номера партий – так пусть и подставляет. Если аналитика "Номер партии" не будет указана как аналитика финансового склада, то после закрытия склада мы и получим информацию, связывающую расходы с номерами партий в приходах. Только в данной ситуации у нас в складской аналитике расходных проводок не будет номеров партий; Нам придется собирать эту информацию из таблицы складских сопоставлений, связывающей расходы с приходами.
Складские сопоставления и как с ними работать.


В данном разделе пойдет речь о таблице складских сопоставлений (inventSettlement). Строго говоря – использование термина "сопоставление” (Settlement) в названии этой таблицы, поскольку, эта таблица несет двоякий смысл: она может описывать и сопоставление прихода с расходом, и коррекцию себестоимости. Хотя для расходных складских проводок коррекция себестоимости ВСЕГДА порождается на основании сопоставления, для приходных складских проводок коррекция себестоимости происходит совершенно независимо от сопоставления с расходными. Кроме того – если коррекция себестоимости расхода делается на основании пересчета, а не закрытия склада, то коррекция себестоимости будет помещена в эту таблицу без данных о сопоставленном количестве. Давайте внимательнее рассмотрим список полей этой таблицы:

(...таблица в исходном сообщении...)

При выполнении закрытии склада информация о сопоставлении заносится в эту таблицу следующим образом: и для сопоставляемого расхода и для сопоставляемого прихода создается запись в таблице складских сопоставлений, при этом поле SettleTransId у этих двух записей будет одинаковым.
В случае коррекции себестоимости прихода (например – при разноске накладных расходов по накладной или переоценке складских запасов) – создается одна запись. Аналогичным образом – одна запись создается и при коррекции себестоимости расходных проводок (при пересчете склада).
Поля, связанные с разноской в ГК заполняются информацией из таблицы складской разноски (InventTransPosting), связанной с корректируемой (сопоставляемой) складской проводкой. Если запись в этой таблице по каким-то причинам отсутствует – в качестве складского счета берется счет складского прихода или расхода из таблицы настроек складской разноски по данной номенклатуре, в качестве корсчета – счет прибылей и убытков из той же таблицы. Отмечу что в саму таблицу inventTransPosting информация попадает из финансовой аналитики исходного документа и остается в данной таблице даже если этот документ удален.
Надо сказать – что далеко не всегда коррекция себестоимости приводит к необходимости делать проводки в ГК. Скажем – при коррекции себестоимости прихода или расхода по журналу переноса никакой проводки в ГК делать не надо – поскольку по исходному журналу – такой проводки тоже не было. Этот момент отслеживается с помощью поля isPosted в таблице InventTransPosting. Если данное поле не было установлено в true, то счета и корсчета в inventSettlement не заполняются и подсистема разноски сопоставлений в ГК эти коррекции/сопоставления игнорирует. Так что если вы занимаетесь выверкой проводок в ГК по закрытию с себестоимостью, то следует игнорировать записи с пустыми счетами и корсчетами. Наконец – хочу уточнить что поле posted в таблице inventSettlement не имеет никакого отношения к факту разноски или неразноски данного сопоставления(коррекции) в ГК. Это поле заполняется в момент обработки сопоставления классом разноски сопоставлений в ГК и говорит только о том, что эта запись была обработана этим классом.
Немного о складских проводках

(...таблица в исходном сообщении...)

....

Еще: http://blogs.technet.com/denisfed/ar...23/705202.aspx

[EVGL]

Гениально. Жаль только, что по-русски.

[mazzy]

Цитата:

Сообщение от Blog bot

Партионная себестоимость

Нигде в Dynamics AX нет специальной настройки для включения режима партионной себестоимости. Тем не менее – если в настройках группы складских аналитик поставить галку "Финансовый склад" для складских аналитик "Номер партии" или "Серийный номер", то при закрытии склада...

Приношу свои извинения, что влезаю.
Обычно про "партионный учет" приходится объяснять 1Сникам.
Но похоже путаница с партионным учетом распространилась за пределы 1С.

Итак, когда 1Сники говорят о "партионном учете", то под этим термином может пониматься две совершенно разные вещи (и эти вещи зачастую смешиваются при разговоре с клиентами. Причем специалисты 1Сники моего поколения знают о том, что партионных учетов несколько (не знаю как новое поколение 1Сников). После общения с 1Сниками заказчики задают вопросы, ответы на которые выливаются в целые лекции.

Так вот:
Когда 1Сники говорят о "партионном учете", то под этим термином может пониматься две совершенно разные вещи.
1. Финансовые партии.
2. Физические партии.

Финансовые партионный учет - это учет по финансовым приходам.
Термин "партионный" учет в 1С:Бухгалтерии означает всего лишь FIFO-LIFO. Термин "партионный" учет противопоставляется учету "по-среднему". Не больше.

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

Физическая партия может быть закуплена разными финансовыми документами, и даже у разных поставщиков. Но партия все равно будет одна.

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

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

===============
Несколько слов о серийном номере.
К сожалению, здесь терминология 1С снова приводит к определенной путанице.

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

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

и т.п. и т.д... текста на полчаса с диаграммами.
=================

Краткое резюме:

1. То, что 1С называет Партионным учетом, в Аксапте есть всегда при любой модели списания, при любых галочках в настройке складской аналитики
2. То, что в Аксапте назывется Партионным учетом, в 1С называется "Серийным учетом"
3. То, что в Аксапте называется учетом по Серийным номерам, в 1С вручную эмулируется тем же самым "Серийным учетом"

Партионно/серийный учет в этих двух системах сильно отличается по идеологии и по возможностям настройки. Но самое главное: знайте, что при разговоре о партионном учете всегда надо уточнять какой именно партионный учет подразумевается в вопросе.

[raz]

Цитата:

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

Гениально. Жаль только, что по-русски.

Здорово что по русски!!!

Я понимаю, что DAX интернациаональная система и многие наши блоггеры смотрят в сторону запада (возможно в надежде туда уехать) и пишут свои статьи по "аглицки". Но, ИМХО, если ты знаешь "великий и могучий", то повтори свою статью на нем, хотя бы из уважения к тем кто тебя учил, и в помощь тем кто останеться тут.

[mazzy]

Цитата:

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

Гениально. Жаль только, что по-русски.

Типун тебе на язык!
Спасибо огромное, что по-русски!

[fed]

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

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

[mazzy]

Спасибо, что появился.
Мегареспект за статью о себестоимости.

[Maxim Gorbunov]

fed, спасибо за статью. Соглашусь с EVGL в том, что она бы и на английском была хитом (особенно в свете открытия нового коммьюнити для финансовых аналитиков, работающих с Dynamics).

Цитата:

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

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

Если хотите, я готов с терминологией помочь. Могу также немного помочь с переводом, но учтите, что я не профессиональный переводчик

[Exus]

Денис, спасибо! Здорово структурировал все знания! У меня теперь тоже некоторые моменты, которые понимал интуитивно, разложились по полочкам! Пятерка!

[EVGL]

Да, я тоже готов помочь с переводом, если автор согласен. Мне все равно к одному экзамену готовиться надо, так пусть хоть польза будет. За первые выходные готов перевести первые три "главы" (до "Прогона себестоимости").

[fed]

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

[Morpheus]

Еще: http://blogs.technet.com/denisfed/ar...23/705202.aspx

Ссылка не работает...

[EVGL]

Цитата:

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

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

OK. Займусь.

[Gustav]

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

P.S. Нашёл приемлемое решение: таблицы итераций 1-6 кинул копипастом в Excel и распечатал отдельно. Оказалось, что там еще самая правая колонка "Склад" есть (не видел ее даже в браузере).

[kashperuk]

Цитата:

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

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

P.S. Нашёл приемлемое решение: таблицы итераций 1-6 кинул копипастом в Excel и распечатал отдельно. Оказалось, что там еще самая правая колонка "Склад" есть (не видел ее даже в браузере).

ЭЭ. а ты отсюда чтоли печатал?
http://blogs.technet.com/denisfed/ar...23/705202.aspx

[longson]

Ну в WORD не помещаются все картинки - особенно это касается картинок 6 итераций сопоставления проводок.

Но ЗДОРОВО что они все находятся рядом друг с другом. Поэтому если с целью печати предлагаю вариант файла WORD без этих 7 картинок, которые перемещены в Excel чтобы можно распечатать в виде альбома. Получится

[Gustav]

Цитата:

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

ЭЭ. а ты отсюда чтоли печатал?
http://blogs.technet.com/denisfed/ar...23/705202.aspx

Ну да. А откуда надо было? Я сначала взял всё в Word (я люблю абзацы с выравненными левым и правым краями), но там таблицы победить не удалось. Поэтому печатал с сайта, причём в landscape. Но когда и там таблицы оказались не полностью, то победил их Excel'ем.

[EVGL]

Ок, первая часть готова. Предоставляется по принципу open source. Это значит, если бросятся в глаза ошибки - сообщайте.

What it’s all about?

I have been talking to consultants and developers working with DAX and I know that the issues regarding inventory closing and stock cost calculation have become one of the most severe at the majority of the implementation projects. One treats the inventory closing as a ‘black box’ delivering various results in different times depending on a phase of the moon. In my opinion, this is caused by the lack of information, which is dispersed across the whole documentation. Furthermore, some tricks of this procedure are not described at all and need to be discovered on the cut-and-try principle or by studying the source code of the inventory closing.

In this article I’m trying to explain in detail how this procedure works and to guide through some other issues related to cost calculation. One part of the content has been collected from different documents about DAX; another captures my own experience gathered while working with Axapta 3.0 and reverse-engineering its source code. I haven’t verified everything in the version 4.0 but - according to my analysis of the source code – the algorithm hasn’t been changed significantly.

This document is addressed to experienced consultants and software architects with DAX (former Axapta) who have questions about the topic being discussed. The reader should comprehend the basic ideas behind the Trade and Logistics module and should have already tried to complete an inventory closing.

Why do we need inventory closing?

The primary goal of inventory closing is to calculate the true prime cost of an outward inventory movement (a so-called inventory issue). DAX works with the cost price the following way: at the moment of an inventory issue the system doesn’t try to derive the precise cost of this movement in accordance with the inventory model. The system books instead an estimated value which more or less resembles the real prime cost (read more about it in the chapter ‘Instant cost of issues’).

After all, the real cost is figured out during an inventory closing session according to the inventory model settings. Having calculated the cost, the system derives an adjustment which is a difference between the previously estimated cost and the real one. This adjustment is saved in the inventory transaction table and booked in the General Ledger.

Why it’s done this way? Generally speaking, at the time of an outward movement the system doesn’t necessarily have all data needed to compute the true cost. For example, with the ‘negative inventory’ turned on we can sell items even before they come to our warehouse. Moreover, with the model ‘Weighted Average [per period]’ it’s impossible to calculate the cost price before all stock arrivals have been booked; with the model ‘LIFO’ we cannot assess an issue cost until the last arrival in the period hasn’t been registered, and so on.

Several times novice consultants came to me and asked to customize the system, to let accountants enter a cost price directly into a voucher and to prevent AX from interfering and re-calculating costs in such operations. Well, this approach contradicts carelessly the ideology and the architecture of the inventory closing in DAX. Cost price must always be determined by reconciliation of item issues (outward movements) with receipts (inward movements).

After the system has calculated inventory cost for a particular period any subsequent movements are prohibited in that period. It makes sense because the insertion of new receipts and issues in behindhand might lead to inconsistency in existing settlements and corrupt the prime cost. If we only need to momentarily estimate the cost price of issues in their current state without preventing new inventory movements from being posted, we can just start a recalculation procedure instead of a closing.

The inventory closing as it is consists of the following steps:
1. Reconciliation of issues and receipts, calculation of an initial issue cost price;
2. A run through the graph of all inventory movements with adjustments being worked out;
3. Booking in the General Ledger.
Let’s consider each of these steps in detail.

Reconciliation of receipts with issues

Calculation of true issue cost price is always done in AX on the basis of settlement of issue inventory transactions with receipt transactions. Settlement may not be applied across different item codes or across different ‘financial’ inventory dimensions.
Legitimacy of this approach for the models FIFO and LIFO can be easily proven. For example, if we bought 2 pieces per 10 Euro and 5 pieces per 14 Euro each and than sold 3 pieces, the prime cost of the issue comprises [on the FIFO model] 2 pieces from the first receipt (20 Euro in total) and one piece from the second (14 Euro more). Consequently, the total issue cost of 3 pieces equals 34 Euro.

I will proceed using the terms settled quantity and settled amount. A settled amount is a multiplication of a receipt’s cost price and a settled quantity from a receipt. Of course, the settled amount is rounded according to the setting in the currency master table.
The principle of reconciliation on the model FIFO is trivial and doesn’t require further explanation. The only feature to mention is that the system ignores history of issues and receipts. I. e. if wares were bought on the 15th and sold on the 5th, the two movements would be mutually settled by FIFO in assumption that there were no other receipts. Usually it doesn’t make sense. This phenomenon of a ‘negative on-hand inventory’ is explained at greater length in the chapters ‘Why do we have a negative on-hand’ and ‘Cost price run’.

The models ‘LIFO’ and ‘LIFO date’ in DAX should be better called LILO (Last In – Last Out). They act like the FIFO but exactly the opposite way around. The system goes through a list of unsettled receipts beginning from the very last and reconciles them with last issues, respectively. The ‘LIFO date’ differs in the way how the receipts are chosen. It takes only those receipts which existed at the time of a particular issue movement. Co-existence of these two models can be explained on the following example. Imagine you buy wares on the 1st, 5th and 31st and sell on the 10th and 18th. On the one hand, according to the strict accounting principle of LIFO you must sell 31st‘s wares because the last receipts are to be taken first. On the other hand, the sale from the 18th is going to be settled with the purchase from the 31st, which is somehow illogical. That’s why developers of the system have implemented the both principles. The first one is correct from an accountant’s point of view; the second is in line with common sense.

Now let us consider the reconciliation models ‚Weighted average’ and ‚Weighted average date’. Long time ago, in the ages before the version Axapta 3.0 SP2, EACH issue in a period was reconciled with EACH open receipt (or with each receipt before and including the issue’s date in case of the model ‘Weighted avg. date’). That is, if we had 2 unsettled receipts by the beginning and got 6 more in the course of a month, each issue would be settled against all the 8 receipts. Given 40 issues, this would result into 8*40*2 settlement transactions (the factor of 2 is determined by the architecture of the module which needs 2 transactions per one pair of settled movements). It’s not surprising that this exponential growth didn’t favour the performance of the closing routine. As a result, in the Axapta 3.0 SP2 they implemented some compromise algorithm of weighted average. Thresholds for the settled quantities and amounts were introduced. The system takes bigger receipts first in order not to settle less than the given threshold quantity. If a particular receipt or issue still has an open quantity less than the threshold, it is settled regardless of the threshold.

The threshold quantity can be applied in several ways:
1. You can specify a ‚Minimum percent’ directly in the form of the closing procedure. The system tries to settle not less than the given percent part of the receipt’s quantity.
2. You can enter a ‘Minimum average quantity in the item master table.
3. You can pre-define a ‘Minimum average quantity’ in the Inventory module parameters for those items which don’t have any setting in the master table (see the option 2).

There is another implicit method to limit the settlement quantity by specifying a ‘minimum average amount’ in the inventory closing form. This will encourage the system not to make settlements with an amount less that the given threshold.

This model does well in usual business cases, which means, if the purchase price doesn’t vary too much and if purchases happen relatively rarely compared to sales. In this case the approximating algorithm produces very insignificant deviation from the real cost price computed, for example, in Excel by dividing the whole cost of the unsettled receipts by their total quantity. Nevertheless, assume we procure on regular basis 2-3 batches a month with 1000 pieces each and sell thousands of batches per 1-2 pieces each. If we’ve suddenly got additional 5 pieces twice as expensive as usual, there is a chance to get a higher cost for a couple of sales which happen to be settled against this extra purchase.
At the end I have to point out that receipt transactions are valued on the closing date. If we bought wares on the 15th and allocated some miscellaneous changes on the 25th, an inventory closing performed on the 20th won’t take the correction into account and will use original price from the purchase.

[fed]

Update: Выяснилось, что в версии 4.0sp1 изменился подход к списанию ошибок и округлений при закрытии. До этой версии - они списывались на коррсчета приходов, а с выходом sp - начали списываться на счета прибылей и убытков. Исходный текст статьи обновил.

[Maxim Gorbunov]

Для начала, чисто грамматические и фактические правки :

• "Why it’s done this way? " --> "Why is it done this way?"
• "the model ‘Weighted Average [per period]’" --> "the 'Weighted average [date] model"
• "the model ‘LIFO’" --> "the 'LIFO' model"
• "until the last arrival in the period hasn’t been registered" --> "until the last arrival in the period has been registered"
• "and to prevent" --> "and prevent"
• "the insertion of new receipts and issues in behindhand might lead to inconsistency in existing settlements and corrupt the prime cost" --> "inserting behindhand receipts and issues might cause the inconsistency of existing settlement and corrupt the prime cost"
• "start a recalculation procedure instead of a closing" --> "start the recalculation procedure instead of the closing" (речь о вполне определенных функциях, а не о процессе, по-моему)
• "The inventory closing as it is consists of the following steps:
  1. Reconciliation of issues and receipts, calculation of an initial issue cost price;
  2. A run through the graph of all inventory movements with adjustments being worked out;
  3. Booking in the General Ledger.
  Let’s consider each of these steps in detail."
  -->
  "So the inventory closing is combined of the following steps:
  1. Reconciling issues and receipts, calculating initial issue cost price;
  2. Traversing through the inventory movements and adjusting the cost price of single transactions;
  3. Booking the adjustments to GL.
  Let’s elaborate on each of these steps."

Уф... Последний абзац чуть попозже.

P.S.: А может нам какую-нибудь Wiki-страницу для этого дела организовать, чтобы можно было править текст, и правки при этом были хорошо видны?