Закрытие склада : время и деньги

[laptev]

Всем доброго дня.

Посоветуйте, пожалуйста, как можно ускорить периодические операции на складе.
У меня, собственно, три вопроса.

Наша конфигурация
- Axapta 3.0 без SP
- включен "Отрицательный финансовый склад"
- для аналитики "Склад" стоит галочка "Склад" в группе складской аналитики
- закрытие планируется с 31.07.2005 по 31.12.2005 с интервалом в месяц.
Опыты: закрытие за ноябрь ~ 5 часов.

Публикации на AxForum и Mazzy.ru я прочитал (что нашёл )

1.Какими, всё-таки, будут оптимальные параметры "Максимальная пропускная способность" и "Минимальная коррекция пропускной способности"?

2.Хотелось бы сделать пересчёт "на сегодня" для приведения последних проводок в божеский вид (реально закрыть даже "на вчера" не получится). Однако, опыты показывают: декабрьский пересчёт
занял 8 часов. И действительно, методичка "Расчёт сбестоимости" сообщает (стр.17):
"Проводки, скорректированные при пересчете, будут обрабатываться заново при последующих расчетах".
Т.е. при пересчёте каждый раз будут обработаны ВСЕ проводки?
А для указания периода пересчёта нужно модифицировать функционал?

3.Поскольку операции длительные, запускаем пакетную обработку на ночь.
Но: для этого нужен клиент, работающий в режиме batch-сервера. У нас с этим проблемы: клиенты периодически вылетают. Поэтому вопрос:
Можно ли запустить пакет в определённое время на сервере, без участия клиентской рабочей станции?

[mazzy]

Цитата:

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

- включен "Отрицательный финансовый склад"

Что сильно усложняет и замедляет алгоритм.

Цитата:

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

Опыты: закрытие за ноябрь ~ 5 часов.

Да, и чем меньше у вас будет незакрытых данных, тем быстрее будет работать закрытие.
См. ниже.

Цитата:

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

1.Какими, всё-таки, будут оптимальные параметры "Максимальная пропускная способность" и "Минимальная коррекция пропускной способности"?

Для скорости или для точности?
Чтобы получить максимальную скорость введите в оба поля по миллиону, например

Цитата:

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

2.Хотелось бы сделать пересчёт "на сегодня" для приведения последних проводок в божеский вид (реально закрыть даже "на вчера" не получится). Однако, опыты показывают: декабрьский пересчёт
занял 8 часов. И действительно, методичка "Расчёт сбестоимости" сообщает (стр.17):
"Проводки, скорректированные при пересчете, будут обрабатываться заново при последующих расчетах".
Т.е. при пересчёте каждый раз будут обработаны ВСЕ проводки?

Почти правильно.
Правильно так: При каждом пересчете будут обработаны ВСЕ НЕЗАКРЫТЫЕ проводки.

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

Цитата:

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

А для указания периода пересчёта нужно модифицировать функционал?

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

Это как редактирование реестра в виндах - очень мощно, но можно и запороть всю систему одним неловким движением.

Цитата:

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

3.Поскольку операции длительные, запускаем пакетную обработку на ночь.
Но: для этого нужен клиент, работающий в режиме batch-сервера. У нас с этим проблемы: клиенты периодически вылетают. Поэтому вопрос:
Можно ли запустить пакет в определённое время на сервере, без участия клиентской рабочей станции?

Нет.

Вернее, можно. Но некоторые обработки показывают результаты не только в инфологе...
Блин... в общем, нет нельзя.
Снова как с правкой реестра. Если не понимаете до конца, то лучше пока не лезьте.

Лучше потратьте свое время и силы на решение проблемы с вылетанием клиентов - такого не должно быть .

[Vadik]

Цитата:

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

Всем доброго дня

Вечер добрый

Цитата:

Поскольку операции длительные, запускаем пакетную обработку на ночь.
Но: для этого нужен клиент, работающий в режиме batch-сервера. У нас с этим проблемы: клиенты периодически вылетают. Поэтому вопрос:
Можно ли запустить пакет в определённое время на сервере, без участия клиентской рабочей станции?

"Батч-сервер для бедных" (ничего личного - сам так работал):
- ax32.exe запускаем как периодическое задание (scheduled task)
- вход по сетевому имени пользователя
- через командную строку указываем, что надо запускаться в режиме batch-сервера (возможно, потребуется небольшая модификация, если надо запускать не все пакеты, а только определенную пакетную группу)
- автоматический выход из системы после некоторго времени бездействия

В принципе, вариант вполне живучий

[laptev]

to mazzy

Благодарю за ответ.
Если можно, несколько уточнений.

Цитата:

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

Цитата:

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

- включен "Отрицательный финансовый склад"

Что сильно усложняет и замедляет алгоритм.

А нет ли оценок - во сколько раз?
Если сильно - мы, возможно, изменим бизнес-процесс.

Цитата:

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

Цитата:

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

1.Какими, всё-таки, будут оптимальные параметры "Максимальная пропускная способность" и "Минимальная коррекция пропускной способности"?

Для скорости или для точности?
Чтобы получить максимальную скорость введите в оба поля по миллиону, например

