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

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