Как блокировать одновременный доступ к Заказу?

[блондинка]

Товарищи по Axapta, подскажите, пожалуйста, никто не сталкивался с такой задачей:

Необходимо не допускать одновременной работы 2х и более пользователей в одной шапке(строках) Заказа/Закупки.
Работаем на 2х звенке, Axapta 3.0.

Цитата:

Сообщение от блондинка

Товарищи по Axapta, подскажите, пожалуйста, никто не сталкивался с такой задачей:

Необходимо не допускать одновременной работы 2х и более пользователей в одной шапке(строках) Заказа/Закупки.
Работаем на 2х звенке, Axapta 3.0.

Глупый наверное вопрос, но зачем?

[glibs]

lagr221374, на ник посмотрите.

А вообще речь идет о поиске стандартной функциональности или о том, как выполнить доработку?

Первого нет, а второе можно почерпнуть в журналах ГК и складских журналах.

Цитата:

Сообщение от glibs

lagr221374, на ник посмотрите.

А вообще речь идет о поиске стандартной функциональности или о том, как выполнить доработку?

Первого нет, а второе можно почерпнуть в журналах ГК и складских журналах.

Ну почему нет первого? Можно создать одного user-а и только ему дать права для работы с заказами. Все остальные в сад...
Другой вопрос что для работы это не удобно...но такова жизнь

[mazzy]

Цитата:

Сообщение от lagr221374

Можно создать одного user-а и только ему дать права для работы с заказами.

Радикально.
Вообще говоря, лучше настроить RLS на поле Ответственный продавец.
При создании это поле заполнять в обязательном порядке.

[блондинка]

Большое спасибо за активное участие!

Жизненная ситуация такая:

Выделить отдельного "ответственного" за Заказ административно невозможно, да и не требуется. Желание только не мешать друг другу одновременной работой.

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

Цитата:

Сообщение от блондинка

Большое спасибо за активное участие!

Жизненная ситуация такая:

Выделить отдельного "ответственного" за Заказ административно невозможно, да и не требуется. Желание только не мешать друг другу одновременной работой.

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

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

[блондинка]

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

[блондинка]

Я тоже считаю, что оптимальным было бы разделить ответственность за Заказы между пользователями. Буду стараться убедить в этом руководство. Главная трудность состоит в том, что в 1С это ТАК РАБОТАЛО.

[mazzy]

Цитата:

Сообщение от блондинка

Главная трудность состоит в том, что в 1С это ТАК РАБОТАЛО.

Нет. В 1С это работало ПО ДРУГОМУ.
В 1С пока пользователь не нажмет на кнопку Записать или Провести данных в базе просто нет.
После создания, несколько пользователей и в 1С вполне могут работать с одним документом - изменения запишет только первый. Второй получит сообщение о том, что заказ изменен и все его изменения будут потеряны.

Проэмулируйте эту кнопку - Записать.
При создании заказ блокируйте, при нажатии на кнопку разблокируйте.
Редактируйте заказ только в том случае если пользователь нажал на кнопку Открыть.
Обратите внимание на совет glibs Как блокировать одновременный доступ к Заказу?
Его совет содержит только суть.

На самом деле в Аксапте есть аналог безо всякого программирования.
Заказ должен создаваться в статусе "Журнал".
Журнал - черновик, который не влияет на итоги.
Когда пользователь полностью создаст заказ - он переводит его в состояние Заказ.
В этот момент происходит резервирование всех строк и создаются складские проводки.

Если вы хотите избавиться от коллизий при редактировании разными пользователями одного и того же заказа - вам нужно проэмулировать кнопку Открыть и разрешать редактирование только открытых заказов.

Только зачем повторять функционал другой программы - не очень понимаю.

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

[mazzy]

Цитата:

Сообщение от блондинка

Согласна. Но у нас очень требовательный пользователь. Он не хочет помнить сам о необходимости ставить, и главное, снимать эту галку.

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

[Lokis]

Можно попробовать реализовать с.о.
1. Создаете табличку (salesTableLock), в которой поля: SalesId, UnitId (1, 2:Заказы\Закупки), createdBy, createdDate, createdTime
2. На примере Заказов: Перегружаете в форме salesTable метод active, в котором:
2.1 Делаете проверку на наличие в SalesTableLock записи с salesId == SalesId из текущего курсора, и, если находите, то на форме д.б. метод editsales (я в 2.5 работаю). Вызываете его с параметром false. Посмотрите методы datasource формы AlowEdit, AllowCreate, AllowDelete... Можете выдавать сообщение пользователю.
2.2 Удаляете все записи из табличке salesTableLock, у которых createdBy == curUserId() и, сот-но, модуль == 1:заказы
2.2 Вставляете запись в salesTableLock, salesId из текущего курсора, UnitId = 1

Это навскидку, изврат конечно. Наверняка есть подводные камни. Например пользователь может перезагрузить комп, и тогда запись зависнет в таблице. Тогда нужно определять пакет, который будет чистить "подвисшие" записи, а идентифицировать их, ну, скажем по времени захвата. Сколько времени Заказ может быть захвачен? Решать вам.
Да, и лочить запись нужно так же в момент создания.
3. В форме SalesCreateOrder в конце метода initvalue. В противном случае, пока пользователь создает новую запись, другой вошедший в форму "Заказы" может ее заблокировать.

[glibs]

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

Это теоретически. Реально я бы ничего из вышеперечисленного делать не рекомендовал (слишком много кодирования из-за ерунды какой-то).

[ziva]

Цитата:

Сообщение от glibs

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

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

блондинка,
Журналы то это одно - там отдельная форма строк, открытие которой можно заблокировать. А вот форма заказов совсем другая. Представьте себе что имеем 10 заказов. Один пользователь на 1м. Второй на 10м. И начинают они "бежать" (с помощью стрелочек на клавиатуре) по гриду - первый - вниз, второй - вверх.
Что происходит в районе примерно 5го по счету заказа если они одновременно на нем "остановились"?
Вы вообще думали о той бизнес-логике которая должна при этом отрабатывать? Для каждого пользователя:
1. Перечитать запись из БД.
2. Проверить флаг
а. Блокирован - блокируем заказ от изменения текущим пользователем (строки + все кнопки)
б. Не блокирован - обновляем в транзакции флаг в заказе. Перечитываем запись в датасорс. Можем осуществлять работу с заказом.
3. Ушли с этого заказа - обновить запись в БД., разбликировать строки и кнопки ... и далее на п.1
Короче, бред....

А кроме обычной формы заказов есть форма "Строки открытых заказов" (или как она там называется... Аксапты под рукой нет). Там такую же хрень реализовывать?