Вышла 1.025.1 : Супермаг Плюс (Супермаг 2000)

█ 25.09.2007 10:49

Иван, удалось ли уменьшить время расчёта товародвижения до прежнего значения? Есть сообщение от пользователя о похожей проблеме после перехода на 1.025.1, с причинами пока разбираемся.

█ 25.09.2007 11:23

Время расчёта ТД не удалось уменьшить, что с 1 SP что со 2 SP.
c переходом на 1.025.1 токже увеличилось время заполнение остатками сличительной ведомости

█ 26.09.2007 16:53

Вышел 3SP

20.09.07 (№ 724) SP № 3
SMORA00002998. Кассовый модуль. В формате "УКМ4 Супермаг" не выгружались заблокированные дисконтные карты накопительного типа в таблицу стоп-листа. Исправлено.
ukm4_download.sql
20.09.07 (№ 723) SP № 3
SMORA00003000. Карточки складского учета. Исправлена ошибка "Запись с ключом 0 не найдена в справочнике SMSTORELOCATIONS" при вызове диалога "Движение товара" на странице "Поставки", если в таблице приходов показан полностью закрытый приход.
SmDomCards.dll
20.09.07 (№ 722) SP № 3
SMORA00003003. Кассовый модуль. Исправлена выгрузка наименования товара в неверной кодировке для формата "УКМ2 Супермаг".
SmUKMDesk.dll, SmUKM4Desk.dll

█ 26.09.2007 17:40

После установки SP 3 время расчёта ТД уменьшилось у меня приблизительно в 1.5 раза
но это всё равно ниже чем до установки 1.025.1 в 4-5 раз

█ 28.09.2007 11:09

Попробуй в административном модуле поставь галку "Считать нулевую неопределённую себестоимость по будущим приходам", жми кнопку "Сохранить". Потом снимай эту же галку, ещё раз сохраняй и пересчитывай товародвижение. Данная процедура у меня вернула время расчёта к прежнему значению.
Версия 1.025.1 SP1
Как пояснили разработчики, "при отсутствии записи в справочнике БД повторное обращение к справочнику (внутреннему объекту Супермага) приводит к повторному обращению к БД. В свою очередь, обращение к БД приводит к значительному потреблению ресурсов. Если их по какой-то причине недостаточно, может произойти значительное падение производительности."
В алгоритм расчёта внесены изменения, ждём сервиспак.

█ 28.09.2007 15:41

Цитата:

orekhov ➤ Попробуй в административном модуле поставь галку "Считать нулевую неопределённую себестоимость по будущим приходам", жми кнопку "Сохранить". Потом снимай эту же галку, ещё раз сохраняй и пересчитывай товародвижение. Данная процедура у меня вернула время расчёта к прежнему значению.
Версия 1.025.1 SP1
Как пояснили разработчики, "при отсутствии записи в справочнике БД повторное обращение к справочнику (внутреннему объекту Супермага) приводит к повторному обращению к БД. В свою очередь, обращение к БД приводит к значительному потреблению ресурсов. Если их по какой-то причине недостаточно, может произойти значительное падение производительности."
В алгоритм расчёта внесены изменения, ждём сервиспак.

Проделал так они и есть, от меня спасибо за инфу, время расчёта ТД было 2 часа с хвостиком стало 14 минут

█ 28.09.2007 16:46

Делаю вывод об ошибке, при которой по умолчанию ТД считается с учетом будущих приходов, а "галочка" по умолчанию показывает другое. Это надо будет иметь ввиду тем, кто переходит, ТД изменится.

█ 28.09.2007 18:32

Олег, не уверен в твоей правоте. В таком случае, например, расчёт без галочки у меня занимает 26 минут, а с галочкой следуя твоей логике будет длиться больше 5 часов. Такая "галочка" была бы никому не нужна.
Проверю - сообщу о результатах.

█ 28.09.2007 18:35

Цитата:

Попробуй в административном модуле поставь галку "Считать нулевую неопределённую себестоимость по будущим приходам", жми кнопку "Сохранить". Потом снимай эту же галку, ещё раз сохраняй

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

█ 28.09.2007 20:34

Полагаю, что в любом случае обрабатываются все документы, за исключением закрытого периода. Статистика расчётов на выделенном тестовом сервере такова:
- версия 1.025 - 26 минут
- версия 1.025.1, сразу после обновления - 5 часов 45 минут
- версия 1.025.1, установлена и снята галка "неопр.с/с" - 26 минут
- версия 1.025.1, установлена галка "неопр.с/с" - 25,5 минут
Перед каждым последующим расчётом аналитическая база очищалась.