[ОТВЕТИТЬ]
09.11.2015 11:53
DMaslov
 
Обнаружил такое.

Очевидная причина - кривизна рук программиста. Чего-то полез править, и недоправил.

Но, может, кто подскажет какие-то штатные (без залезания в БД руками) ситуации, когда такое получается.

SQL код:
select rest_doc.articlerest_doc.quantitysmgoods.quantity
  from 
(
select spc.articlenvl(sum(
                               
decode(head.doctype,
                                      
'WI'spc.quantity,
                                      
'CR'spc.quantity,
                                      
'CS', -spc.quantity,
                                      
'WO', -spc.quantity,
                                      
0
                                     
)
                           ), 
0
                       
quantity
 
  from smdocuments head
smspec spc
 where head
.doctype spc.doctype
   
and head.id spc.docid
   
and (head.location or head.locationfrom or head.locationto 6)
 
group by spc.article
       
rest_docsmgoods
 where rest_doc
.article smgoods.article
   
and smgoods.storeloc 6
   
and rest_doc.quantity != smgoods.quantity 
09.11.2015 11:58
Mtirt
 
А вы уверены, что все документы движения товара учли?
Нет перемещений? Нет производства?
09.11.2015 17:05
DMaslov
 
Просто так я проверять не взялся бы, разумеется. Заметили по некоторым артикулам такое расхождение, и мне сообщили.

SQL код:
select head.doctypeap.appnamecount(1)
  
from smdocuments headssdoctypes dtsmclientapps ap
 where head
.doctype dt.doctype
   
and dt.appmodule ap.id
 group by head
.doctypeap.appname 
09.11.2015 17:11
Mtirt
 
Штатно, увы, уже много лет остатки не разбегаются...
Кстати, в исходном запросе статусы документов учитываются? Неужели нет заблокированных или в черновике приходов/расходов?
Штатная процедура наведения порядка находится в адм.модуле и называется "Перерасчет остатков".
09.11.2015 17:13
OlegON
 
"Не смешно, зато про войну" :)
Вопрос-то был, что в первом запросе учитываются, например, не все документы товародвижения. Сравнивать теплое с мягким нет смысла.
Для начала прогоните перерасчет остатков в этом месте хранения, чтобы не ломать голову, что, кто и где там напортачил.
А потом сядьте узким кругом принимающих решение лиц и определитесь, зачем вам такой геморрой с ручной заменой шестеренок на ходу.
09.11.2015 17:29
DMaslov
 
> Неужели нет заблокированных или в черновике приходов/расходов?

Это забыл учесть, спасибо.

> Вопрос-то был, что в первом запросе учитываются, например, не все документы товародвижения.

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

> прогоните перерасчет остатков в этом месте хранения, чтобы не ломать голову, что, кто и где там напортачил.

По сути, мой запрос, с напильником, решает ту же задачу.

> Штатно, увы, уже много лет остатки не разбегаются...

Ясно.
09.11.2015 17:38
Mtirt
 
Цитата:
DMaslov
По сути, мой запрос, с напильником, решает ту же задачу.
Не решает, так как статусы документов не учитывает.

С изменениями скриптами smgoods я бы поступала поосторожнее.
Там еще ожидаемое количество есть, которое меняется заказами и приходами. Еще и его можно "порушить". А еще, что будет, если кто-то во время изменения остаток надумает исправить документ?

Штатный перерасчет остатков избавляет от проблем в smgoods в основном потому, что делается при монопольном доступе к базе.

Ну и хорошо бы сделать ревизию всего собственного кода на предмет выявления источника расхождения остатков.
09.11.2015 17:39
Mtirt
 
Цитата:
OlegON "Не смешно, зато про войну" :)
Вопрос-то был, что в первом запросе учитываются, например, не все документы товародвижения.
Судя по второму запросу и перчисленным типам документов учитываются все имеющиеся в базе.
09.11.2015 18:31
DMaslov
 
Цитата:
Mtirt Не решает, так как статусы документов не учитывает.
С напильником, head.docstate = 3, и блокировки.

Цитата:
делается при монопольном доступе к базе.
Да, я уже понял, что у СуперМАГа - это решение всех проблем.
09.11.2015 19:03
OlegON
 
Цитата:
DMaslov Да, я уже понял, что у СуперМАГа - это решение всех проблем.
Надо отметить, что проблема в большинстве случаев только одна - кривые руки, полагающие, что если что-то крутится, то это обязательно надо покрутить :)
10.11.2015 09:25
akonev
 
Цитата:
DMaslov С напильником, head.docstate = 3, и блокировки.
остатки меняются начиная со статуса 2 !!!

главная причина подобных расхождений - как раз таки напильник:
меняют статус документов прямыми запросами к базе без понимания механики супермага.

