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

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