Пересчёт склада в пакетном режиме

[Cathome]

DAX ядро 4.0.2503.454, приложение 4.0.2501.122, СУБД не знаю.

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

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

1. В пакете нельзя запускать пересчёт несколько раз. Конечно, можно поиграться со значениями макс. пропускной способности, но экспериментальным путём мы пришли к тому, что в разы быстрее посчитать несколько раз, чем поставить большую макс.пропускную способность, да и нет гарантии, что при ней склад всегда пересчитается в ноль за один присест.
2. Если даже и можно как-то запустить несколько раз, как можно узнать, что предыдущий раз завершился?

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

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

[twilight]

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

[Cathome]

Да, сопоставления-то формируются, следовательно, себестоимость меняется. Ну вот приведу пример, легкий был пересчёт, всего за 2 повторения все рассчиталось. Обычно 3-4 раза считаем.

[Cathome]

В общем, решила сделать класс, который будет делать то, что мне нужно. Но это оказалось весьма нетривиально.
Сначала думала отнаследоваться от InventCostClosingRecalc, но оказалось, не судьба, т.к. у него только статические конструкторы.
Тогда решила отнаследоваться от RunBaseBatch, но тут встал вопрос, как получить параметры из диалога пересчёта, ведь он запаковывается до того, как распаковывается мой класс. Использовала xSysLastValue, чтобы достать параметры пересчёта, и параметр getLastCalled, что бы это ни было (не смогла нагуглить о нём ничего вразумительного), для того, чтобы делать это только при создании пакетного задания, но не при его просмотре и запуске.

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

[mazzy]

Цитата:

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

Делаем это руками - до тех пор, пока при очередном пересчёте не будет чисто в плане сопоставлений. Это занимает 3-4 повторения.
...
В общем, я думаю над тем, чтобы сделать класс, который бы запускался в пакетном режиме и крутил бы пересчёт по условию.

скорее всего, не надо делать никакого класса.

у стандартного функционала есть два параметра

1. число повторений. по умолчанию = 100
2. минимальное изменение себестоимости. по умолчанию = 1

это значит, что стандартный функционал будет повторять процедуру закрытия до тех пор,
ПОКА себестоимость изменяется сильно (больше, чем второй параметр)
ИЛИ будет выполнено максимальное число повторений

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

обычно ставят минимальное изменение = 0.01 (1 копейка)
это очень маленький порог. округления сумм дают не меньше копейки. поэтому из-за округлений, значение 0.01 не работает как нужно.
нужно поставить хотя бы 0.02. на самом деле 1 вполне хорошее допущение.

а вот первый параметр обычно оставляют по умолчанию = 100.
хотя в вашем случае "3-4 повторения" означает, что фактически вы делаете 300-400 итераций.

поэтому поставьте в первый параметр 400 или 500.
а второй параметр не уменьшайте слишком близко к 0.01, сделайте 1.0 или хотя бы 0.10

[Cathome]

Макс.пропускную способность 2 раза пробовала 500, и в этом случае, честно говоря, за весь рабочий день не дождалась результата. Не могу понять, с чем это связано, при 100 3-4 пересчёта занимают минут 20-30. Со вторым параметром, честно, не пробовала играться, т.к.подозреваю, что он замедляет процесс ещё больше.

[mazzy]

Цитата:

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

500, и в этом случае, честно говоря, за весь рабочий день не дождалась результата. Не могу понять, с чем это связано, при 100 3-4 пересчёта занимают минут 20-30.

deadlock к каким-то периодическим заданием в пакетнике.

==============================
общий совет, как контролировать и оптимизировать процедуру закрытия

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

заглядывайте туда. смотрите какие номенклатуры там появляются, с каким номером итерации.

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

у каждой номенклатуры есть поле - уровень.
этот уровень пересчитывается в процедуре закрытия перед основным циклом.
в списке расчета есть этот уровень.

далее список упорядочивается по уровню и номеру расчета.

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

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

в идеале, закрытие должно выполняться за (1-2 * максимальная_глубина_спецификации) итераций. максимум за (10 * максимальная_глубина_спецификации) итераций.

Цитата:

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

Со вторым параметром, честно, не пробовала играться, т.к.подозреваю, что он замедляет процесс ещё больше.

судя по вашим скриншотам, у вас там 0.01 )
сделайте чуток больше.

[SRF]

Цитата:

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

судя по вашим скриншотам, у вас там 0.01 )
сделайте чуток больше.

В стандарте нельзя указать значение меньше, чем значение в общем правиле округления x10(в случае если указано 0, то берется точность как 0.01, ну и как правило никто там ничего не ставит), т.е. в большинстве случаев меньшем чем 0.1 просто не укажешь.

Использование данного параметра отличается от типа пересчета, корректировка себестоимости создается в случае, если используется типа пересчета = закрытие, посмотрите например в код InventcostItemDim\updateTransIdReceipt (подобные условия есть не только там)

                    if (inventClosing.AdjustmentType == InventAdjustmentType::Closing)
                    {
                        if (abs(adjustNow) < inventClosing.MinTransferValue || inventClosing.NumOfIteration >= inventClosing.MaxIterations)
                        {
                            // <GEERU>
                            if (countryRegion_RU)
                            {
                                this.createErrorAdjustment(receipt,-adjustNow, false);
                            }
                            else
                            {
                            // </GEERU>
                               this.createErrorAdjustment(receipt,-adjustNow);
                            // <GEERU>
                            }
                            // </GEERU>
                        }
                    }

