Контроль отрицательных остатков наоборот
 

Добрый день.
Я никак не могу решить одну проблему сродни контролю отрицательных остатков. Прошу разъяснить что я делаю не так и что нужно, чтобы было так как надо. 1С 8.2, база на SQL. У меня есть справочник мест. Для каждого физического места есть элемент справочника. Есть регистр остатков для учета занятости этих мест. При проведении каждого документа одно из свободных мест программа занимает, т.е. остаток по такому месту становится больше нуля. В документе нельзя выбрать уже занятое место. Пока работал один оператор, то все получалось нормально. Теперь требуется два и более. Я в обработке проведения стал проверять не занято ли в регистре остатков требуемое место прежде чем пропускать проведение. На практике оказалось, что программа иногда дает провести два разных документа на одно и тоже место. Запрос при проверке при проведении возвращал информацию, что место пусто. Наверняка из-за еще не завершенной транзакции при проведении другого документа. Или наоборот, но главное оба иногда проводятся, особенно если одновременно провести. Если будет разница в пару секунд, то уже второй документ видит, что место занято. Я тогда сделал еще одну проверку в событии модуля формы документа проведения "ПослеЗаписи()". Проверяю есть ли остатки по требуемому месту с регистратором отличным от этого документа. Если есть, то откатываю проведение с сообщением. Думал, что это точно решит проблему. Но нет. Все равно иногда проводятся оба документа и увеличивают остатки как один, так и другой. Ну а иногда если даже у обоих документов обработка проведения отработала нормально, то бывает при событии "ПослеЗаписи()" в модуле формы документа откатывается.
Вот я и спрашиваю - подскажите пожалуйста, как правильно и наверняка надо отследить проведение двух документов увеличивающих остатки на одном и том же месте, чтобы не допустить этого? Увеличение остатков по одному месту (ссылка на элемент справочника мест) может быть произведено только одним регистратором.

может у тебя управляемые блокировки, а заблокировать запись забыл?

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

При начале проведения накладывай блокировку на весь справочник мест или на перечень обрабатываемых мест (если это возможно).
.
а вообще - криво сделано. ТОТАЛЬНО КРИВО.
.
факт занятости/свободности места должен ФИКСИРОВАТЬСя ТОЛЬКО ПО ФАКТУ ЗАНЯТОСТИ/ОСВОБОЖДЕНИЯ ЭТОГО МЕСТА.
.
очевидно, что с одним местом ДВА работника не могут РАБОТАТЬ ОДНОВРЕМЕННО.
.
поэтому - если вы так работаете, то сначала "строите" ЗАДАНИЕ на "ПЛАНИРОВАНИЕ РАЗМЕЩЕНИЯ". В зависимости от частностей здесь можно даже неконтролировать при планированиях свободно место еще или нет - т.е. может получиться что на одно свободное место ЗАПЛАНИРУЕТСЯ нескольо размещений - НУ И ФИГ СНИМ!
.
далее ИСПОЛЯНЕТЕ ЗАПЛАНИРОВАННОЕ РАЗМЕЩЕНИЕ. !!! ПО ФАКТУ !!!! - кто первый подошел к ячейке - тот и выполнил:
1. проверить свободна ли ячейка
2. если да - разместить и отметить занятость ячейки
3. если ячейка занята - то либо выплюнуть просьбу на перепланирование либо тут же перепланировать и отправить к новой ячейке.
.
все тараканы от того, что работаета от фиктивного "документа", а не от реального СОБЫТИЯ.

опять же - если размещение не автоматизировано - работаете по бумажке - делай проще. ну и хрен ли что на одну ячейк два размещения.
.
сделают два размещения - если сделали и не пришли с проблемами - считаешь что в ячейке как и сделано доками СУММАРНОЕ КОЛИЧЕСТВО.

если возникла неразрешимая трабла - придут к тебе. переразместишь заново.

то есть тупо: документ записан, но не проведен = задание на размещение.. идут размещают, приносят листочке с отметками. по отметкам проводищь документ.

(2) Ты конфигурацию то озвучь? А то ща как врубишь автоматические блокировки в УТ 11...

7-Reaper >[em]А то ща как врубишь автоматические блокировки в УТ 11..[/em] - просто интересно - что в итоге будет? На сколько я тебя понял - так категорически делать нельзя?

(8) Скорее всего, блокировки вообще изчезнут. В УТ 11 не пользуют конструкцию ДЛЯ ИЗМЕНЕНИЯ, а ручная блокировка в режиме автомата вроде ничего не делает. Вобщем, плохо будет :)

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

