Борьба с отрицательными резервами в УТ 10.3??
 

Используется
Заказ клиент (он же резервирует товар путем построчного выбора склада)
Реализация товаров и услуг (создается на основании, она же в теории должна снимать товар с резерва)
Пользователи могут править доки задним числом.
База перепроводится ежедневно.
Документы : Корректировка заказа, Резервирование товара,
Закрытие заказов - не используется..

Сравнительно недавно начали появляться отрицательные резервы их видно при подборе товара.

Вопрос как побороть штатными средствами и избавиться от уже
созданных ...?? Спасибо..

Что уже изучено по этому вопросу:
1. Допиской контроля не победить - ибо "не опративно" система не дает контролировать.
2. Где то вычитал , что использование Корректировка заказа, Резервирование товара решает эту проблему - не могу внедрить манагеры востанут...

Есть еще решения?? Спасибо..

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

Много мероприятий нужно. Проведение манагерами заказов только в оперативном режиме, все исправления только Корректировкой заказа покупателя. Все закрытия только с проверкой, чтоб не ранее самого заказа, и при закрытии корневого заказа отменяются все вышестоящие резервы. И еще куча всего. И розг с горохом не жалеть...

(0) проходил аналогичную ситуацию много раз.
если ты в конторе никто и фамилия товя никак - то забей. лично тебе отрицательные резервы не мешают - не мешают! ну и пофиг значит!
.
Манагеры - не восстанут.
если нужно вести работу правильно - то этого надо добиться.
Опыт - неоднократный - показывает что этого достаточно за 1 неделю.
.
Сразу и полностью закрывается неоперативная работа с заказами. Вот прост так. и все.
.
если надо - стоишь день-два-три в офисе за спиной у менеджеров. И отвечаешь - нет, нет, по-старому не будет,почему - потому что! делать надо вот так - показываешь. основное - манагер должен понять что не он здесь решает что полезно бизнесу в этом участке работы. и что ему самому будет дешевле делать так как надо. а не так как хочется. То есть тупо занимаешься дрессировкой (это и личные скиллы прокачивает помаленьку)
.
основное - закрыть все что можно то что приведет к нежелательным ситуациям.
.
все.

Спасибо огромное за развернутые ответы....Пошел применять все выше сказанное...

И за уделенное время....так же отдельный поклон

Если пользователи правят задним числом можно решить последующим "перепроведением" с восстановлением последовательности. Только не просто за текущий день, а именно с даты когда "неоперативно" провели любой документ влияющий на резервы/товары, и до текущей даты. Вот тут вопрос, если "полезут" в месяц назад, успеет ли за ночь всё провестись? А если на несколько месяцев назад?) Поэтому проще и надёжнее конечно права порезать чтоб только оперативно проводили и вводили "корректировку" заказа если его надо менять задним числом.

[quote=31337;47463356]Если пользователи правят задним числом можно решить последующим "перепроведением" с восстановлением последовательности. [/quote] не всегда поможет. пример, на 01.02.10 в резерве под заказ №001 было 10 пачек макарон (весь остаток), 05.02.20 сделали по заказу реализацию А001. А 10.02.20 влезли в заказ №001 и убрали из резерва макароны и поставили их все в резерв заказу №002... при перепроведении реализация А001 сообщит о невозможности проведения, т.к. по указанному заказу нет под нее резервов, и свободных остатков тоже нет...

6-31337 > точно могу сказать , сели мы на 10 ку с января этого года, база перепроводится ежедневно, начина с остатков 21-12-2019 кончая текущим днем .. не помогает.
7-bma1 > данная версия формирования отрицательных остатков более реальна...

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

соответственно применение такого допила а) блокирует нехорошую работу хитрожопых и б) всегда гарантирует перепроведение (котрое является чисто технологической орпераций и вполне может получится что вообще нафиг не нужно)

10-Сергей Че > Огромное спасибо. Можете пояснить в чем суть допила, в деталях , я допилю. Просто нужно направление.
11-Gosha > Не вариант, так как есть заказы не закрытые и выстреливают спустя дней 10 легко...а если делать Закрытие он на сколько я вообще понял снимает все резервы и долги..

(12) я рекомендую использовать вариант в (11). Закрытие заказа делается ОСОЗНАНО менеджером. У менеджера д.б. удобный инструмент (арм/отчет/итд), в котором сразу видны все АКТИВНЫЕ (незакрытые, то есть по которым есть остаток количественный/суммовой и не важно правильный это остаток или "неправильно").
.
"Закрытие заказа" хз как там сделано в типовых, я по опыту 77 говорю (идефя везде примерно та же самая). в 77 был такой документ "снятие резерва" (это не эквивалентно закрытию заказа!), где надо было конкретно указывать количество снимаемое с резерва. В результате задних поползновений и восстановления ГП - такие доки бывало не прводились с выдачей сообщения типа "количество, указанное к снятию с резерва превышает количество в резерве" - ну превышает и чтио? сними сколько можно снять, главное не превышай ууказанное в документе снятия - в результате доппилили модуль проведения именно так. Но это было давным давно и потом ушли от этой схемы на схему "закрытия заказа" полностью (документ "Отмена заявок покупателя"), это оказалось прозрачнее и поянтнее менеджерам - проще полностью снять заказ и ввести новый как надо (такая схема в условиях только "заказ на склад"). Ну и в 77 была ввод заявки на основании заявки (корректировочная заявка) - тогда заяувка-основание занулялась, а новая заявка (корректировочная) писала текущее состояние (но там в модуле проведения были какие-то недоработки типа ка краз связанные ч тем что смотрелись -по-моему- только правильные остстаик, а неправильные остатки так закрыть не удавалось или анализировался только количественный остаток по заявке, а подвисшую сумму без количества так не скорретируешь)
.
Направление: осциллирующая во времени функция остатка есть сумма монотонно убывающих функций...

13-Сергей Че >осциллирующая во времени функция остатка есть сумма монотонно убывающих функций... - не вопрос! А просто закрытие на не оперативное проведения координально не сможет решить этот вопрос???

14-alex55 > Почти сможет. так и надо сделать.
но изредка все же бывает надо "залезть взад".
и тут должно действовать правило (в части каких показателей - выбираешь сам, для примера - в части остатков) "изменение в заднем числе допускается только В БОЛЬШУЮ строну" т.е. ведет на увеличение остатков - тогда можно. Можно задним числом впихнуть Поступление тмц. Можно задним числом вычеркнуть из реализации строку/количество. Умны бухи радостоно хурачат перемещенич задним числом - оно же увеличивает остаток на складе. Тогда приходится публично унижать, указывая что на складе-источнике приводит к уменьшению остатка. ну итд.

15-Сергей Че > Я понял, спасибо!!

16-alex55 > но надо учитывать, что например манипуляции с увеличением остатка на складе (что безболезненно) могут одновременно приводить к уменьшению остатка резерва, что ведет к появлению незакрытых заявок...
.
тут, как выше писал имхо у мены все что касается "физики" остатки и проч. - ведется в ТА. а весь "воздух" (суммы бонусов/премий, взаимозачеты и прочее) - могут и взад вводить, это не мешает текущему состоянию "остатков" и оперативной работе манагеров и база пересчитывается без проблем...