[ОТВЕТИТЬ]
Опции темы
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, время: 03:27.

Все в прочитанное - Календарь - RSS - - Карта - Вверх 👫 Яндекс.Метрика
Форум сделан на основе vBulletin®
Copyright ©2000 - 2016, Jelsoft Enterprises Ltd. Перевод: zCarot и OlegON
В случае заимствования информации гипертекстовая индексируемая ссылка на Форум обязательна.