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

[Link]

Да, вот такая у нас ситуация: от начала внедрения (2005 год) и по сей день склад никогда не закрывался.
История версий Аксапты начинается с 3ки, и скоро мы должны перейти на 2009 с нынешней 4ки.
В новой версии собираемся использовать стандартную себестоимость, посему стал остро вопрос, как можно быстрее закрыть склад за все 7 лет.
За этот период транзакций накопилось очень много > 43 млн записей, при размере таблицы 25 Гб и почти столько же занимает индекс.

По большому счету, основная цель нашего закрытия не вычисление истинной себестоимости, и автоматом в ГК разносить не будем (отключим в настройках).
Главное - это подготовить систему для включения стандартной себестоимости в новой версии.
Статью Дениса о себестоимости и закрытии склада я прочел. Но статья описывает закрытие на регулярной основе.
Хотелось бы услышать мнение о такой нетипичной ситуации. Может быть известны какие нибудь полезные настройки или приёмы?

[ena_ax]

Первое что пришло в голову.
Может пройтись по строкам InventTrans и поставить ValueOpen = NoYes::Yes
QtySettled = Qty ?

[S.Kuskov]

Цитата:

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

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

А не хотите сделать "перезаливку" остатков номенклатур (т.е. всё списать а потом заново оприходовать) а потом искуственно позакрывать все старые проводки

[mazzy]

Цитата:

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

Да, вот такая у нас ситуация: от начала внедрения (2005 год) и по сей день склад никогда не закрывался.
История версий Аксапты начинается с 3ки, и скоро мы должны перейти на 2009 с нынешней 4ки.
...

По большому счету, основная цель нашего закрытия не вычисление истинной себестоимости, и автоматом в ГК разносить не будем (отключим в настройках).

Не поддавайтесь искушению.
Попробуйте стандартное закрытие.

Хинты:

1. Первое закрытие должно быть ДО начала всех складских проводок - так будет и быстрее и легче отменять в случае чего.
2. Закрывайте мелкими кусочками - по неделе/месяцу. Так будет быстрее. Не закрывайте большими кусками. Дело в том, что внутри закрытия алгоритм собирает складские проводки и пытается между ними найти связи. При этом стандартный алгоритм использует map'ы, которые хранятся в памяти. (но обязательно нужна правка кода. см.пункт 6)
3. Задайте небольшое число итераций при закрытии = 10-20 будет вполне достаточно
4. Задайте относительно большой порог точности (минимальная коррекция пропускной способности = 10, минимальная сумма сопоставления = 10 руб) - получите приемлемый результат на большом количестве и суммах. Но при этом получите чудовищный разброс себестоимости на маленьких количествах и суммах (обычно это возврат 1-2 штук по смешным копеечным ценам на фоне многотысячных приходов)
5. Не используйте алгоритм закрытия по-среднему - как ни странно, это самый медленный и самый базоемкий алгоритм в ax3 и ax4. в ax2009 это исправили. Попробуйте стандартную себестоимость или FIFO.
6. Последнее по счету, но не по важности: стандартный алгоритм нормально обрабатывает ввод данных "задним числом". Поэтому ему необходимо "заглядывать" вперед (в даты больше, чем даты закрытия). При нормальном ходе закрытия предполагается, что будущих проводок немного и они не сильно влияют на производительность закрытия. В вашем случае это катастрофа - каждое закрытие прошлых периодов будет просматривать все будущие проводки. Поэтому надо будет найти в коде основной цикл закрытия и добавить условие "рассматривать проводки с датой не больше, чем дата закрытия". В этом случае закрытие будет спотыкаться если расход раньше прихода (обычно число итераций превышает границу). Но дальнейшие закрытия ситуацию разрулят. Не поддавайтесь сооблазну закрыть одним махом все периоды - в этом случае расчет будет постоянно уходить в своп и тормозить совершенно безбожно (см. пункт 2)

примерно так.
дальше читать статьи Федотенко (fed) про закрытие.

[Link]

Цитата:

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

Первое что пришло в голову.
Может пройтись по строкам InventTrans и поставить ValueOpen = NoYes::Yes
QtySettled = Qty ?

Выглядит очень неопределенно в будущем. Хочется решить проблему стандартным функционалом. Спасибо!

[Link]

Цитата:

Сообщение от S.Kuskov

А не хотите сделать "перезаливку" остатков номенклатур (т.е. всё списать а потом заново оприходовать) а потом искуственно позакрывать все старые проводки

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

[Ivanhoe]

Поддержу вариант с начальным сальдо. Какие преимущества вы хотите получить, перенося все операции и делая закрытие?

[Link]

Цитата:

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

Не поддавайтесь искушению.
Попробуйте стандартное закрытие.

Спасибо, это было бы идеальным вариантом.

Цитата:

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

Хинты:

