[ОТВЕТИТЬ]
14.09.2006 14:44
whitewizard
 
реально ли сделать так, чтобы конкретный пользователь (или группа пользователей) имела доступ только к своему МХ (создание и просмотр документов, цены, остатки итп)?
14.09.2006 14:51
Propil
 
В административном модуле в правах доступа для должности есть кнопка Склады/магазины
14.09.2006 14:52
whitewizard
 
и после этого даж в карточке товара человек не увидит не принадлежащие его МХ цены и остатки?
14.09.2006 15:01
Propil
 
Ну, вообще там речь идет о запрете редактирования документов..
14.09.2006 15:16
Mtirt
 
А у тебя структура какая? У меня магазины только свои цены и остатки и так видят. Информации из других магазинов у них просто нет.
Только офис видит все. Или ты хочешь и в офисе разделить? Тогда зачем?
14.09.2006 15:20
akonev
 
Цитата:
Propil Ну, вообще там речь идет о запрете редактирования документов..
увидит. если информация есть в базе - не разделишь.
надо настраивать обмен так, чтобы лишняя инфа в базу не попадала.
14.09.2006 15:20
whitewizard
 
суть в том, что есть база на которой второй магазин работает удаленно через DSL. вот и вопрос про разделение доступа
14.09.2006 15:22
akonev
 
Цитата:
whitewizard суть в том, что есть база на которой второй магазин работает удаленно через DSL. вот и вопрос про разделение доступа
а есть серьезные требования безопасности, по которым они не должны знать остатки друг-друга?
если нет - достаточно будет, что документы друг-другу делать не могут
14.09.2006 15:24
whitewizard
 
с документами то все понятно, а вот про все остальное бы
14.09.2006 15:37
Mtirt
 
А зачем? Чем мешает? Можно объяснить?
Это мой принцип: перед тем, как требовать, чтобы сделали, сначала понять, зачем это надо?
15.09.2006 00:42
whitewizard
 
в магазие не должны видеть остатки другого магазина
вот и все
15.09.2006 07:10
Mtirt
 
А чем мешают то остатки другого магазина?
15.09.2006 07:14
akonev
 
Цитата:
whitewizard в магазие не должны видеть остатки другого магазина
вот и все
Ключевое слово было: "ЗАЧЕМ". Ответ "потому что" - не засчитывается.
При работе на одной базе, разделить остатки можно только создав отдельные карточки для каждого магазина.
И это даже не есть недостаток программы. Просто для разделения данных по МХ предполагается разделять базы.
Понятно, что это будет стоить дополнительной лицензии, но разве кто-то обещал какой-то нестандартный функционал даром?
Лично я не решусь обвинять С+ в желании зарабатывать.

Надо найти какой-то способ донести это до осознания руководства (или кто там у вас требует разделения остатков).
И пусть уже они сами думают: стоит ли эта "секретность" тех денег за лицензию или нет.
15.09.2006 07:22
whitewizard
 
суть в том, что если бы там была сеть, то это одно.
но там маленькие магазин и покупка ЦО для него достаточно дорого.
вот и возник вопрос можно ли сделать пару магазинов на одной лицензии
15.09.2006 07:32
Mtirt
 
Можно. Но остатки то тут при чем?
15.09.2006 07:45
akonev
 
Цитата:
whitewizard суть в том, что если бы там была сеть, то это одно.
но там маленькие магазин и покупка ЦО для него достаточно дорого.
вот и возник вопрос можно ли сделать пару магазинов на одной лицензии
и можно и делают.
но остатки и цены друг друга они будут видеть. без вариантов.
15.09.2006 12:20
whitewizard
 
хорошо. всем спасибо.
26.11.2010 06:54
Vovantus
 
поднимаю старую тему. много воды утекло с момента последнего поста. в версии 1.027.5.4 функционал программы позволяет разграничивать доступ для МХ по трём параметрам:

просмотр МХ
просмотр документов
редактирование документов

вроде как хватает. НО. возникла такая ситуация. кладовщик создаёт и отписывает в магазин накладную на перемещение товара. отписывает в розовом статусе. в магазине, администратор принимает товар по накладной и после этого переводит её в зёленый статус. давно у нас зрел конфликт ЦС с МГ, назрел. обвиняют друг друга в том, что документы правятся, в том числе и задним числом. теперь, решили подключить меня. просят сделать так, чтобы:

проведённая до зелёного статуса накладная на перемещение назад уже не откатывалась. это реализовать просто. но просят, чтобы эти ограничения действовали для накладных, которые участвуют в товородвижении ТОЛЬКО между ЦС и МГ. у нас ещё внутри центрального склада есть несколько складов под каждую группу товара. накладные, участвующие в товародвижении между СК и ЦС никаких ограничений содержать не должны.

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

сижу, ломаю голову, как это всё реализовать на практике. единственный вариант, который приходит в мозг - это создать для каждого участника товародвижение по несколько ролей. и уже внутри них делать разграничение по правам доступа. кто таким заморачивался, есть другие идеи?
26.11.2010 07:11
Mtirt
 
Цитата:
Vovantus поднимаю старую тему. много воды утекло с момента последнего поста. в версии 1.027.5.4 функционал программы позволяет разграничивать доступ для МХ по трём параметрам:

просмотр МХ
просмотр документов
редактирование документов

вроде как хватает. НО. возникла такая ситуация. кладовщик создаёт и отписывает в магазин накладную на перемещение товара. отписывает в розовом статусе. в магазине, администратор принимает товар по накладной и после этого переводит её в зёленый статус. давно у нас зрел конфликт ЦС с МГ, назрел. обвиняют друг друга в том, что документы правятся, в том числе и задним числом. теперь, решили подключить меня. просят сделать так, чтобы:

проведённая до зелёного статуса накладная на перемещение назад уже не откатывалась. это реализовать просто. но просят, чтобы эти ограничения действовали для накладных, которые участвуют в товородвижении ТОЛЬКО между ЦС и МГ. у нас ещё внутри центрального склада есть несколько складов под каждую группу товара. накладные, участвующие в товародвижении между СК и ЦС никаких ограничений содержать не должны.

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

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

Давай по пунктам. Есть 2 должности: оператор склада, оператор магазина. Если у тебя это одна должность - дели.
У оператора магазина на накладную на перемещение права только на проведение в зеленый. И больше никаких прав.
У оператора склада права на создание и проведение в розовый. На проведение в зеленый - нет. И на распроведение из розового в черновик лучше тоже не давать. А еще оператор склада видит только документы и остатки склада.

Всё? Или еще какой-то вопрос остался?
26.11.2010 07:22
Vovantus
 
Цитата:
Mtirt Всё? Или еще какой-то вопрос остался?
остался, конечно. а как быть, если оператор магазина отписывает товар на ЦС? бывает, отписали одно, отправили другое. бывает, с количеством ошибаются, иногда брак возвращают с МГ на ЦС. у оператора магазина должно быть право создавать НП с МГ на ЦС, и проводить их до розового статуса.
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, время: 16:32.

 

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