Большое спасибо всем за внимание к моей проблеме.
Сегодня переставил у регистра остатков на автоматическую блокировку и больше ничего не делал. Попробовал - стало лишь реже выдавать одновременно одно и то же место, так что опять работал один оператор. Завтра попользую "ДЛЯ ИЗМЕНЕНИЯ" в запросе.
Сейчас кратко изложу для чего это все надо. Дело в том, что куда разместить из имеющихся свободных мест зависит от того что надо размещать. Отдавать это на откуп работнику нельзя, т.к. они иногда даже когда им точно говоришь куда разместить мутаборят, хоть их и штрафуют за это. Поэтому программа, зная что это, предлагает место куда разместить. Оператор, правда, может скорректировать, прежде чем выдать номер места сотруднику. И вот в этот момент у разных операторов высокая вероятность, что программа будет предлагать одно и то же место, операторы согласятся с предложением, почти одновременно проведут, сообщат каждый своему работнику и они повезут в одно и то же место. Нельзя полагаться на то, что один из них поставит на следующее место, вернется, сообщит оператору и тот исправит на другое, т.к. пока эти двое будут размещать уже с десяток таких же сотрудников будут также размещать на места полученные от операторов. И тут начинается весела - четвертый или пятый приходит ставить туда, куда сказал ему оператор, а оказалось, что из первых двух туда уже поставил и пошел сообщать оператору, что он поставил на другое место. Оператору надо раздавать все новые места, а тут уже к нему спешат с корректировками. Поэтому тут даже проще чтобы пока работал один оператор но все шло по порядку. Думали уже, может изменить, а как иначе чтобы не хуже было - на ум не приходит, да и зачем, если можно при помощи программы распараллелить так, чтобы не дублировались места? Там еще куча технологических и организационных ухищрений и загвоздка пока в этом.
Если что, то посоветуйте к чему применять в запросе "ДЛЯ ИЗМЕНЕНИЯ". К справочнику мест? И тогда, если у меня запрос отработал, но я еще не отпустил блокировку, будет значить, что требуемое место в справочнике уже свободно, а в регистре остатков либо еще не занято место, либо уже занято что я и увижу в следующем запросе при чтении остатка, так что-ли? Или вообще сразу одним запросом?

а как устроено?
получается надо оператору провести документ с резервированием места, после проведения говорить место. тогда не будет конфликтов.

справочник мест, регистр сведений с измерением место. тогда документ даже наверное проводится не будет будет ругаться что такая запись уже есть.

Нет, у меня регистр остатков. Мне надо статистику сохранять. Я потом после полного цикла одним махом обнуляю остатки и новый цикл заново с чистого листа, как говорится.

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

(15) Так, я не понял, ты что в регистр накопления пишешь 1 если место занимают и -1 когда его освобождают?

(11) бредятина близкая к полной, еще раз почитай (3) и подумай сильнее. не только про то что написано, но и про то что рядом "леджит"...
.
если автору ломы думать то надо сделать тупо. "блокировку" накладывать на одну "иерархию" раньше.
.
пока не выполнена предыдущая операция размещения(или чего у вас там) оператором1 - оператор2 вообще пусть не может даже начать очередную операцию размещения. то есть операция размещения (а не блокировка какихто умозрительных сущностей) - ЕДИНСТВЕННЫЙ НЕРАЗДЕЛЯЕМЫЙ РЕСУРС. все. и никаких проблем.
.
наличие частых проблем описанных автором в (11) свидедеольствует либо о тотальнйо кривизне вообще самого решения (не вникал) либо о крайней тормознутости самого процесса размещения, т.е. он тормознутый настолько, что постоянно (?) приводит к проблемам...

и ваще... операции размещения выполянемые и инициируемые оператором - это блин полный пипец. я понимаю когда это у меня делается, в самопальной системе на 7000 ячеек. без всяких клинчей и блокирвок.
.
поставь робота - подсовывай ему стек заданий пусть он их молотит одно за одним... одно задание на один "ресурс" - отсутсвуют блокировки.

На 16. Reaper, Что-то типа того только по-разному, то 1, то 2, то ... и 20 бывает и т.д. После отработки полного цикла одним документом обнуляются остатки и дальше все по-новой. А обнулить несложно - списываю по каждому месту то количество, что есть на остатке - под ноль, короче.
На 17. Чучундер, не кипятись, пожалуйста. Я же пишу - там и так куча технических и технологических приколов. Все отлично работает, требовалось только это - чтобы одновременно не выдавалось одно и то же место. Сегодня получилось! Испытания прошли удачно! Прямо так их и проводили - пытались проводить снаряженные на одно и тоже место документы одновременно под счет на три. Ни единой одновременной сработки - всегда занимается только одно место, а у остальных, кто не успел предупреждение и предложение очередного места. Теперь так все устраивает.

