[ОТВЕТИТЬ]
07.04.2014 18:50
Aligator
 
СМ+ 1030.3
Появилась у одного клиента необходимость ограничить в СМ+ переоценку определенному пользователю (либо должности) только по определенной группе (ассортименту) товаров. Иные товарные группы не могут быть переоценены на магазине.
При этом работа с другими разделами (приход, расход...) должна быть по всему классификатору.
Возможно ли как-то выкрутиться в данном вопросе? Может были у кого-то подобные вопросы, интересно мнение.
07.04.2014 19:21
OlegON
 
Рекомендую дождаться, может, кто-то придумает, как пользоваться штатными средствами, но однозначно можно сделать триггер, чтобы не давал создавать акты с определенным товаром кому-то...
08.04.2014 07:16
Mtirt
 
Для группы можно поставить максимальную и минимальную переоценку.
Только, скорее всего, она будет действовать для всех должностей в базе, например в базе магазина.
08.04.2014 09:31
Aligator
 
Цитата:
Mtirt Для группы можно поставить максимальную и минимальную переоценку.
Только, скорее всего, она будет действовать для всех должностей в базе, например в базе магазина.
Так не пойдет, в БД работают и другие должности, для которых ограничений не должно быть.
08.04.2014 10:16
Mtirt
 
Обычно такое разделение делается не на уровне пользователей, а на уровне базы данных.
Т.е. всему магазину нельзя переоценять товар, а всему офису - можно.
08.04.2014 10:36
Aligator
 
Цитата:
Mtirt Обычно такое разделение делается не на уровне пользователей, а на уровне базы данных.
Т.е. всему магазину нельзя переоценять товар, а всему офису - можно.
Это да, более того можно было бы выкрутиться как-то локальным ценообразованием, но тут задача именно в одной БД сдулать такое разграничение и именно на переоценку.
08.04.2014 10:44
vdm
 
Подобные "нестандартные" запреты можно делать через нечто среднее между триггером и штатным функционалом. В стантартные проверки супермага добавить свою процедуру, для актов переоценки. Удобно тем, что их можно включить/отключить из адм. модуля для конкретных должностей.
08.04.2014 12:28
Aligator
 
Цитата:
vdm Подобные "нестандартные" запреты можно делать через нечто среднее между триггером и штатным функционалом. В стантартные проверки супермага добавить свою процедуру, для актов переоценки. Удобно тем, что их можно включить/отключить из адм. модуля для конкретных должностей.
Ага, осталось походу научиться сие творить в БД, уж стандартные проверки системы уж точно я никогда не ковырял через БД )))
08.04.2014 17:14
vdm
 
Примерный шаблон. На современных СМ+ не проверено.

Код:
CREATE OR REPLACE PROCEDURE SUPERMAG.USR_INSPECT_1001 (
   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 )
IS

  INSPECT_ID    supermag.ttinspectresbuffer.inspectid%TYPE := 1001;

BEGIN
    INSPECT.ONSTARTTRANS;
   
    INSERT INTO supermag.ttinspectresbuffer
                (inspectid, errid, inspectname, errtext)
    SELECT DISTINCT INSPECT_ID, 0, TO_CHAR(INSPECT_ID),
                    SUBSTR('Запрещено наценивание артикула ' || article || ' в группе ' || tree, 1, 255) 
      FROM ( SELECT s.article, sc.tree
               FROM supermag.smspec s, supermag.smcard с, supermag.sacardclass sc
              WHERE s.doctype=indoctype AND s.docid=indocid AND s.article=c.articler AND c.idclass=sc.id
                AND sc.tree in (...)
           );
  
    INSPECT.SETFUNCNAME(INSPECT_ID);
END USR_INSPECT_1001;
/


-- Добавление процедуры в список супермаговских стандартных проверок 
-- для документов 'AC', при смене статуса в "Принят к исполнению", по умолчанию у всех отключено
DECLARE
  INSPECT_ID       supermag.ssinspectfunc.id%TYPE := 1001;
  INSPECT_NAME     supermag.ssinspectfunc.name%TYPE := 'Пользовательская проверка 1001';
  INSPECT_ORANAME  supermag.ssinspectdoc.inspectoraname%TYPE := 'SUPERMAG.USR_INSPECT_1001';
  INSPECT_DEFMODE  supermag.ssinspectfunc.definspectmode%TYPE := 0;
BEGIN

insert into ssinspectfunc(id, name, definspectmode)
  values (INSPECT_ID, INSPECT_NAME, INSPECT_DEFMODE);

