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

[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, но мне пока встречались ситуации, то такое количество возникает тогда, когда есть какое-то "зацикливание" (было списание со склада на другой склад, потом возврат с другого склада обратно, потом опять отгрузка и т.д., в результате, сумма коррекции гонялась по кругу).