Закрытие склада за 7 лет...

[fed]

Отвечу по шагам. В текущей (2009RU7) версии аксапты есть два подхода к принудительному (без нормального сопоставления и рассчета себестоимости) закрытию проводок:

1. Услуги. В версии 4.0sp1, появилась специальная ветка (inventCostItemDim,updateServiceItemTrans()), которая принудительно закрывает складскип проводки по услугам. Закрывает она их по умному, заполняя сопоставленное количество, сопоставленную сумму и создавая в складских сопоставлениях запись специального типа (InventSettletModel::ServiceItem). Из за того что все эти поля заполняются и запись сопоставления создается, такая проводка для всех (ну или почти всех) стандартных и нестандартных отчетов выглядит как закрытая и сопоставленная 'по честному'
2. Нефинансовые переносы. В DAX2009RU7 отбэкпортили из DAX2012 фичу, которая позволяет при закрытии игнорировать нефинансовые переносы (то есть - проводки переноса у которых у прихода и расхода одинаковые складские аналитики финансового склада). При этом такие проводки помечаются как закрытые 'по грубому'. То есть - просто тупо у проводок ставится признак закрытия и дата закрытия (и еще в некое совсем новое поле вешается ссылка на запись в inventClosing по закрытию). Из за этого, по моим ощущениям, заметная часть складских отчетов на такие проводки будет плохо реагировать. По крайней мере часть моих самописных отчетов - точно будет плохо реагировать. Когда я по поводу этого подхода высказал некоторые сомнения в уже упомянутой дискуссии, участник Ievgenii, написал что "Наши ПМы убедеждены что этого делать не надо, чтобы не терять времени. По-этому для не финансовых переносов убрали. Для услуг - это легаси код, который не меняли." Я так подозреваю, что под термином "Наши ПМы" скрывался конкретно Anders Girke, ответственный за костинг в Аксапте

Теперь о твоей конкретной ситуации: Во первых - со своим советом насчет того чтобы подхакать закрытие чтобы считало всю номенклатуру сервисами - я был не прав. Дело в том, что у тебя тогда ВСЕ проводки пометяться как закрытые, а задача состоит в том чтобы пометить как закрытые только те проводки, которые НЕ ВХОДЯТ в текущий остаток. Соответственно у тебя есть два подхода к решению проблемы:
1. Написать собственную процедуру закрытия. Просто надо бежать по текущим складским остаткам в разрезе аналитик финансового склада и для каждой комбинации аналитик отсчитывать назад от текущей даты достаточно складских проводок в статусе "Закуплено" чтобы покрыть текущий складской остаток. Затем все остальные складские проводки надо пометить как закрытые (с использованием кода inventCostItemDim.updateServiceItems() как прототипа). Да - еще замечу что если у тебя в складских остатках, допустим 5 штук, а приходная проводка на 12, то тебе надо ее рассплитить на две проводки по 7 и 5 штук, первую закрыть, а вторую - оставить. Я бы лично пошел по этому пути.
2. Если ты не чуствуешь себя достаточно увереным для варианта N1, по прежнему можно пойти по пути обычного закрытия склада. Я бы, к рекомендациям mazzy, сделал такие поправки:

• Ставьте модель FIFO - она самая быстрая.
• Поскольку себестоимость вам не важна, поставьте максимальное число итераций в 1. Тогда у вас на нулевой итерации все проводки сопоставяться и закроются, а на первой итерации вся зависшая себестоимость спишется на прибыли и убытки.
• Можно закрывать склад ЗА ВСЕ ВРЕМЯ, но вам понадобится очень много хелперов. В принципе, если ты за все время склад закрываешь, то ограничивающим является только память, в которую система загружает сразу все проводки по данной номенклатуре и аналитике для сопоставления и прогонки коррекции. Чтобы оценить то, сколько времени займет закрытие одной номенклатуры в худшем случае (и чтобы посмотреть хватит ли памяти и тп), попробуй пересчитать склад по одной номенклатуре (с максимальным числом записей в inventTrans) за все время. Потом попробуй то же самое для номенклатуры со средним числом записей в inventTrans. Потом подели ваш временной промежуток (48 часов) на это время и получишь (грубо приблизительно) число хелперов, которые нужны чтобы закрыть склад за это время.
• Попробуйте запустить пересчет по самой популярной номенклатуре с тем числом хелперов которые получились на предыдущем пункте, и помониторьте загрузку сервера БД. Если у вас там полный содом с утилизацией, памятью и очередью к диску - значит номер заведомо не пройдет и надо разбираться с вариантом N1 и принудительным закрытием.
• Когда будете планировать закрытие, заложитесь с приличным запасом по времени.
• Наконец - возможен вариант комбинации больших и маленьких закрытий Сначала закрыть за выходные и (если понадобится) понедельник и вторник длительный период (первые 6 лет работы), потом по вечерам потихоньку позакрывать по месяцам.
• Если будете закрывать склад параллельно пользовательской работе, можно попробовать понизить макрос CommitCountMax в заголовке класса inventCostItemDim с 50 до, скажем, 15. Производительность закрытия понизиться (потому что транзакция будет коммититься после каждых 15 обновленных проводок), но шансы на откаты транзакций и retry из за того что несколько станций обновили inventSum - уменьшаться.
  

