ОСТАТКИ товара

← →
GanibalLector © (2004-11-28 13:19) [0]

Вот какое дело...Мне необходимо выводить остатки товара по дате.Как то в "Базы" я увидел такой подход:
-id -id_tovar -FK по ID товара -id_part -FK по ID партии -data (дата) -type_oper (-1 расходная, 0 - нейтральная(перемещение), 1 приходная) -kol (кол-во товара)
Попробовал...все как бы работает при такой структуре,но я решил ее слегка протестить и наполнил несколькоми тысячами значений.
И что же я вижу...запрос выполняется более минуты,что не есть хорошо.Так вот,собственно,что я хотел спросить:может есть какие-нибудь другие подходы к остаткам товара??? Т.е. другие структуры таблиц(возможно алгоритмы)

← →
sniknik © (2004-11-28 13:41) [1]

в 1С (всеми любимом ;о)) есть точка отсчета на которую остатки (и не только) пересчитываются.
т.е. получается типа, на 1 число каждого месяца уже расчитаные остатки в отдельной таблице, все в середине месяца пересчитываются. (проще чем за весь год/два/три суммировать, всегда только с начала месяца, зато старое править без перепроводок (пересчета) нельзя)

← →
GanibalLector © (2004-11-28 14:39) [2]

2 sniknik
Я согласен.Я тоже собираюсь раз в месяц все пересчитывать и оставлять для каждого товара одну запись.НО!!!Как быть с текущим месяцем???Пару тысяч действий за месяц будет обязательно и,соответственно,получаю тормоз при выполнении запроса.

← →
jack128 © (2004-11-28 14:57) [3]

GanibalLector © (28.11.04 14:39) [2]
а можно этот запросик прривести, который на паре тысяч записей тормозит?

← →
GanibalLector © (2004-11-28 15:51) [4]

Что-то типа этого :
CREATE PROCEDURE OSTATOK( DD DATE) RETURNS ( ID_TOVAR1 INTEGER, KOL1 BIGINT) AS DECLARE VARIABLE ID INTEGER; DECLARE VARIABLE SS1 BIGINT; DECLARE VARIABLE SS2 BIGINT; DECLARE VARIABLE SS3 BIGINT; begin for select distinct id_tovar from detal into :id do begin select sum(kol) from detal where type_opr>=1 and da<=:dd and id_tovar=:ID into :ss1; select sum(kol) from detal where type_opr=0 and da<=:dd and id_tovar=:ID into :ss2; select sum(kol) from detal where type_opr<=-1 and da<=:dd and id_tovar=:ID into :ss3; if (ss1 is null) then ss1=0; if (ss2 is null) then ss2=0; if (ss3 is null) then ss3=0; id_tovar1=:id ; kol1=:ss1-:ss2-ss3; suspend ; end end
select * from ostatok(:tipa_data)

← →
Vemer © (2004-11-28 16:34) [5]

1) Select distinct id_tovar - ID по идее уникален?
2) зачем обрабатывать type_opr=0 - ведь это по идее нейтрал (или неправильный нейтрал какой-то:)?).
3) kol1=:ss1-:ss2-ss3 Зачем нейтрал отнимать? Если это перемещение между складами, то тогда это не нейтрал.. а (+1/-1) имхо..

А если так (без учета нейтрала):
For Select id_tovar, Sum(Kol * Type_opr) From Detal ......?

← →
GanibalLector © (2004-11-28 16:55) [6]

2 Vemer
нет,Вы не поняли.
Примерно...это выглядит так :
id\id_tovar\id_part\type_opr\kol\date
1 1 1 1 10 28.11.2004
2 1 2 1 5 28.11.2004
3 1 1 0 2 28.11.2004
4 2 3 1 5 28.11.2004
5 1 1 0 2 27.11.2004

2)Предположим,что админ.захотел изменить кол-во товара некоторой партии...так вот,после изменения в kol попадет разница между тем кол-вом,которое было и тем которое он ввел.
3 и 4)не нужно!ибо 2!

← →
GanibalLector © (2004-11-28 17:06) [7]

2 Vemer
+1 это приход
-1 это реализация,списание,исчезновение и пр.
0 это изменения оператором

← →
Vemer © (2004-11-28 17:40) [8]

Неправильная таблица.. )).

Table OPER_TYPE (справочник) OPT_ID OPT_NAME OPT_TYPE 1 Поставка +1 2 Продажа -1 3 Перемещение 0 4 Оператор "+" +1 5 Оператор "-" -1 6 Оператор "0" 0 Table OPER_TOVAR (журнал) OT_ID OT_State (FK по OPT_ID из OPER_TYPE) Tov_ID Kolvo