insert into ssinspectdoc (doctype, docstate, docstatebefore, inspectid, inspectoraname, dobefore)
  values ('AC', 2, 1, INSPECT_ID, INSPECT_ORANAME, 1);

commit;

END;
/
08.04.2014 17:30
Aligator
 
AND sc.tree in (...)

а здесь в скобках через запятую нужно перечислить все группы, в которых запрещено или разрешено наценивать товары?
08.04.2014 17:45
Aligator
 
чет не хочет применяться...
Форум автоматизации
Миниатюры
Нажмите на изображение для увеличения
Название: Image 940.png
Просмотров: 650
Размер:	25.0 Кб
ID:	3356  
08.04.2014 17:49
vdm
 
В которых запрещено. IN ('1.3.5.', '2.4.8.', '2.4.9.')
Но вообще правильнее хранить список не в коде, а в таблице где нибудь (если в стандартных, то в доп. свойство склада например).

И очепятка c.articler ==> c.article
08.04.2014 17:59
Aligator
 
Цитата:
vdm В которых запрещено. IN ('1.3.5.', '2.4.8.', '2.4.9.')
Но вообще правильнее хранить список не в коде, а в таблице где нибудь (если в стандартных, то в доп. свойство склада например).

И очепятка c.articler ==> c.article
А чего ж может ругаться на [Error] ORA-00904 (20: 89): PL/SQL: ORA-00904: "C"."IDCLASS": недопустимый идентификатор (скрин в сообщении выше)?
08.04.2014 18:27
vdm
 
А тоже очепятка, русский язык в одном символе.
Еще правка, для вложенных групп.
Код:
             SELECT s.article, sc.tree
               FROM supermag.smspec s, supermag.smcard c, supermag.sacardclass sc
              WHERE s.doctype=indoctype AND s.docid=indocid AND s.article=c.article AND c.idclass=sc.id
                AND ((sc.tree like '1.2.%') or (sc.tree like '1.4.1.%'))
08.04.2014 18:28
Aligator
 
Цитата:
vdm А тоже очепятка, русский язык в одном символе.
Еще правка, для вложенных групп.
Код:
             SELECT s.article, sc.tree
               FROM supermag.smspec s, supermag.smcard c, supermag.sacardclass sc
              WHERE s.doctype=indoctype AND s.docid=indocid AND s.article=c.article AND c.idclass=sc.id
                AND (sc.tree like ('1.2.%') or sc.tree like ('1.4.1.%'))
Да, с русским я тоже нашел, и как раз хотел спросить как вложенные группы добавить, спс, сейчас попробую...
08.04.2014 18:34
Aligator
 
Таки да, все получается, а вот как через доп характеристики МХ к примеру такое сотворить, чтобы с интерфейса этим чудом управлять...такое сложно будет дописать?
08.04.2014 19:32
vdm
 
"Не сложно" - это кому как.
У меня времени и желания недостаточно.
Структура БД открыта :)
08.04.2014 21:41
Aligator
 
Цитата:
vdm "Не сложно" - это кому как.
У меня времени и желания недостаточно.
Структура БД открыта :)
Эт я так уточнил.
И на этом огромное спасибо, теперь есть куда копать главное... ))
09.04.2014 11:46
kadr
 
Цитата:
Aligator Таки да, все получается, а вот как через доп характеристики МХ к примеру такое сотворить, чтобы с интерфейса этим чудом управлять...такое сложно будет дописать?
А привязывайся не к группе товара, а к группе ассортимента, тогда добавить/удалить из ассортимента и вот тебе управление из интерфейса
09.04.2014 12:45
Aligator
 
Цитата:
kadr А привязывайся не к группе товара, а к группе ассортимента, тогда добавить/удалить из ассортимента и вот тебе управление из интерфейса
Для старых да, можно их махом закинуть в ассортимент, для новых тоже пойдет-можно создать правило, но не пойдет, товар если переместят из одной группы в другую - в ассортименте ведь он останется...
09.04.2014 14:53
vdm
 
На самом деле для навешивания своего на классификатор товаров я использую "Доп. информация для ценников" - там можно хоть на группу, хоть на артикул нужный параметр выставить. Только фильтра нет (м.б. в новых СМ есть).
09.04.2014 14:55
Mtirt
 
Можно еще Доп.характеристики товара задействовать.
Опции темы


Часовой пояс GMT +3, время: 17:00.

 

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