Сделал так: сначала включаю блокировку прямо в самих движениях регистра в обработке проведения. Т.е. без проверки занято место или нет. Затем после осуществления требуемых движений запросом выбираю остаток за минусом осуществленного движения. Если после этого остаток ноль, то все нормально - движения только мои, если нет (будет больше нуля), то значит это проведение уже было вторым и параметр обработки проведения "отказ" инициирую в ИСТИНА, т.е. откатываю проведение и далее предлагаю очередное место, согласно тому, что надо разместить. Да, конечно же перевел настройку самого регистра остатков в конфигурации на управляемые блокировки.

Всем большое спасибо, проблема решена.

я возможно мало понимаю в снеговике - но мсье любит извращения...

Чучундер, я возможно не понял сказанного, но смешно ...

(21) ну извращенное решение в (19) череззаднепроходное.
В определенных случаях надо накладывать исключительную блокировку - запрещать даже чтение. То что ты описал - это как оно там правильно называется - грязное чтение... если нет блокировки на чтение - вот такая фигня может получаться.
Где эти определенные случаи - когда нажо накладывать запрет даже на чтение пока не прошла текущая транзакция - вот это как раз и надо понимать и блокировку на чтение ставить только в этих случаях...

в реальности же, чтобы получилась такая ситуация как у тебя - должна быть ну очень длинная работа в транзакции.. настолько длинная, что другой сеанс успевает прочитать грязные данные.
.
отсбда встает вопрос - как получается так, что два задания с планом на запись выполняются практически одновременно? - ясен пень траблы будут если один кладовщик работает с ячейкой и не заблокировал ее типа - звонокм ко всем кладовщикам ... але я работаю с ячейкой - так что даже не пытайтесь с ней работать - откуда кладовщик в другом вагончике знает об этом?
.
соответственно, такой звонок оповещение должен идти ДО НАЧАЛА РАБОТЫ с ячейкой. т.е. даже до чтения данных из нее...
.
а вы в роли кладовщиков запулили еще два быстрых программных процесса - вот они и столкнулись...

именно поэтому, в ахрененно больших и тяжелых системах вмс всегда идет работа по факту. и по факту всегда с ОДНИМ НЕДЕЛИМЫМ ОБЪЕКТОМ. этим и отличаются системы управленяи складами - работа по неделимым квантам.

Поэтому, тове решение еще через жпс потому, что оно скрывает возникающие коллизии - т.е. не позволяет даже увидеть что коллизия возникла чтобы поянть где система построен акриво что допускает коллизии. Именно поэтому, мое решение в (3) - более "правильное" - оно фиксирует возникновение коллизии и явно об этом говорит. что позволит скорректировать/доработать систему чтобы такие коллизии не возникали повторно.

и именно поэтому что "...откатываю проведение и далее предлагаю очередное место, согласно тому, что надо разместить." - нигде в системе не гарантировано, что при второй попытке спланировать - СНОВА НЕ НАРВЕМСЯ на такую же ситуацию... и витоге - ДИДЛОК запросто может вылезть, система впадет в ступор...

а если и не впадет в ступор, то процедура проведения существенно длиннее будет... а в это время сборщик возле ячейки тыкает/жмакает в сканер а он все долюится пытаетсмяданные прочитать - а они в ступоре ивместо того, чтобы заблокировать объекты на 0.03 сек - получитяс блокировка на 0.3сек. Упрощенно конечно излагаю...

Чучундер, спасибо за такое внимание к моей ситуации. Ты так подробно описываешь траблы, от которых меня пытаешься оберечь и др. и клонишь по факту работать - сначала занимать, а потом уже в системе пытаться фиксировать. И еще говоришь, что во всех крупных вмс так сделано. И если с этим не спорить, тогда становится вопрос - так что это неправильно организовано? То, когда требуется выписать товар, сначала читаются остатки, пользователь видит, что есть, а чего нет, затем заносится потребность, потом списываются остатки с блокировкой, потом проверяется не получились ли отрицательные и если нет, то все пучком, а если есть отрицательные, то откат и предупреждение. Если по-твоему, то сначала надо идти на склад, отложить то что надо, а потом забить расходный документ, так что ли? Или я так и не понял что ты мне предлагаешь? Мой случай очень похож на выписку расходного документа. Поэтому я и назвал так тему.