1. Первое закрытие должно быть ДО начала всех складских проводок - так будет и быстрее и легче отменять в случае чего.
2. Закрывайте мелкими кусочками - по неделе/месяцу. Так будет быстрее. Не закрывайте большими кусками. Дело в том, что внутри закрытия алгоритм собирает складские проводки и пытается между ними найти связи. При этом стандартный алгоритм использует map'ы, которые хранятся в памяти. (но обязательно нужна правка кода. см.пункт 6)
3. Задайте небольшое число итераций при закрытии = 10-20 будет вполне достаточно
4. Задайте относительно большой порог точности (минимальная коррекция пропускной способности = 10, минимальная сумма сопоставления = 10 руб) - получите приемлемый результат на большом количестве и суммах. Но при этом получите чудовищный разброс себестоимости на маленьких количествах и суммах (обычно это возврат 1-2 штук по смешным копеечным ценам на фоне многотысячных приходов)
5. Не используйте алгоритм закрытия по-среднему - как ни странно, это самый медленный и самый базоемкий алгоритм в ax3 и ax4. в ax2009 это исправили. Попробуйте стандартную себестоимость или FIFO.
6. Последнее по счету, но не по важности: стандартный алгоритм нормально обрабатывает ввод данных "задним числом". Поэтому ему необходимо "заглядывать" вперед (в даты больше, чем даты закрытия). При нормальном ходе закрытия предполагается, что будущих проводок немного и они не сильно влияют на производительность закрытия. В вашем случае это катастрофа - каждое закрытие прошлых периодов будет просматривать все будущие проводки. Поэтому надо будет найти в коде основной цикл закрытия и добавить условие "рассматривать проводки с датой не больше, чем дата закрытия". В этом случае закрытие будет спотыкаться если расход раньше прихода (обычно число итераций превышает границу). Но дальнейшие закрытия ситуацию разрулят. Не поддавайтесь сооблазну закрыть одним махом все периоды - в этом случае расчет будет постоянно уходить в своп и тормозить совершенно безбожно (см. пункт 2)

примерно так.
дальше читать статьи Федотенко (fed) про закрытие.

Спасибо, большое! Теперь понятно что к чему
То то у нас при попытках закрытия больше месяца, так все дико тормозит
Пойду делать пункт 6.

[Link]

Цитата:

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

Поддержу вариант с начальным сальдо. Какие преимущества вы хотите получить, перенося все операции и делая закрытие?

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

Мне как программисту куда проще и надежнее подправить стандартную процедуру, если после этого производительность будет удовлетворительной.
Поэтому вариант с начальным сальдо, мы рассматриваем на крайний случай.
Опять же нет опыта и понимания всего процесса. Поэтому тут еще придется привлекать партнеров.
К тому же если я правильно понимаю, перенос остатков приведет к потере истории и отчетности.

[fed]

Если закрытие мелкими кусочками, которое mazzy предлогает, не поможет, можно сделать похаканную версию закрытия (для первого закрытия конечно), которое для любой номенклатуры использует метод, который 4ка штатно использует только для услуг. Один раз закрыть склад этой штукой и больше никогда не юзать.
Кроме того - с учетом этого вариант тупо пометить проводки как закрытые, програм-манагер по себестоимости считает вполне легальным и верным для версии 2009.Так что, возможно, предложение ena_ax - оно вполне корректно...

[Link]

Цитата:

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

Если закрытие мелкими кусочками, которое mazzy предлогает, не поможет, можно сделать похаканную версию закрытия (для первого закрытия конечно), которое для любой номенклатуры использует метод, который 4ка штатно использует только для услуг. Один раз закрыть склад этой штукой и больше никогда не юзать..

Спасибо, Денис!

В первом случае я так понимаю будет достаточно установить isServiceItem = true для \Classes\InventCostItemDim\run. Можно ли будет при таком хаке закрыть склад за выходные за все 7 лет? И после этого как минимум уйдет неделя что бы перейти на 2009 версию и еще неделя включить мультисайт и начать использовать стандартную себестоимость. Но насколько помню, нам рекомендовали закрыть склад полностью, тут возникает вопрос можно ли будет закрыть те 3 недели уже в 2009 версии без изменений кода?

isServiceItem       = this.inventTable(inventCostList.ItemId).inventItemType().isServiceItem();
..................       
            else
            {
                this.updateSettleRefItem(inventCostList.ItemId);

                if (! isServiceItem)
                {
                    mapLoopTrans    = new Map(Types::Integer,Types::Record);
                    mapLoopDim      = new Map(Types::Integer,Types::Record);
                    loopX           = 0;

                    queryRun = inventCostHelp.initQueryRunTrans(this.inventTable(inventCostList.ItemId));
                    while (queryRun.next())
                    {
                        loopX++;
                        mapLoopTrans.insert(loopX,queryRun.get(tablenum(InventTrans)));
                        mapLoopDim.insert(loopX,queryRun.get(tablenum(InventDim)));
                    }

                    loopMax = loopX;
                    loopX   = 0;
                    while (loopX < loopMax)
                    {
                        loopX++;

                        this.updateItemDim(mapLoopTrans.lookup(loopX),mapLoopDim.lookup(loopX));
                    }
                }
            }

            if (inventClosing.AdjustmentType == InventAdjustmentType::Closing && isServiceItem)
            {
               this.updateServiceItemTrans(inventCostList.ItemId);
            }

Цитата:

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

Кроме того - с учетом этого вариант тупо пометить проводки как закрытые, програм-манагер по себестоимости считает вполне легальным и верным для версии 2009.Так что, возможно, предложение ena_ax - оно вполне корректно...

Второй вариант мне не особо понятен. Каковы должны быть критерии выборки записей для обновления, для закрытия всех проводок?

    InventTrans                 inventTrans;
;
    update_recordset inventTrans
        setting ValueOpen = InventTransOpen::Yes, QtySettled = inventTrans.Qty;

ПМ ваш или МС так считает? Мы хотели попросить партнеров уточнить у МС. Т.к. консультант нам ничего такого не посоветовал. Сказал закрывать склад стандартными средствами и желательно закрыть в версии 4 все что накопилось в 3ке, что бы по его мнению минимизировать возможно ошибок.
На закрытие 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.
Правильно ли я сделал убрав это условие при использовании метода для закрытия всех проводок?

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