Проблема в следующем:
Система блокирует одновременное изменение двух разных заказов к одному приложению (количественный контракт) к договору (групповой контракт).
Подскажите, как можно побороть эту блокировку?
Заранее спасибо

Немного неясно, что Вы имели ввиду под "к одному приложению (количественный контракт) к договору (групповой контракт)".
Но посмотрите ноту 107199, и аналогичные.

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

ещё проще если - то у вас на один ТД типа контракт созданы два ТД типа Заказ. Хочется редактировать одновременно два заказа разными пользерами.

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

если по логике, то в Контракте 100 тонн, в заказе1 - 30 тонн и в заказе2 - 40 тонн. Одновременное редактирование, например, тоннажей в заказе может привести к тому, что у нас окажется и контракт на 100тонн и оба заказа по 100 тонн - итогог 200 по заказу. Это нехорошо и неправильно. С другими данными такая же печенька. Поэтому логичная блокировка на мой взгляд

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

Когда изменяем первый заказ, ФМ SD_SALES_DOCUMENT_ENQUEUE установливает блокировку для его документа предшественника. SM12 - обзор блокировок. Когда заходим на изменение второго заказа, при активном режиме изменения первого заказа, этот же ФМ SD_SALES_DOCUMENT_ENQUEUE пытается опять установить блокировку на уже установленный док. Таким образом, сняв в каком нить екзите блокировку, которая устанавливается, когда входим в режим изменения первого заказа, получите желаемое Но это наверное только начало всех проблем

Justudent совершенно прав(а) - так работает стандарт и, для поддержания data integrity, все как раз так и должно работать. Когда создаются/изменяются последующие документы, предыдущий документ тоже блокируется, т.к. действия с последующими документами могут повлечь за собой изменения в нем тоже. Если вы хотите делать блокировку только в момент сохранения (что не совсем правильно, мягко говоря), то вам придется писать свою транзакцию. Хотя полагаю, что юзеры будут не очень рады, когда после долгих раздумий у экрана они при сохранении получат сообщение типа "ха-ха, а вот и обломитесь - заказ заблокирован!".


Да вообще придумали ерунду - блокировки еще какие-то. Устроить лотерею: кто первый нажал, у того изменения и сохранились. Юзеры наверняка это оценят по достоинству.

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