14.08.2007 11:37
OlegON
 
Надеюсь, разработчики сообщат мне, если добавят этот триггер в штатную схему...
Цитата:
CREATE OR REPLACE TRIGGER supermag.smdocuments_ok_orwi
BEFORE INSERT OR UPDATE
ON supermag.smdocuments
FOR EACH ROW
WHEN (NEW.doctype = 'WI' AND NEW.docstate > 1)
DECLARE
lidx NUMBER (20) := 0;
BEGIN
SELECT MAX (quantity_wi - quantity_or) idx
INTO lidx
FROM (SELECT article article_or, SUM (quantity) quantity_or
FROM smspec
WHERE (doctype, docid) IN (
SELECT basedoctype, baseid
FROM smcommonbases
WHERE basedoctype = 'OR'
AND doctype = 'WI'
AND ID = :NEW.ID)
GROUP BY article) zk,
(SELECT article article_wi, SUM (quantity) quantity_wi
FROM smspec
WHERE (doctype, docid) IN (
SELECT doctype, ID
FROM smcommonbases
WHERE (basedoctype, baseid) IN (
SELECT basedoctype, baseid
FROM smcommonbases
WHERE basedoctype = 'OR'
AND doctype = 'WI'
AND ID = :NEW.ID))
GROUP BY article) pr
WHERE article_or = article_wi;

IF lidx > 0
THEN
raise_application_error (-20000,
'Кол-во в накладных больше кол-ва в заказе'
);
END IF;
END smdocuments_ok_orwi;
/
14.08.2007 11:44
Mtirt
 
Спасибо. Я тут кстати еще глюк отловила... При ручной рассылке контракта в "подходящие филиалы" он уходит только в то место хранения, от имени которого создан. А в места поставки не уходит.

И еще, проверка цен по контракту в приходных накладных работает точно также, как и заполнение контрактными ценами. Цена берется строго из контракта-основания заказа. При нескольких контрактах - из первого, а не последнего.
14.08.2007 13:20
OlegON
 
Да, поясню, что триггер делает-то :) Если есть заказ, скажем, на 100 штук и два прихода на его основании по 80 шт., то Супермаг на это забивает, т.е. не считает суммарное количество по приходу, несмотря на включенную проверку. Мне это мешало. Триггер лечит.
20.07.2009 14:57
OlegON
 
Доработка, в сообщении об ошибке показывается артикул с максимальным превышением (заказали тут):
Код:
CREATE OR REPLACE TRIGGER supermag.smdocuments_ok_orwi
   BEFORE INSERT OR UPDATE
   ON supermag.smdocuments
   FOR EACH ROW
   WHEN (NEW.doctype = 'WI' AND NEW.docstate > 1 AND NEW.opcode=0)
DECLARE
   lidx   NUMBER (20) := 0;
   art	  VARCHAR(200) :=' ';
BEGIN
   SELECT MAX (quantity_wi - quantity_or) idx
     INTO lidx
     FROM (SELECT   article article_or, SUM (quantity) quantity_or
               FROM smspec
              WHERE (doctype, docid) IN (
                       SELECT basedoctype, baseid
                         FROM smcommonbases
                        WHERE basedoctype = 'OR'
                          AND doctype = 'WI'
                          AND ID = :NEW.ID)
           GROUP BY article) zk,
          (SELECT   article article_wi, SUM (quantity) quantity_wi
               FROM smspec
              WHERE (doctype, docid) IN (
                       SELECT doctype, ID
                         FROM smcommonbases
                        WHERE (basedoctype, baseid) IN (
                                 SELECT basedoctype, baseid
                                   FROM smcommonbases
                                  WHERE basedoctype = 'OR'
                                    AND doctype = 'WI'
                                    AND ID = :NEW.ID))
           GROUP BY article) pr
    WHERE article_or = article_wi;

   IF lidx > 0
   THEN
    select (' По артикулу '||article_or||' превышение на '||idx) 
    into art
    from (
    SELECT article_or,(quantity_wi - quantity_or) idx
     FROM (SELECT   article article_or, SUM (quantity) quantity_or
               FROM smspec
              WHERE (doctype, docid) IN (
                       SELECT basedoctype, baseid
                         FROM smcommonbases
                        WHERE basedoctype = 'OR'
                          AND doctype = 'WI'
                          AND ID = :NEW.ID)
           GROUP BY article) zk,
          (SELECT   article article_wi, SUM (quantity) quantity_wi
               FROM smspec
              WHERE (doctype, docid) IN (
                       SELECT doctype, ID
                         FROM smcommonbases
                        WHERE (basedoctype, baseid) IN (
                                 SELECT basedoctype, baseid
                                   FROM smcommonbases
                                  WHERE basedoctype = 'OR'
                                    AND doctype = 'WI'
                                    AND ID = :NEW.ID))
           GROUP BY article) pr
    WHERE article_or = article_wi order by 2 desc) where rownum<2;

      raise_application_error (-20000,
                               'Кол-во в накладных больше кол-ва в заказе.'||art||'    '
                              );
   END IF;
   
END smdocuments_ok_orwi;
/
21.07.2009 16:06
ReDHawK
 
Цитата:
OlegON Да, поясню, что триггер делает-то :) Если есть заказ, скажем, на 100 штук и два прихода на его основании по 80 шт., то Супермаг на это забивает, т.е. не считает суммарное количество по приходу, несмотря на включенную проверку. Мне это мешало. Триггер лечит.
В принципе если делается приход по заказу и приход полностью проведен, то в 99% случаев заказ становится выполненым (из-за включения сообветсвующей настройки). Зачем делать еще приход на старый заказ, если можно сделать новый с учетом новых остатков?
21.07.2009 16:11
OlegON
 
А никто и не говорил, что это обязательно на старый заказ. И если тебе по одному заказу привезут вместо 100 кг. анасов, 100 кг. картошки, я думаю, ты огорчишься, будучи ответственным за это дело. В общем, спорить не хочу, схемы однозначно есть, где такие ограничения нужны.
21.07.2009 16:12
Mtirt
 
Цитата:
ReDHawK В принципе если делается приход по заказу и приход полностью проведен, то в 99% случаев заказ становится выполненым (из-за включения сообветсвующей настройки). Зачем делать еще приход на старый заказ, если можно сделать новый с учетом новых остатков?
Потому что это не в 99% случаев, а в 1%.
Жизнь далека от идеала.
Логистику поставщика нам не понять.
Поэтому, когда он одну поставку везет десятком разных накладных нам надо корректно привязываться к заказу.
21.07.2009 16:24
7zEro
 
Цитата:
Mtirt Спасибо. Я тут кстати еще глюк отловила... При ручной рассылке контракта в "подходящие филиалы" он уходит только в то место хранения, от имени которого создан. А в места поставки не уходит.

И еще, проверка цен по контракту в приходных накладных работает точно также, как и заполнение контрактными ценами. Цена берется строго из контракта-основания заказа. При нескольких контрактах - из первого, а не последнего.
это про какую версию идет речь... 27ая?
21.07.2009 16:27
Mtirt
 
Ты на год посмотри.
Это где-то 1.024 -1.024.6
21.07.2009 16:29
7zEro
 
Цитата:
Mtirt Цена берется строго из контракта-основания заказа. При нескольких контрактах - из первого, а не последнего.
сам с такой же проблемой постоянно сталкиваюсь версия правда 26ая =) пришлось с поставщиками договариваться что бы накладные делили а не объединяли в общую..
Часовой пояс GMT +3, время: 14:03.

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