[mazzy]

Цитата:

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

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

Разве так она закроет переносы и спецификации?
переносы и спецификации детектируются и откладываются на второй проход.
или я чего забыл?

[fed]

Цитата:

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

Разве так она закроет переносы и спецификации?
переносы и спецификации детектируются и откладываются на второй проход.
или я чего забыл?

Нет - все проводки сопоставляются на нулевом проходе (включая спецификации и тп). Просто внутри прохода, номенклатура обрабатывается по BOMLevel. И потом при обработке очередной номенклатуры на итерациях прогонки (от 1ой и выше), система слегка жульничает находя все коррекции, которые должны были быть обработаны на следующей итерации, и понижая у них номер итерации в inventCostListTrans до текущего. То есть из за того что прогонка идет по уровням BOM, есть шансы что коррекция, созданная для BOMLevel==1 будет применена к номенклатуре с BOMLevel==2 внутри ОДНОЙ итерации, за счет этого жульничания (попросту при обработке номенклатуры все коррекции помеченные для следующего прохода, в принудительном порядке переводятся на данный проход). Соответственно, есть некоторые шансы что у тебя после 1ого прохода по всем производствам (если переносов не было) будет более или менее внятная себестоимость.
Но поскольку топикстартера вообще не интересует себестоимость, то вполне можно поставить всего 1 итерацию чтобы сначала все сопоставилось, а потом списалось.

[mazzy]

Цитата:

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

Соответственно, есть некоторые шансы что у тебя после 1ого прохода по всем производствам (если переносов не было) будет более или менее внятная себестоимость.

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

И если без производства, но были перемещения. Точно одного прохода будет достаточно, чтобы получить что-нибудь боль-мень вменяемое?

(Это я уже для повышения собственной образованности спрашиваю)

[fed]

Цитата:

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

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

И если без производства, но были перемещения. Точно одного прохода будет достаточно, чтобы получить что-нибудь боль-мень вменяемое?

(Это я уже для повышения собственной образованности спрашиваю)

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

[fed]

Цитата:

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

Попробуйте запустить пересчет по самой популярной номенклатуре с тем числом хелперов которые получились на предыдущем пункте, и помониторьте загрузку сервера БД. Если у вас там полный содом с утилизацией, памятью и очередью к диску - значит номер заведомо не пройдет и надо разбираться с вариантом N1 и принудительным закрытием.

Вру. Один хелпер только одну номенклатуру обрабатывает.Так что надо попробовать вытащить в условие пересчета 60-70 типовых номенклатур и посмотреть сколько это времени займет с вашим числом хелперов и вашим сервером БД.

[Link]

Цитата:

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

1. Услуги. В версии 4.0sp1, появилась специальная ветка (inventCostItemDim,updateServiceItemTrans()), которая принудительно закрывает складскип проводки по услугам. Закрывает она их по умному, заполняя сопоставленное количество, сопоставленную сумму и создавая в складских сопоставлениях запись специального типа (InventSettletModel::ServiceItem). Из за того что все эти поля заполняются и запись сопоставления создается, такая проводка для всех (ну или почти всех) стандартных и нестандартных отчетов выглядит как закрытая и сопоставленная 'по честному'

Цитата:

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

1. Написать собственную процедуру закрытия. Просто надо бежать по текущим складским остаткам в разрезе аналитик финансового склада и для каждой комбинации аналитик отсчитывать назад от текущей даты достаточно складских проводок в статусе "Закуплено" чтобы покрыть текущий складской остаток. Затем все остальные складские проводки надо пометить как закрытые (с использованием кода inventCostItemDim.updateServiceItems() как прототипа). Да - еще замечу что если у тебя в складских остатках, допустим 5 штук, а приходная проводка на 12, то тебе надо ее рассплитить на две проводки по 7 и 5 штук, первую закрыть, а вторую - оставить. Я бы лично пошел по этому пути.
[/LIST]

