ЗАКРЫТИЕ СКЛАДА

[Alex_right]

Наверное я не первый, кто закрывает склад.
Испытываю проблемы с закрытием склада. Никак не могу закрыть склад.
Модель - средняя на дату
Операций порядка - 300 000
Выполнил все рекомендации для ускорения. Хот-фикс стоит, который должен был улучшить производительность на 10%.
Закрываю маленькими кусочками. Закрыл 3 дня периода - закрытие произошло за 2 часа. Но второй раз закрыть склад не могу.
Поставил параметры производительность - 5, минимальное ... - 1.
Так вот за следующие три дня (около 4 тыс. операций) склад закрывался 21 час.
Причем закрылся, но выдал сообщение, что данный период уже закрыт, а следующее сообщение- склад закрылся с исключительной ошибкой Error.
Корреспонденцию отключить не могу.
Что же это за недостойный и непродуманный алгоритм по закрытию!!!! Если я в состоянии в EXcel с написанием всех формул за 2 мин расчитать себестоимость по одной номенклатуре, то почему ПО на сервере с кучей процессоров, гигагерцев и мозгов закрывает склад по 4000 операций (в Inventtrans) 21 час!!!!
MBS за это надо .....
Что посоветуете. Финансовой аналитики нет никакой. Кто может указать кусок кода, в котором надо исключить из расчета перемещения и что можно еще откорректировать в самом алгоритме?

[Волчара]

А не можешь отключить корреспондерцию перед закрытием и включить ее после?
Или это сильно нарушит учет?
При корреспондеции счетов во второй Ахапке действительно может быть Error.

По поводу медленного закрытия:
1. Сколько складских проводок?
2. Сколько складской аналитики?
3. Сколько бухгалтерских проводок?

[Андре]

Quote:

Модель - средняя на дату

Критично ? FIFO, LIFO - будут гораздо быстрее.

[mazzy]

Quote:

Изначально опубликовано Alex_right
почему ПО на сервере с кучей процессоров, гигагерцев и мозгов закрывает склад по 4000 операций (в Inventtrans) 21 час!!!!

Проверьте на наличие deadlock'ов.
Корреспонденция странно отражается на многопроцессорной машине.

[Alex_right]

На счет дедлоков. Смотрим сейчас. Но дело в том, что каждое закрытие склада не будешь ведь отслеживать сидя ночью на локи. Странна эта ситуация. Я отключил всех пользователей, сделал сингл-юзер на базу. Что там лочится не понятно ((

Корреспонденцию отключить не могу, поскольку это сильно повредит учету
И еще не известно как это повлияет на отчеты в ГК, а бухгалтерии клиента не объяснишь (((

Аналитики всего две (Склад+ГТД и Склад) без финансовой аналитики

Кто-нибудь интересно оптимизировал код?

[Shrike]

Всем известна позиция МБС по данному вопросу: "...закрытие склада не является критической ошибкой. при определенных условиях закрыть склад можно..."

В-общем, проблемы индейцев вождя не... (волнуют)

[Wamr]

Что пишется в прогресс-баре?.. если он не успевает пробегать 1 раз, то ни параметры производительности, ни отключение корреспонденции не помогут.

Посмотрите трейс, что тормозит?..
На каком компе находится АОС? посмотрите его загрузку..

Чтобы исключить перемещения достаточно проставить в этих проводках ValueOpen = NO

Код написан достаточно прямо.

[mazzy]

Quote:

Изначально опубликовано Alex_right
Что там лочится не понятно

Точно. Однако ж deadlock'и были.

[Alex_right]

to Warm
"Что пишется в прогресс-баре?.. если он не успевает пробегать 1 раз, то ни параметры производительности, ни отключение корреспонденции не помогут."

ЧТо значит не успевает пробегать один раз? У меня он обновляется в процессе.
Но эти параметры производительности действительно никак не помогают


АОС находится на хорошем сервере с 4мя процессорами. При закрытии загрузка сервера менее 40%. Вроде ничего не тормозит.

Где надо поставить ValueOpen? В INVENTTRANS?

[Wamr]

Quote:

ЧТо значит не успевает пробегать один раз? .

Закрытие делается в несколько проходов, при этом прогресс для каждого прохода начинается сначала.
1-ый, как правило, самый длительный и параметры быстродействия на него не влияют. Количество и длительность следующих итераций, как раз зависит от параметров.
Последний - финансовое проведение, вообще без отрисовки прогресса и, естественно, зависит от включенной корреспонденции. (На этом этапе во всех созданных InventSettlement-ах построчно простовляется галочка Posted)

Quote:

Где надо поставить ValueOpen? В INVENTTRANS?

Да в InventTrans есть такое поле, НО бездумное закрытие проводок приводит к долгоиграющим проблемам. В InventSum будут накапливаться записи с пустыми кол-вами и непустыми суммами, а это значит, что не будет в них проставляться флаг Closed, следовательно, всегда при расчете складских запасов, мгновенной себестоимости они будут учитываться... система будет все тормозней и тормозней

Quote:

Вроде ничего не тормозит

А что говорит трейс.. есть ли длительные запросы? какие промежутки между обращениями к БД?
Какая загрузка сети?

Попробуйте 2-х уровневую конфигурацию (приложение, клиент и SQL на одной машине)

[Alex_right]

Quote:

Изначально опубликовано Wamr

Да в InventTrans есть такое поле, НО бездумное закрытие проводок приводит к долгоиграющим проблемам. В InventSum будут накапливаться записи с пустыми кол-вами и непустыми суммами, а это значит, что не будет в них проставляться флаг Closed, следовательно, всегда при расчете складских запасов, мгновенной себестоимости они будут учитываться... система будет все тормозней и тормозней

В документации MBS сказано, что можно из расчета отключить перемещения, поэтому я и спрашиваю про кусок кода, который поможет исключить перемещения. Если же отключать не программно, а установкой на проводках Valuopen параметра,то имели ли опыт установки этого параметра в проводках? Понятно, что если его устанавливать, то по разнесенным перемещениям - бездумно никто этого делать не собирается. Кто-либо так делал??? Если установить этот параметр, то что будет с InventSum, InventSettlment

Quote:

Попробуйте 2-х уровневую конфигурацию (приложение, клиент и SQL на одной машине)

На двухуровневой и делаем закрытие склада

[AndrewZam]

Quote:

Изначально опубликовано Alex_right


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

а) Документация MBS не верна. Перемещения отключать нельзя.
б) На какой версии склад закрываете?
в) Почему такой экзотический выбор - модели "Средняя на дату"? Аналогичный результат даст ежедневное закрытие склада с моделью "Средняя".
г) Проверьте, закрывается ли склад при отключении "Интеграции с ГК"?

[Alex_right]

Quote:

Изначально опубликовано AndrewZam
а) Документация MBS не верна. Перемещения отключать нельзя.