осторожнее с напильником.
22.11.2016 16:28
DMaslov
 
> Штатно, увы, уже много лет остатки не разбегаются...

Поймал ситуацию.

Всего 3 документа. В базе магазина остаток правильный, 1, в центре - нет, 0.



В SMGOODS в центре отсутствует строчка. Поправил руками.

Теперь уже точно не руки программиста, ибо последние полтора года программист - я, и такого - удаление из SMGOODS - я не делал :).

1.030.1 SP4

Так что "много лет" - еще не гарантия.

Познакомился с СуперМАГ-УКМ2 в 2001-м году, но и сегодня каждый день открытия бывают :).
22.11.2016 16:53
OlegON
 
Не очень понятно...
Причину удалось найти? Из магазина какой-то пакет не пришел, например... Так тот пакет и надо найти, мало ли что в нем еще было...
09.12.2016 11:14
DMaslov
 
> Причину удалось найти?

Пока нет.
15.08.2017 16:45
DMaslov
 




select * from smgoods where article = 207550 and storeloc = 38 - пусто, нет строк

СервисПлюс не предложил ничего лучше, чем "В административном модуле выполните процедуру «полного перерасчета остатков»."
15.08.2017 16:59
Dim
 
а чем не устраивает полный пересчет остатков?
15.08.2017 17:00
Dim
 
а если опустить накладную в черновик, что показывать будет?
15.08.2017 17:00
Dim
 
а если потом снова до 2-х зеленых?
16.08.2017 06:55
Mtirt
 
А кнопка "Остаток на начало" на первом скриншоте почему отжата?
16.08.2017 06:58
DMaslov
 
> а чем не устраивает полный пересчет остатков?

Тем, что это исправление последствий ошибки, а не ее причины.

> а если опустить накладную в черновик, что показывать будет?

Остаток -1.

> а если потом снова до 2-х зеленых?

Остаток 0, теперь строка в SMGOODS есть.
16.08.2017 06:58
DMaslov
 
> А кнопка "Остаток на начало" на первом скриншоте почему отжата?

Не знаю, никогда не пользовался, версию 1.033.4 установили недавно.
16.08.2017 07:30
Mtirt
 
Нажимать пробовали???
16.08.2017 07:38
DMaslov
 
Да, пробовал.
Остаток на начало = 0 как в случае отсутствия строки в SMGOODS, так и в случае ее наличия.
16.08.2017 07:57
Mtirt
 
Тогда только пересчет остатков.
И подумать: какое внешнее ПО может на это влиять, были ли отключения триггеров, проблемы с базой?
16.08.2017 08:07
DMaslov
 
Внешнее ПО есть, в SMGOODS оно не пишет.
В процедурах проводки некоторых документов есть мой добавочный код, но только добавочные проверки, не касающиеся SMGOODS. Если уж они срабатывают, то raise отменяет транзакцию.
Триггера отключаю исчезающе редко, когда копаюсь в алгоритмах.
Особых проблем с базой не было.
Допускаю, что причина все-таки мои шаловливые ручки, но как отследить, пока не знаю. Да и проблема эта видна все 2.5 года работы с СуперМагом, а в начале работы я ничего не правил. Впрочем, возможно, правил мой предшественник, и эти правки не затерлись даже обновлением 1.30-1.33.
Проблема наблюдается только на документах, пришедших почтовым модулем. В тех базах, откуда документы пришли, SMGOODS в порядке.
16.08.2017 08:12
Mtirt
 
Вариантов вижу два:

1. Проверить настройки мест хранения. Может быть просто отключен перерасчет остатков в этой базе (закладка "Логистика")
2. Проверять все свои проверки. При получении документов почтовым модулем, они тоже срабатывают. И если по ним ошибка, следующие операции (в том числе и изменение остатков) могут не срабатывать.
16.08.2017 08:23
DMaslov
 
1. Проблема наблюдается лишь на небольшом проценте товаров, не более 1%.
2. Посмотрю.



А остаток так и остался неверным.

Буду терзать СервисПлюс, посмотрим код этого перерасчета.
16.08.2017 08:40
Mtirt
 
Перерасчет не там делаешь.

База данных - Утилиты - Перерасчет остатков.
16.08.2017 10:07
-Den-
 
Цитата:
DMaslov
> а если опустить накладную в черновик, что показывать будет?

Остаток -1.
В smgoods? То есть получается остатки то считаются.
Опции темы


Часовой пояс GMT +3, время: 02:43.

 

Форум сделан на основе vBulletin®
Copyright ©2000 - 2018, Jelsoft Enterprises Ltd. Перевод: zCarot и OlegON
В случае заимствования информации гипертекстовая индексируемая ссылка на Форум обязательна.