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

[Eldar9x]

Закрывали склад за месяц. Закрылся, если судить по логам, примерно за 2 часа. На форме закрытие и коррекция появилась строчка Закрытие со статусом Ок. Но в конце выдалось сообщение Закрытие склада достигло максимального числа итераций. Для получения более точного результата следует увеличить пропускную способность. . При этом повторная попытка закрыть склад выдает предупреждение:
Склад уже закрыт до 30.04.2010.. Вот как тут понять, правильно склад закрылся или нет, и закрылся ли он вообще?

[sukhanchik]

Закрылся. Но закрылся "по принуждению" - т.е. не когда "все сошлось", а когда кол-во итераций дошло до максимума. Поэтому система рекомендует открыть склад, изменить параметр и снова закрыть склад

[Андре]

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

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

[Eldar9x]

Ну этот параметр я и так выставил в 1000, следует еще поднять (все равно закрывали на тестовой)?

[fed]

Цитата:

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

Ну этот параметр я и так выставил в 1000, следует еще поднять (все равно закрывали на тестовой)?

Вообще - в нормальной ситуации, склад закрывается за 30-40 итераций. При разумном уровне ошибок в данных (нарушений исторического порядка) - итераций за 50-80-100. Если у вас за 1000 итераций не удалось погрешность довести хотя бы до рубля, то надо не число итераций увеличивать, а порядок в данных наводить.

[Logger]

Скорее всего куча циклов из-за переносов возникла. Гоняет копейки по кругу.

[Geo]

Цитата:

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

Скорее всего куча циклов из-за переносов возникла. Гоняет копейки по кругу.

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

[Raven Melancholic]

Какие у вас модели себестоимости и какие параметры выставляли при запуске процедуры закрытия?
Вам нужно проанализировать движения номенклатуры, обращая особое внимание на следующие места (список не полный, но часто встречающийся):

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

Вычислить такие номенклатуры можно несколькими способами:
Не откатывая закрытие посмотреть операции ГК и найти те, в которых идет списание на счета прибылей и убытков. Затем зайти в сопоставления и отфильтровать по счету и аналитикам. Если записей немного, то большая вероятность, что это именно проблемные номенклатуры, особенно, если суммы там больше, чем ожидалось при установке параметров закрытия.
Откатить закрытие. Если у вас DAX4, то запустить отчеты по проверке открытого количества и проверке себестоимости. Хотя они отлавливают достаточно простые случаи, но могут помочь. Запустить закрытие. С другой машины открыть форму "Закрытие и коррекция" и, время от времени обновляя её, ждать пока в поле "Число программных последовательностей" значение не достигнет нескольких десятков и после этого открыть на просмотр таблицу InventCostListTrans. В ней как раз останутся проблемные номенклатуры. Обновляя время от времени эту таблицу следите за тем, меняется ли что-то или нет и насколько меняется. Вот с этими номенклатурами и нужно разбираться. В простейших случаях достаточно промаркировать проблемные операции. В более сложных уже придется разбираться с каждым случаем в отдельности
Удачи

[Starling]

Цитата:

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

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

Если я правильно понял идею, то она будет работать не всегда.
Пример:
Есть один перенос, по нему две проводки:
- Проводка1 - Х
- Проводка2 +Х
Сторнирующий перенос:
- Проводка3 - Y
- Проводка4 +Y
Вы предлагаете маркировать: Проводка1 <-> Проводка4 и Проводка2 <-> Проводка3?
Этот подход избавит от циклов только в случае если Х = Y. Если это не так, то такая маркировка наоборот может привести к появлению новых циклов.

[Raven Melancholic]

После активного отдыха уточню насчет циклов. Под цикличностью я имел ввиду изменение аналитик с точки зрения расчета себестоимости, то есть сочетания аналитик, у которых включен финансовый склад. Поэтому циклы могут быть и неявными. Например (это только один пример, вариантов может быть много), есть складские журналы типа "Перенос" в которых меняется склад. Даже если нет возвратов полученной номенклатуры на исходный склад, цикл все равно может возникнуть из-за того, что склад не является аналитикой, включенной в финансовый склад. Получается, что с точки зрения расчета себестоимости в разрезе аналитик финансового склада был как приход, так и расход одного и того же, соответственно процедура закрытия склада будет от итерации к итерации пытаться переносить себестоимость расхода через операции журнала на приход, а коррекцию прихода опять посылать по кругу на следующей итерации.
Особенно ярко такие вещи проявляются при использовании модели по средней себестоимости, а уж по средней на дату это вообще вылазит часто. В DAX2009 для этих двух моделей изменили способ расчета, но проблемы цикличности есть и там.
Ну и, как всегда, приведу ссылку на статью, которую должен знать каждый аксаптовед:
Denis Fedotenko: Себестоимость и закрытие склада

[Geo]

Цитата:

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

Если я правильно понял идею, то она будет работать не всегда.
Пример:
Есть один перенос, по нему две проводки:
- Проводка1 - Х
- Проводка2 +Х
Сторнирующий перенос:
- Проводка3 - Y
- Проводка4 +Y
Вы предлагаете маркировать: Проводка1 <-> Проводка4 и Проводка2 <-> Проводка3?
Этот подход избавит от циклов только в случае если Х = Y. Если это не так, то такая маркировка наоборот может привести к появлению новых циклов.

Немного не так. Надо проводки не полностью в кольцо замыкать (т.к. при разной себестоимости в проводках это вызовет заворот мозгов у системы, т.е. безконечный цикл до исчерпания лимита, причем с бредовой себестоимостью в переносах в результате), а приход-расход на одном складе. Точнее, ошибочный приход со сторно-расходом.
В Вашем примере, если принять первую операцию за ошибочную, а вторую - за сторно, это будет маркировка Проводка2 <-> Проводка3.

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

[Geo]

Посмотрел нашу базу. Собственно, сейчас поумневшая АХ при сторнировании переносов (через родную функцию копирования журналов) так сама и делает: сразу маркирует расходную проводку сторнирующей операции с приходной проводкой сторнируемой. Аплодисменты!

У нас АХ2009.

...
Более того: даже при наличии неотмаркированных обратных переносов, пересчет склада всё равно работает очень быстро (на тестовых данных). Либо это в 2009 так хорошо переписали закрытие склада по средней, либо это из-за того, что у нас себестоимость средняя не "на дату", а взвешенная (за период то бишь). Однако, по логике, средняя взвешенная должна бы, наоборот, резко увеличивать количество циклов при переносах туда-сюда, поскольку теперь пересчету подлежат цикличные переносы не только за один день, а за весь период в целом (хотя тут могу ошибаться).