Почему же нельзя исключать перемещения, в случае если склад не является финансовой аналитикой?

Quote:

б) На какой версии склад закрываете?

Закрываем на версии 2.5

Quote:

в) Почему такой экзотический выбор - модели "Средняя на дату"? Аналогичный результат даст ежедневное закрытие склада с моделью "Средняя".

Потому что такая учетная политика. Склад закрывать каждый день нельзя, поскольку есть отчетный период и документы вносятся по мере их поступления. Нельзя забывать и про дату формирования задолженности. Она будет некорректна если склад закрывается каждый день.

Quote:

г) Проверьте, закрывается ли склад при отключении "Интеграции с ГК"?

Может быть и закрывается, но такое решение никому не нужно.

[AndrewZam]

Quote:

Изначально опубликовано Alex_right
Может быть и закрывается, но такое решение никому не нужно.

Закрытие склада состоит из двух частей:
1) собственно закрытие склада
2) выполнение бухгалтерских проводок
Ошибки могут наблюдать в обоих частях.
Суть моего предложения проверить собственно закрытие склада.

[AndrewZam]

Quote:

Изначально опубликовано Alex_right
Почему же нельзя исключать перемещения, в случае если склад не является финансовой аналитикой?.

Потому что, на основании проводок перемещения могут при закрытии склад перезаписываться некоторые поля в InventSum.

[AndrewZam]

Quote:

Изначально опубликовано Alex_right

Потому что такая учетная политика. Склад закрывать каждый день нельзя, поскольку есть отчетный период и документы вносятся по мере их поступления. Нельзя забывать и про дату формирования задолженности. Она будет некорректна если склад закрывается каждый день.

"Странная" учетная политика. Мне казалось, что по налоговому кодексу допустимы три модели: FIFO, LIFO, средняя.

Закрытие склада на каждый день НЕ подразумевает, что каждую ночь ровно в 0:00 запускается закрытие склада за прошедший день. Можно закрывать с некоторым временным лагом +3 дня, то есть в четверг закрываем склад за понедельник.
Формирование задолженности перед поставщиком происходит в момент принятия МПЗ на склад, поэтому комментарий не понял.

[Wamr]

Quote:

Если же отключать не программно, а установкой на проводках Valuopen параметра,то имели ли опыт установки этого параметра в проводках? Понятно, что если его устанавливать, то по разнесенным перемещениям - бездумно никто этого делать не собирается. Кто-либо так делал??? Если установить этот параметр, то что будет с InventSum, InventSettlment

Имеем такой опыт и все последствия описаны именно по этому опыту. Для InventSettlement-а эти проводки просто не будут существовать.

Еще варианты:
- использовать для закрытия приложение без USR-слоя (и без синхронизации с БД)
- пригласить специалистов (за деньги)

[Волчара]

AndrewZam несомненно прав.
Решать все проблемы одновременно не возможно.
Для начала я бы рекомендовал разобраться со скоростью.

Для этого надо включить трассировку SQL запросов.
Я повторяю вопрос: сколько записей в таблицах:
InventTrans,InventDim,LedgerTrans?
Представляет интерес и сколько их всего и сколько их в компании в которой закрыватеся склад.
Ваши 4 процессора вообщемто в этом вопросе особенно ни чего не значат
по моей оценке, если первый загружен на 100% то второй на 15% третий на 3%, а зачем нужен четвертый?
Далеко не многие задачи хорошо распараллеливаются.
Сколько оперативной памяти на сервере?
Конфигурация трехуровневая?
Загружен ли сервер другими задачами?
Лежит ли логика на другом сервере или на томже?
Скорость сети?
Хороший ли локальный комп?

После того, как удастся решить проблему с быстродействием надо попробовать решить вопрос с ошибками.
Я поддерживаю AndrewZam - ошибки ищутся методом деления пополам.
Отключил корреспонденцию - работает - дело в корреспонденции, не работает, ищем другую.

[Wamr]

согласен с тем что сказал Волчара..
еще нуждается в проверки скорость дисковой системы SQL-сервера