Сложное условие WHERE : Oracle

AlexeyF · █ 13.02.2012 17:13

Цитата:

Mtirt ➤ Такое условие тебя устроит?

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

Добавлено через 2 минуты 56 секунд

Цитата:

vdm ➤ Присоединяюсь.
Выглядит очень странно, примерно как "отобрать группы с длиной(!) до 9-10-11 символов"
У вас tree так хитро устроено, что его длина что-то означает?

Код стал разбирать то же не понял почему так сложно. Завтра положу скрипт, прошу на него взглянуть - может понятно будет почему так сделал программист.

AlexeyF · █ 14.02.2012 10:30

Предлагаю посмотреть скрипт:
temp-4.sql
В нём готовый код, который к любому супермагу должен подойти. (наверное структура настолько сильно не меняется от версии, что бы этот код не смог заработать)
Там требуется только указать кассовый документ, продажи которого выводятся в seleсt.
Описание работы и вопросы в теле скрипта в комментариях.

Люди добрые, не хватает знаний у меня что бы разрешить данную проблему. Присоветуйте что поделать?
Либо помогите условие переделать. Нужно обработать попадание артикула в одну из 7-ми групп. Либо была правильная мысль - а можно его переделать на попадание/непопадание в один Ассортимент ?

Mtirt · █ 14.02.2012 10:34

Вопрос у меня. В указанных в скрипте семи группах вложенные подгруппы есть? Или это последний уровень классификатора?

AlexeyF · █ 14.02.2012 10:35

последний, нет подгрупп

Mtirt · █ 14.02.2012 10:40

Давай для начала упростим запрос.

Код:

 select
f.saleid , f.article, f.saletype, f.saledate, f.SALENOVAT, tax.TAXRATE, tax.TAXSUM
from
SUPERMAG.FFMapRep f
SUPERMAG.SMCARD sm
where 
    f.saleid='Бр20120101@39' 
    and sm.article=f.article
    and f.RECTYPE=1
    and sm.idclass in ('9092', '6789', '7891', '9400', '9402', '10093', '10095')

Сколько артикулов? Ну и с not in соответственно...

AlexeyF · █ 14.02.2012 11:23

in -- 2-ва "лишних" артикула
not in -- 1132 артикула, т.е. первоначальный скрипт без условий (1134) минус 2-ва "лишних" артикула

Я такие варианты сразу проверил - это само напрашивается. Результат получается совсем неожиданный. Я поэтому и понял, что я не понимаю ещё нюансов запроса к нескольким таблицам.

Mtirt · █ 14.02.2012 11:29

Такой вариант:

Цитата:

select
f.article, sum(f.SALENOVAT)
from
SUPERMAG.FFMapRep f
SUPERMAG.SMCARD sm
where
f.saleid='Бр20120101@39'
and sm.article=f.article
and f.RECTYPE=1
and sm.idclass in ('9092', '6789', '7891', '9400', '9402', '10093', '10095')
group by f.article

AlexeyF · █ 14.02.2012 11:35

Так же даёт сумму, по этим двум артикулам.

можно пока sum и group by f.article не делать, пока просто на том скелете с которого начали, если будет нормально показывать позиции проданного товара, я уже потом само суммирование с group верну.

Mtirt · █ 14.02.2012 11:44

А почему не должен давать по этим двум артикулам?
Они есть в документе, насколько я понимаю. И принадлежат нужным группам. Нет?

AlexeyF · █ 14.02.2012 13:13

Я не досмотрел один момент нехороший.
Артикулы производства должны находиться не в самих указанных 7-ми узловых группах, а в подгруппах. Именно поэтому используется фильтрация с отрезанием дерева артикулов SUBSTR(t.TREE,0, 10).

И вот тут была ошибка. По нашим стандартам карточки не могут находиться в узлах дерева артикулов, только в конечных папках. В процессе переноса карточек производства операторы "накосячили" и часть карточек оставили в узловых группах. Эти карточки и попадали в оба условия и эти карточки делали ошибку.

В процессе общения с Mtirt я наконец заметил эту ошибку, карточки перенесены куда должны были быть перенесены ранее, данные выгружаются корректные - уррааааа.....