(28) не-не-не! сорри если создал неправильное впечатление.

> и клонишь по факту работать - сначала занимать, а потом уже в системе пытаться фиксировать.
.
все зависит от частностей. При этом ничто не мешает СНАЧАЛА запланировать, потом выполнить. Только планирование - этим должен заниматься кто-то один. Это как Госплан - он на всю страну один был. А у тебя за неразделяемый ресурс два Госплана бьются и мне сильно не понраилось каким образом ты это решил разрулить. но это всего лищь мое маленькое частное мнение.
.
> отложить то что надо
- сначала надо решить что надо и выписать на это по-любасику "расходную накладную"
.
так что ты все верно излагаешь. я предлагаю всего лишь одно: планированием должен заниматься один "человек". тогда и траблов тобой описанных не будет.

> Но нет. Все равно иногда проводятся оба документа и увеличивают остатки как один, так и другой
.
проблема здесь. документы не могут увеличивать остатки в ячейках. точно так же как их и уменьшать. Увеличение/уменьшение выполняется конкретным ДЕЙСТВИЕМ размещения в ячейку или изъятия из ячейки. А уже потом по факту выполнения атомарных операций возникает РЕЗУЛЬТИРУЮЩИЙ итоговый документ - который к ДВИЖЕНИЮ ТМЦ практически не имеет никакого отношения. А ты танцуешь наоборот сначала делаешь документы...
.
все зависит в какой ты системе работешь, если какая-то УТ - то придется идти по примерно товему пути - ибо УТ нацелена исключительно на регистрацию уже свершившихся фактов. что к СКЛАДСКОЙ РАБОТЕ весьма далеко.
.
ясен пень надо смотреть вдумчиво.. особенно если документ типа "Планирование чего-то". Так что творчеки преломляй и внедряй. ну и относись критически к любым советам - лучше тебя все равно никто не знает что и как.
.
Единственное меня напрягает - нихрена не пойму почему БОЛЕЕ одного оператора ПЛАНИРУЕТ размещение в ячейки? почему этого не может делать один?

30-Чучундер > А вот это-то и есть тот гвоздь, из-за которого проиграна битва... ;)

(31) угу... один гедон

Один планирует - низкая пропускная способность. Успевают набиваться работники, которых тоже надо обработать. В обработку у одного оператора входит определить что вывозится и предположить в какой области надо разместить - компьютер, то предлагает, но на ввод информации уходит некоторое время. Пока так. Позднее планирую изменить цепочку и автоматизировать ввод этой информации раньше, а тут уже только раздавать места. Тогда можно будет укладываться с одним оператором. А пока никак.

(33) не понял при чем тут "вывозится", если в (0) идет речь о ЗАНЯТИИ мест...
.
> предположить в какой области надо разместить
у вас решение что в какую ячеку поставить принимает ОПЕРАТОР? на основании каких-то исключительно ему доступных данных..? таких, которые не формализованы и не могут быть обработаны компом?
.
> компьютер, то предлагает, но на ввод информации уходит некоторое время.
- совсем непонятно, если комп предложил и вы в целом согласны с его предложением - что мешает грубо говоря "на основании" предложенного компом ввести пару кликами бОльшую часть информации...?

(33) озвучьте, какая система управления складом используется? самописная автономная конфа? что-то штатное из типовой УТ? самописки к УТ?
.
если у вас такой живой и подвижный склад, что пока ОПЕРАТОР планирует - успевает набиться толпа работников - то либо у вас существенный избыток работников, которым делать нечего или что-то вообще не так.. потому что всегда операции размещения и отбора СУЩЕСТВЕННО по времени БОЛЬШЕ времени планирования этих операций - так что ну блин никак не могут быть свободные люди которые в очереди стоят... и даже если вдруг образовалась очередь - то ну пусть постоят 1-2-3 мин, пока идет планирование - после того как спланировано - они все будут заняты работой и очередь как бы должна рассосаться... как-то так я себе представляю...
.
опять же - может не стоить делать самописку, пока это все не увязло - а посмотреть в сторону норамльных wms-систем?

(33) чисто интересно - а сколько времени у вас занимает ПЛАНИРОВАНИЕ отбора заявки (сбор товара для отгрузки), например для заявки строк в 600..? у меня это занимает - несколько секунд... с планированием размещения - конечно подольше будет, потому что задача чуть посложнее планирования отбора..

(33) как вариант - посмотри [url]http://www.arenawms.ru/freewms.html[/url]

(37) Подскажи тупому, где ссылка на скачивание?

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