Это то, что нужно! Большое вам спасибо, Денис!

[Alexius]

Может быть проще будет сделать переброску остатков с помощью двух журналов типа "проводка" ?
1. Формируем журнал(ы) на списание на основании остатков, разносим, маркируем поля сопоставления во всех проводках.
2. Копируем этот журнал(ы) с отрицательным знаком, разносим, наслаждаемся

Из плюсов:
1. Не надо возится со старыми проводками
2. Можно выправить себ-ть на день Ч

Из минусов - теряется связь со старыми документами

[Link]

Цитата:

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

Услуги. В версии 4.0sp1, появилась специальная ветка (inventCostItemDim,updateServiceItemTrans()), которая принудительно закрывает складскип проводки по услугам. Закрывает она их по умному, заполняя сопоставленное количество, сопоставленную сумму и создавая в складских сопоставлениях запись специального типа (InventSettletModel::ServiceItem). Из за того что все эти поля заполняются и запись сопоставления создается, такая проводка для всех (ну или почти всех) стандартных и нестандартных отчетов выглядит как закрытая и сопоставленная 'по честному'

1. Написать собственную процедуру закрытия. Просто надо бежать по текущим складским остаткам в разрезе аналитик финансового склада и для каждой комбинации аналитик отсчитывать назад от текущей даты достаточно складских проводок в статусе "Закуплено" чтобы покрыть текущий складской остаток. Затем все остальные складские проводки надо пометить как закрытые (с использованием кода inventCostItemDim.updateServiceItems() как прототипа). Да - еще замечу что если у тебя в складских остатках, допустим 5 штук, а приходная проводка на 12, то тебе надо ее рассплитить на две проводки по 7 и 5 штук, первую закрыть, а вторую - оставить. Я бы лично пошел по этому пути.

Написал класс для закрытия склада, есть вопросик по inventCostItemDim.updateServiceItems() :
В этом методе изначально цикл обрабатывает только проводки со статусами Sold и Purchased.
Правильно ли я сделал убрав это условие при использовании метода для закрытия всех проводок?

П.С. Если кому то нужен класс, могу выложить.

[fed]

Цитата:

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

Написал класс для закрытия склада, есть вопросик по inventCostItemDim.updateServiceItems() :
В этом методе изначально цикл обрабатывает только проводки со статусами Sold и Purchased.
Правильно ли я сделал убрав это условие при использовании метода для закрытия всех проводок?

П.С. Если кому то нужен класс, могу выложить.

Не правильно. Закрытие в общем случае вообще не должно трогать проводки с другими статусами (оно правда иногда обновляет, но не закрывает, проводки со статусами Received и Deducted, но наш случай это явно не затрагивает). Вообще для твоего случая, любые проводки в статусах отличных от Purchased и Sold должны игнорироваться. (Это справедливо и для поиска проводок, составляющих остаток в inventSum.postedQty).

[Link]

Цитата:

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

Не правильно. Закрытие в общем случае вообще не должно трогать проводки с другими статусами (оно правда иногда обновляет, но не закрывает, проводки со статусами Received и Deducted, но наш случай это явно не затрагивает). Вообще для твоего случая, любые проводки в статусах отличных от Purchased и Sold должны игнорироваться. (Это справедливо и для поиска проводок, составляющих остаток в inventSum.postedQty).

Все понял, спасибо! Для поиска проводок для остатка ищу только со статусом StatusReceipt == StatusReceipt::Purchased.

[Link]

Упустил такой момент, в случае с негативными складскими остатками, нужно ли их покрывать?

[fed]

Цитата:

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

Упустил такой момент, в случае с негативными складскими остатками, нужно ли их покрывать?

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

[Link]

Цитата:

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

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

Благодарю! Будем разбираться.
Думаю, что мы попытаемся привести номенклатуры в порядок, перед переходом.
Я сейчас хочу допилить наше закрытие, что бы можно было паралельно закрывать, ака хелперы.
Как закроем склад, сразу будем тренероваться со стандартной себестоимостью.
Спасибо за помощь!

[Alexius]

Еще неплохо бы проверить проводки по возвратам и маркированные проводки, с ними может быть весело