26.11.2010 07:29
LexaP
 
есть же механизм пользовательских проверок - процедур БД, которые срабатывают при смене статуса документов
там любые извращения (запреты) можно запрограммировать и назначить срабатывание этих проверок только для определённых должностей, типов документов и направлений смены статуса (красный в зелень, зелень в красный и т.д.)
вобщем очень гибкий инструмент
26.11.2010 07:39
Vovantus
 
Цитата:
LexaP вобщем очень гибкий инструмент
ну так про него и речь. вот и пытаюсь ёжика слепить, да так, чтобы и работать было удобно и права разграничены были.
26.11.2010 07:57
Mtirt
 
Цитата:
Vovantus остался, конечно. а как быть, если оператор магазина отписывает товар на ЦС? бывает, отписали одно, отправили другое. бывает, с количеством ошибаются, иногда брак возвращают с МГ на ЦС. у оператора магазина должно быть право создавать НП с МГ на ЦС, и проводить их до розового статуса.
Смотри пересорт, который ты описываешь.
В принципе, можно свести к двум операциям:
- на излишки (Перемещение с ЦС в магазин). Делается также как и основной документ - на складе. В магазине проводится.
- на недостачу. Насколько я помню, для этого надо в имеющемся документе поставить фактически принятое количество и провести документ. Статус при этом понижать не нужно.
26.11.2010 08:02
LexaP
 
Цитата:
Vovantus ну так про него и речь. вот и пытаюсь ёжика слепить, да так, чтобы и работать было удобно и права разграничены были.
зачем же ёжика?
в PL/SQL всё можно обработать как угодно, все данные по документу доступны. в зависимости от комбинации условий проверка сработает (нельзя будет сменить статус) или нет (можно будет сменить статус)
и не городить кучу должностей

или вам ещё не приходилось писать проверки в Супермаге?
могу общий концепт набросать
26.11.2010 08:26
Vovantus
 
Цитата:
Mtirt Смотри пересорт, который ты описываешь.
В принципе, можно свести к двум операциям:
- на излишки (Перемещение с ЦС в магазин). Делается также как и основной документ - на складе. В магазине проводится.
- на недостачу. Насколько я помню, для этого надо в имеющемся документе поставить фактически принятое количество и провести документ. Статус при этом понижать не нужно.
это всё понятно, но как эту схему перенести на НП, которые ходят внутри центрального склада и дополнительных складов? там не нужны никакие ограничения, т.к. кладовщики сами у себя тырить ничего не будут. эх, без дополнительной роли, видимо, не обойтись.
26.11.2010 08:27
Vovantus
 
Цитата:
LexaP или вам ещё не приходилось писать проверки в Супермаге?
могу общий концепт набросать
нет, не приходилось. думается мне, общий принцип не помешает, выкладывайте :)
26.11.2010 08:41
Mtirt
 
Цитата:
Vovantus это всё понятно, но как эту схему перенести на НП, которые ходят внутри центрального склада и дополнительных складов? там не нужны никакие ограничения, т.к. кладовщики сами у себя тырить ничего не будут. эх, без дополнительной роли, видимо, не обойтись.
Сколько таких документов? В день, в неделю, в месяц?
26.11.2010 08:43
Vovantus
 
Цитата:
Mtirt В принципе, можно свести к двум операциям:
ещё момент, в разрезе предложенной тобой схемы. как быть с возвратами товара с МГ на ЦС? с одной стороны, МГ не может повысить статус до розового, с другой, у ЦС нет права создавать НП с МГ на ЦС. как быть в этом случае?
26.11.2010 08:46
Vovantus
 
Цитата:
Mtirt Сколько таких документов? В день, в неделю, в месяц?
количество внутрискладских НП, как минимум, равно количеству НП, отписанных в МГ. внутренние склады, при отписке товара, сначала отписывают его на ЦС, а уже потом из ЦС на магазин.
26.11.2010 09:02
LexaP
 
Цитата:
Vovantus нет, не приходилось. думается мне, общий принцип не помешает, выкладывайте :)
в самых общих чертах:
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)
например, проверка для оператора магазина будет действовать в режиме запрета,
а для старшего оператора магазина в режиме предупреждения

описания таблиц в документации есть
и на форуме мне где то попадалась расшифровка значений полей этих таблиц
Часовой пояс GMT +3, время: 17:16.

Форум на базе vBulletin®
Copyright © Jelsoft Enterprises Ltd.
В случае заимствования информации гипертекстовая индексируемая ссылка на Форум обязательна.