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

(0) не мешали и затирали данные - немного разные вещи

(1) не поспоришь

(0) Не советую. С реализацией замудахаешься. Кто первый встал того и тапки.

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

(0) При открытии документа в регистр сведений пишется какой-то флаг. Если кто-то пытается открыть - флаг читается и документ открывается только напосмотреть. При закрытии - флаг убирается. Это примерно как в ДО, когда можно занять документ на редактирование и держать пару дней за собой, чтоб никто в нем свои правки не понаоставлял.

(0) Легко.
В форме документа добавить в начало процедуры "ПриСозданииНаСервере"
У нас немного не так реализовано конечно как описано в (0)
Кто первым зашел, то и папа, пока не закроет.

	Попытка
		ЭтотОбъект.ЗаблокироватьДанныеФормыДляРедактирования();
	Исключение
		Сообщить(ОписаниеОшибки());
		ЭтаФорма.ТолькоПросмотр = Истина;
	КонецПопытки;

В описании ошибки пишется, кто сейчас заблокировал форму.

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

(7) ну классический пример документ инвентаризация, где несколько операторов параллельно забивают результат инвентаризации (по крайне мере многие так хотели бы)

(8) Пусть факт каждый в своем документе значит набивает.

(8) Ага, по учету 10 штук, первый оператор нашел 7 штук, забил - 7, второй нашел 3 штуки - забил 3, итого было 10 стало 3.
Это решается другими способами:
а) Разбиением одного документа инвентаризации на десяток по разным товарным группам, и каждый занимается своей товарной группой.
б) введением промежуточного документа - в который собирается факт от каждого оператора, потом суммируется и переносится как факт в единую инвентаризацию.
95% задач требуют не изменений в коде, а элементарного наведения порядка (в первую очередь в голове), ибо хаос не автоматизируем в принципе.
P.S. была у нас на филиальном складе история. Там хранилось 4 станка, и пришло время проводить инвентаризацию. Срочно в головной звонит старший по складу - станков нашли всего 3!!! (а станок более миллиона стоит), все в панике... Кто-то догадался включить камеру наблюдения на складе и посмотреть, что там творится. Склад имел два прохода, разделенные капитальной стеной посредине, по обоим проходам по сторонам шли стеллажи и паллетоместа, и склад имел как бы форму кольца. Наблюдаем картину - по складу по часовой стрелке идет старший с ведомостью и пересчитывает станки стоящие на паллетометсах. Три станка. А по второму проходу, тоже двигаясь по часовой стрелке, младший кладовщик тащит на тележке четвертый станок, и ищет куда бы его пристроить, чтоб более рационально занять места на складе...

(7) у нас была такая попытка. Набивка одного заказа несколькими операторами. То бишь в магаз ехал большой набор продукции, разной. Например, один оператор набивал болты, второй гайки.
Я блин извернулся, и сделал. Но по итогу нафуй не надо было. Потому что сбор был на разных складах, разными сборщиками. И делить надо было на сборку.
По итогу все выродилось. Куча заказов, одна расходная накладная.

(11) вот именно. Максимум сделали механизм "объединения" заказов, когда несколько распроводятся и проводится один как их объединение.
Но ситуация интересная тем, что в общем случае скидки изначальных заказов и итогового могут не совпадать по понятным причинам.

(5) если сеанс отвалился - док остался "блокированным"...

(13)Решается. Модератор этого хаоса имеет кнопку снять флаг.

(14) решается, но не так же. перед запуском базы в сеансе промониторить все и почистить неактуальное. нужна будет привязка к сеансу например или к IP, и вобще два раза одну базу на одном компе открывать нельзя чтобы за одно сделать

(15) "два раза одну базу на одном компе открывать нельзя" - ну это глупо так-то

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

(0) Можно, но придется свой регистр хранения информации об открытии писать.

Если у вас открыть может любой, но редактирует кто-то один.
То можно , идеи для вас...

1. При открытии блокировать документ, и кто первый, того и тапки.

