права доступа в СМ : Супермаг Плюс (Супермаг 2000)

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

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

Смотри пересорт, который ты описываешь.
В принципе, можно свести к двум операциям:
- на излишки (Перемещение с ЦС в магазин). Делается также как и основной документ - на складе. В магазине проводится.
- на недостачу. Насколько я помню, для этого надо в имеющемся документе поставить фактически принятое количество и провести документ. Статус при этом понижать не нужно.

зачем же ёжика?
в PL/SQL всё можно обработать как угодно, все данные по документу доступны. в зависимости от комбинации условий проверка сработает (нельзя будет сменить статус) или нет (можно будет сменить статус)
и не городить кучу должностей

или вам ещё не приходилось писать проверки в Супермаге?
могу общий концепт набросать

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

нет, не приходилось. думается мне, общий принцип не помешает, выкладывайте :)

Сколько таких документов? В день, в неделю, в месяц?

ещё момент, в разрезе предложенной тобой схемы. как быть с возвратами товара с МГ на ЦС? с одной стороны, МГ не может повысить статус до розового, с другой, у ЦС нет права создавать НП с МГ на ЦС. как быть в этом случае?

количество внутрискладских НП, как минимум, равно количеству НП, отписанных в МГ. внутренние склады, при отписке товара, сначала отписывают его на ЦС, а уже потом из ЦС на магазин.

в самых общих чертах:
1. создаём проверку (таблица ssinspectfunc) (нумеровать сви проверки лучше с 1000)
2. создаём правила срабатывания проверки (таблица ssinspectdoc)
например, для НП при смене статуса из черновика в красный будет вызываться процедура PRC1
а при смене статуса из красного в зелёный будет вызываться проседура PRC2
и т.д. для каждого сочетания статусов (можно не делать кучу процедур, а всё описать в одной,
но строк правил всё равно будет несколько)
3. создаём процедуру-обработчик, в которой должны быть:
3.1. параметры (интересуют только первые 4)
INDOCTYPE IN SMDOCUMENTS.DOCTYPE%TYPE
, INDOCID IN SMDOCUMENTS.ID%TYPE
, INOLDSTATE IN SMDOCUMENTS.DOCSTATE%TYPE := NULL
, INNEWSTATE IN SMDOCUMENTS.DOCSTATE%TYPE := NULL
, INDUMMY IN CORE.SMBOOL := NULL
3.2 первая строка
INSPECT.ONSTARTTRANS
3.3 последняя строка
INSPECT.SETFUNCNAME( ИД проверки )
3.4 для вывода сообщений (это же является срабатыванием проверки) используем
insert INTO TTINSPECTRESBUFFER ( INSPECTID, ERRID, INSPECTNAME, ERRTEXT ) values ...
например при срабатывании на магазине правила с PRC1:
если у НП (locationfrom=ИДмаг and locationto=ИДцс), то null, иначе insert
это означает, что оператор магазина может перевести из черновика в красную только НП из магазина на ЦС
в остальных случаях при переводе НП из черновика в красную будет выдана ошибка
4. привязваем режимы срабатывания проверки к должностям (таблица sminspectcfg)
например, проверка для оператора магазина будет действовать в режиме запрета,
а для старшего оператора магазина в режиме предупреждения

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