Поэтому некоторые используют схему сначала пересчет, а потом закрытие, чтобы получить более точную себестоимость, другое дело, что параметр 1 в пропускной способности более чем достаточно, но не все готовы видеть разрыв себестоимости строки переноса или заказа на перемещение

[Cathome]

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

Цитата:

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

в идеале, закрытие должно выполняться за (1-2 * максимальная_глубина_спецификации) итераций. максимум за (10 * максимальная_глубина_спецификации) итераций.

Вот тут я не совсем поняла, имеется в виду количество программных последовательностей (NumOfIteration)?

И разве уровень спецификации не имеет отношения только к производственным номенклатурам?

count(ItemId) BOMLevel
6463 ------------- 0
320 --------------- 1
99 ---------------- 2
6 ------------------ 3

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

Цитата:

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

судя по вашим скриншотам, у вас там 0.01 )
сделайте чуток больше.

Не, у нас стандартно, единичка там.

Сегодня попробовала разные комбинации, вот с таким результатом:



Т.е. при любом раскладе получается, что считать нужно 3-4 раза до исчезновения новых сопоставлений.

Макс.число программных последовательностей (NumOfIterations) при пересчётах в любых вариантах получилось = 3.

Что касается того, что я писала раньше, по поводу того, что на пропускной способности (MaxIterations) = 500 не дождалась результата. Может быть, это был deadlock, но скорее, какие-то проблемы в складских проводках, потому что количество номеров в расчёте обычно стоит 2000-2400, а тогда оно было около 50 000. Правда, в те 2 раза я решила, что на большом параметре MaxIterations это нормально и не стала разбираться более детально. Сегодня воспроизвести подобный результат мне не удалось.

[SRF]

Цитата:

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

Макс.число программных последовательностей (NumOfIterations) при пересчётах в любых вариантах получилось = 3.

Максимальное кол-во программных последовательностей сверху ограничено значением максимальной пропускной способности, если это значение было бы равно 100, 400 и т.д., то тогда смысл увеличивать его имеется, а так если у вас максимум 3, то можно хоть 5 поставить ничего не поменяется.

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

Поэтому берите отладчик в руки, запускайте итеративные пересчеты по одной номенклатуре(благо это не так сложно воспроизвести), ищите место в коде закрытия, где работает не так как вам надо, а дальше уже по результатам анализа будет понятно что и как можно\нужно делать, по другому думаю не получится, если только кто то не сталкивался с подобной проблемой

[Cathome]

Цитата:

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

Максимальное кол-во программных последовательностей сверху ограничено значением максимальной пропускной способности, если это значение было бы равно 100, 400 и т.д., то тогда смысл увеличивать его имеется, а так если у вас максимум 3, то можно хоть 5 поставить ничего не поменяется.

Извините за глупый вопрос, т.е. maxIterations и NumOfIteration - понятия одного порядка? Неужели у кого-то бывает больше 100?

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

Откуда они берутся, я и без отладчика знаю. В закупках на количество, кратное 2, постоянно приходится сумма, не кратная 2. И эта лишняя копейка в рамках партии потом гоняется туда-сюда до тех пор, пока не закроется склад или пока партия не спишется. Я думаю, это у всех есть, но не у всех при этом получаются фин.проводки. У нас очень часто партия расщепляется на разные бух.счета. Допустим, по одной такой партии приход на 41 потом корреспондирует с 10, 91, 20, или даже банально происходит смена фин.аналитики при перемещении. Вот и проводки от этой копейки. В рамках всего склада много таких операций набирается. Работает ли пересчёт не так, как нам надо, или мы работаем не так, под что заточена Аксапта, это вопрос риторический..

Другой вопрос, что в пересчёте для отчётности, возможно, нет такой острой необходимости получить точную себестоимость, которая всё равно в рамках месяца неточная. А при подготовке к закрытию всё равно запускается всё вручную и нет разницы, 1 или 3-4 раза это сделать.

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

[Raven Melancholic]

Цитата:

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

Извините за глупый вопрос, т.е. maxIterations и NumOfIteration - понятия одного порядка? Неужели у кого-то бывает больше 100?

NumOfIteration это сколько реально итераций было при закрытии (пересчете)
MaxIterations - это то, чем вы ограничиваете Аксу в размере NumOfIteration, то есть больше итераций она делать не будет и при закрытии просто спишет разницу (при пересчете не будет перебрасывать разницу дальше).
При боле-менее сложной логистике (производство и сборка спецификаций, склады хранения, распределительные склады, склады филиалов, склады торговых точек и т.п.) вполне нормальным бывает 30-40 итераций. Возможно все может быть настолько сложным в плане логистики, что нужно и более 100, но мне пока встречались ситуации, то такое количество возникает тогда, когда есть какое-то "зацикливание" (было списание со склада на другой склад, потом возврат с другого склада обратно, потом опять отгрузка и т.д., в результате, сумма коррекции гонялась по кругу).