Правильно ли я понимаю, что при "Максимальная пропускная способность = 1" будет выполнен только 1 цикл пересчёта (ну или 2, если есть ещё нулевой). Т.е. Максимальная пропускная способность =10 даст время в 10(5) раз больше. Экспериментировать на больших объёмах проводок затруднительно, на малых разницы во времени не заметил.
С "Минимальной коррекцией пропускной способности" ситуация непонятна - независимо от параметра расчёт ведётся с точностью до копейки (насколько удалось проверить).

Цитата:

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

Цитата:

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

2.Хотелось бы сделать пересчёт "на сегодня" для приведения последних проводок в божеский вид (реально закрыть даже "на вчера" не получится). Однако, опыты показывают: декабрьский пересчёт
занял 8 часов. И действительно, методичка "Расчёт сбестоимости" сообщает (стр.17):
"Проводки, скорректированные при пересчете, будут обрабатываться заново при последующих расчетах".
Т.е. при пересчёте каждый раз будут обработаны ВСЕ проводки?

Почти правильно.
Правильно так: При каждом пересчете будут обработаны ВСЕ НЕЗАКРЫТЫЕ проводки.

Дело в том, что из закрытого периода тоже корректируются некоторые проводки, всегда на 1 копейку.
Пи этом статус проводки не меняется (Закрытыми я считаю проводки, у которых "Разное"->"Открытое значение"="Нет")
Т.е. возможно, что пересчёт проверяет и закрытые проводки?

[laptev]

to Vadik

Спасибо, совет интересный.

Цитата:

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

"Батч-сервер для бедных" (ничего личного - сам так работал):
- ax32.exe запускаем как периодическое задание (scheduled task)
- вход по сетевому имени пользователя
- через командную строку указываем, что надо запускаться в режиме batch-сервера (возможно, потребуется небольшая модификация, если надо запускать не все пакеты, а только определенную пакетную группу)
- автоматический выход из системы после некоторго времени бездействия

В принципе, вариант вполне живучий

Тут, правда, он может вылететь и во время обработки пакета. Я думаю, мы организуем "невылетающего" клиента.

[mazzy]

Цитата:

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

Цитата:

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

Цитата:

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

- включен "Отрицательный финансовый склад"

Что сильно усложняет и замедляет алгоритм.

А нет ли оценок - во сколько раз?
Если сильно - мы, возможно, изменим бизнес-процесс.

Сильно зависит от числа проводок, которые проданы "в минус" (без себестоимости)
Аксапта для таких проводок пытается себестоимость восстановить.

Цитата:

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

Цитата:

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

Цитата:

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

1.Какими, всё-таки, будут оптимальные параметры "Максимальная пропускная способность" и "Минимальная коррекция пропускной способности"?

Для скорости или для точности?
Чтобы получить максимальную скорость введите в оба поля по миллиону, например

Правильно ли я понимаю, что при "Максимальная пропускная способность = 1" будет выполнен только 1 цикл пересчёта (ну или 2, если есть ещё нулевой). Т.е. Максимальная пропускная способность =10 даст время в 10(5) раз больше. Экспериментировать на больших объёмах проводок затруднительно, на малых разницы во времени не заметил.

Там же сказано - "Максимальная"
Максимальная пропускная способность =10 означает, что будет сделано НЕ БОЛЕЕ 10 циклов.
Если появился самый неблагоприятный случай, когда Аксапта не может определить себестоимость с точностью до "Минимальная коррекция пропускной способности", Аксапта остановится на цикле с номером "Максимальная пропускная способность".

Цитата:

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

С "Минимальной коррекцией пропускной способности" ситуация непонятна - независимо от параметра расчёт ведётся с точностью до копейки (насколько удалось проверить).

Сумма округляется согласно настройкам округления для основной валюты.
Дело в другом.
Аксапта делает несколько итераций (чтобы протащить себестоимость через перемещения между складами, через производственные спецификации, учесть возвраты, разобраться с себестоимостью продаж, которые проданы в минус и т.п.)
Как только разница в себестоимости между двумя циклами меньше "Минимальной коррекции пропускной способности"
ИЛИ количество циклов больше "Максимальная пропускная способность"
Аксапта прекращает делать итерации (записывает получившеюся себестоимость).

Цитата:

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

Цитата:

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

Цитата:

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

2.Хотелось бы сделать пересчёт "на сегодня" для приведения последних проводок в божеский вид (реально закрыть даже "на вчера" не получится). Однако, опыты показывают: декабрьский пересчёт
занял 8 часов. И действительно, методичка "Расчёт сбестоимости" сообщает (стр.17):
"Проводки, скорректированные при пересчете, будут обрабатываться заново при последующих расчетах".
Т.е. при пересчёте каждый раз будут обработаны ВСЕ проводки?

Почти правильно.
Правильно так: При каждом пересчете будут обработаны ВСЕ НЕЗАКРЫТЫЕ проводки.

Дело в том, что из закрытого периода тоже корректируются некоторые проводки, всегда на 1 копейку.
Пи этом статус проводки не меняется (Закрытыми я считаю проводки, у которых "Разное"->"Открытое значение"="Нет")
Т.е. возможно, что пересчёт проверяет и закрытые проводки?

Нет, не должен.
glibs как то рассказывал о подобной баге. В последних сервис-паках вроде исправили.
Надо его спросить.

[laptev]

to mazzy

Спасибо за разъяснения!
В общем, будем закрывать и засекать по таймеру
О результатах сообщу.