2. При открытии, не блокируем. Но как только пользователь документ модифицирует, документ блокируется.
   Блокировка выполняется по обработчику ожидания, если пользователь поменял документ, то пытаемся заблокировать :)
   После успешной блокировки отключаем обработчик.

(16)

Встречал несколько раз (давным давно).

На одном из мест работы, как средство от "максимально тупых пользователей", которые в силах свернуть 1С, но не в силах самостоятельно увидеть 1С в таскбаре и запускают 2..N сеансов за день

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

(16) да ну, от ситуации в общем зависит, и с лицензиями в частности, на 8.2 такую белеберду сделали, чтобы лишних лицензий не поглощалось самим сеансом + еще СОМы поднимаются. На РС все, анализ, подтирка неактуального и т д, все как для (0)
(17) )) это правильно, чтоб жизнь медом не казалась

(0) Если только сигнализировать то ЗаблокироватьДанныеФормыДляРедактирования
Если полноценное редактирование то обработкой через буфер

(0) Лучше сразу избавляться от хаотичного редактирования всеми всего. Один документ - один пользователь. Как только начинается редактирование одного документа всеми, проблемы появляются прям шквально. Всегда всё надо сравнивать с работой без компа, только на бумажках. В каком случае, например, два кассира будут выписывать один чек? Да ни в каком. Значит так же должно быть и в компе
Не правильно это. Прям очень не правильно

(23) и как, интересно, избавиться от функций, которые предоставляет сама 1С из коробки? конечно, в идеале вообще не бывает коллизий. В заказе клиента реализовано две функции - резервировать товар и отгрузить. резервируют менеджеры, отгружают кладовщики. бывает, что надо работать в одном документе двоим, потому что в 1С придумали частичную отгрузку. это ещё не считая кассира, который принимает оплату по документу (может поменять в заказе пометку какую-нибудь) и бухгалтеров, которым нужны проводки.

(24) Глупость какая то. Обычно резервирование делается документом резервирование, а отгрузка реализацией. У вас опять же хромает логика реализация задачи.

(25) это ерп, стандартная конфигурация. я же написал, из коробки. отгрузка делается реализацией, да. только для реализации надо товары в заказе перевести в статус отгрузки.

(24) Где предоставляет? Как только первый пользователь запишет свои изменения, все остальные при попытке записать свои получат уведомление, что объект изменен и они в пролете. Никакого множественного одновременного редактирования документа как ссылки нет. есть возможность редактировать копии объекта, а это принципиально разные вещи.

(26) В ерп я нуб, но уверен по логике в 1С, что такое можно не только в самом заказе делать.

делается так

1. на форме НЕ используем реквизиты объекта, а используем только аналогичные реквизиты формы (форму придется сделать свою)
2. перед записью проверяем версию объекта с той версией которая считана формой,
3. если версии разные - читаем обьект и сравниваем реквизиты объекта с реквизитами формы, если есть критические расхождения - отображаем.
4. ну и где-то блокировка нужна...

(24) а почему кладовщик лезет в управление заказами клиентов?  Статус "Отгрузить" устанавливает условный менеджер, а уже это действие является распоряжением на отгрузку условным кладовщиком.

Прежде чем ломать архитектуру, лучше посмотреть как это проектировали разработчики типовой и как ваши процессы на это ложатся. Может дело не в бобине.

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

[не в тему]
Однажды довелось решать интересную задачу:

Менеджеры по продажам, оформляя заказ покупателя в диалоге с покупателем, хотели видеть не только остатки и резервы товара, но и те позиции товара, которые присутствовали в открытых, но ещё не записанных документах других менеджеров.

Цель? Чтобы один менеджер вовремя мог предложить своему покупателю другой товар или оперативно сообщить другому менеджеру о возникшей "конкуренции" за товар и решить оперативно эту проблему, пока документы ещё не записаны и оба покупателя на проводе у менеджеров.

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

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

Все согласились. Один еврей подумал:
- Если все принесут по бутылке водки, и только я принесу бутылку воды,
никто и не заметит.