Остаток товара:
Select SUM(Kolvo * OPT_TYPE) From Oper_Type, OPER_Tovar Where Tov_ID = :My_ID And OT_State = OPT_ID;

Вся история движения товара:
Select OT_ID, OPT_NAME, Kolvo [* OPT_TYPE] From Oper_Type, OPER_Tovar Where Tov_ID = :My_ID And OT_State = OPT_ID;

← →
GanibalLector © (2004-11-29 02:54) [9]

2 Vemer © (28.11.04 17:40) [8]
Хорошо,что такое Перемещение,Оператор "+",Оператор "-", Оператор "0" ???
Более того ,в отчетах вообще не будет фигурировать Ваше (Оператор "0" и Перемещение) ибо на нуль будет умножено!

← →
sniknik © (2004-11-29 08:29) [10]

> Более того ,в отчетах вообще не будет фигурировать Ваше (Оператор "0" и Перемещение) ибо на нуль будет умножено!
ну, судя по всему, имеется в виду перемещение внутри подразделения (между отделами на одном складе), т.е. то которое не изменяет общие остатки товара. т.что нуль правильно. там же сумма, а то что в скобках это как в хелпах необязательная часть в конструкции запроса, не нужно по логике не ставь.

Оператор "+" - логично это приход, не поставка но меняющая остаток операция (возврат от покупателя к примеру)
Оператор "-" - соответственно наоборот.

и еще логично, что это пример, не обязательно на 100% все копировать, смысл же ясен. (с моей точки зрения нехватает еще кучи операций. по которым тоже желательно деление... продажа по налу/безналу, смешанная оплата, со скидкой, по дисконту, списание, производство, пересорт, наборы (то что меняет количество так последние три убирают один вид товара добавляют другой), но это мне нехватает а они видать обходятся (или нет таких операций или все через Оператор "+/-" делают...), весде же по разному)

← →
Vemer © (2004-11-29 14:17) [11]

Для отчетов на OPT_TYpe умножать не надо.. специально в скобки взял (Может знак кому нужен))).. + поздно ночью писал..
Вобще пример очень общий, скорее схема..
Оператор "+",Оператор "-", Оператор "0" - это изменения, вбитые оператором, то что в твоем примере было как "нейтральная операция" )).

>Vemer © (28.11.04 17:40) [8]

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

В остальном идея объединения всех видов документов в "один стакан", конечно, весьма продуктивна, особенно с т.зр. единой технологии разработки форм, отчетов и т.д.

> MS_Guns
Уважаемый MS_Guns, вы опять пляшете от Документа, то есть с точки зрения бухгалтерии. А это схема для оперативного учета и анализа. В котором я пляшу от Операции. а документ генерится по необходимости.

Для FIFO эта схема напрямую не катит, нужна еще таблица партии и другие мелочи. А наличие таблицы типа OPER_TYPE сильно облегчает добавление новых операции и вывод итогов простым SQL. Сейчас у меня в едином журнале (5 таблиц журналов + 5 справочников) хранятся все операции предприятия, в том числе с основными средствами.

← →
Виталий Панасенко (2004-11-30 09:19) [14]

Интересно... А как при подсчете остатков "на лету" обеспечить в сетевом варианте наличие как минимума нулевого остатка.. Т.е. как не перебрать товара больше, чем есть ? Если хранить остаток как число в таблице, то понятно CHECK(VALUE>=0) ... А в этом варианте?.. Не думайте, что подкалываю.. Честно, интересно...

При минусовых операциях проверку производить непосредственно в ХП перед уменьшением чтобы Выбор >= Остаток.

>Vemer © (29.11.04 19:53) [13]

Т.е. все операции с ТМЦ+ОС Вы запихали в единую схему и, как следствие, все обрабатываете одной алгоритмикой ? Если у Вас документ вторичен (я, к примеру, придерживаюсь иного мнения), а первична некая операция, то Бог с ней, с первичностью. Но ведь разные схемы учета и списания разных видов ТМЦ. К примеру, ОС изнашиваются и выбывают, Материалы и БМП уходят в подотчет и списываются, с товарами вообще кухня третья. Как это все у Вас "уживается" в одной схеме ? Действительно интересно.
Кстати, НМА у Вас в тех же хурналах ?

ОСТАТКИ товара Найти похожие ветки