На следующий день приходят все евреи с бутылками, сливают их в один чан.
Раввин наливает оттуда одну стопку, пробует и говорит:
- Вот за это-то нас русские и не любят!



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

(24) >> и как, интересно, избавиться от функций, которые предоставляет сама 1С из коробки?
Если отходим от компа, то как такое будет делаться? Бумажка передаётся последовательно от одного сотрудника к другому. Они одновременно не пишут в одной бумажке, ведь так? Поэтому есть предположение, что надо почитать документацию от ERP. Не знаю как так получается, но в 1С работают далеко не самые глупые люди и на многие "очевидные" вещи у них есть конкретные рекомендации и документации.
Именно в ERP подобное не изучал, поэтому только предполагаю

далеко не самые глупые люди и на многие "очевидные" вещи у них есть конкретные рекомендации и документации

это даааа
жалко что уже нет тех, которые делали базу платформы, на основе которой теперь умные люди пишут документацию
там глюк на глюке прет и это не остановить

+(32) Вспомнил потому, что вся эта информация оперативно отражалась непосредственно в табличной части заказа покупателя. Что, если подумать, не так уж сильно отличается от задачи автора ветки.

(32) В принципе решаемо. Пара вариантов разной степени бредогеморройности в голову приходят. Но ни один мне не нравится.

(37) РС с временными записями юзали?

(38) бредоненравится тоже. да, но если определить в реальности, что является фактом забора остатков, то можно и в программе сделать. Девочка взяла товар в ТЧ, это? Чепуха же. Она там покурит, чая попьет, откажется. Процесс надо понимать, это как всегда первоочередное, а табличек намутить не проблема

(39) Да. "но есть один нюанс"(с) :) на форме открытого документа, вместо записей ТЧ документа, напрямую показывались записи РС. При открытии документа записи ТЧ копировались в РС, а при сохранении документа - перемещались из РС в ТЧ документа.

(40) Бред или нет - это зависит от постановки работы в конкретной фирме. Если менеджер висит на телефоне и ему надиктовывают список из 2340 позиций, каждую из которых еще надо обсудить (тех.характеристики, взаимозаменяемость и т.п.) он, разумеется хочет быть уверен, что то, что он набрал в заказ не превратится в тыкву, когда он будет проводить документ. Поэтому, например, возможна такая схема: манагеры набирают заказ не в форме заказа, а в специальной форме, где у них открыт сразу весь каталог, и они могут против каждой позиции видеть текущий свободный остаток, количество и срок ожидаемого к поступлению, цену и т.п. (обработка порциями, по строкам, что на экране + столько же строк вверх и вниз по списку, т.ч. их не будет много и пересчет только при смещении экрана на количество позиций равное или большее половине экрана - тогда тормозов не будет). Сразу после окончания редактирования строки записывается резерв по этой позиции с проверкой, чтоб он не ушел в минус (если двое одновременно попытались забрать остаток товара) (запись по одной позиции без остальных проверок - поэтому тормозов не будет). После окончания работы манагер переводит весь этот список в заказ и начинает работать со скидками, сроками отгрузки, оплатами и т.п - но товар уже заблокирован за ним, пока он не проведет этот заказ.

(0) Или вся эта идея плохая?....

это не плохая идея...а очень очень плохая

(42) да, скоро я такую же систему буду колхозить, судя по всему...

Когда требуется (0) вероятно проблемы с архитектурой
Например строки ТЧ дока это разные документы должны быть

(45)+ Довольно часто в WMS "сборочный лист" состоит из отдельных позиций
И да их могут "собирать" отдельные сотрудники каждый со своими ТСД
А потом опс и пытаются писать в один док одновременно

Хотя фактически надо отделить "сборочный лист" и "задание на сборку"
Возможно с промежуточным(ми) РС и регзаданием, которое всем этим дирижирует

(45) +1
Проблема вобора уровня"дискретизации данных"....

фундаментальная проблема теории информации