Главная страница
Top.Mail.Ru    Яндекс.Метрика
Текущий архив: 2004.12.26;
Скачать: CL | DM;

Вниз

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

 
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"  - это изменения, вбитые оператором, то что в твоем примере было как "нейтральная операция" )).


 
msguns ©   (2004-11-29 14:41) [12]

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

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

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


 
Vemer ©   (2004-11-29 19:53) [13]

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

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


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

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


 
Vemer ©   (2004-11-30 09:50) [15]

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


 
msguns ©   (2004-11-30 10:31) [16]

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

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



Страницы: 1 вся ветка

Текущий архив: 2004.12.26;
Скачать: CL | DM;

Наверх




Память: 0.51 MB
Время: 0.04 c
14-1101833468
OneFragLeft
2004-11-30 19:51
2004.12.26
Счастливые трусов не надевают...


14-1102245968
OneFragLeft
2004-12-05 14:26
2004.12.26
Microsoft Hotfixы


3-1101298230
keymaster
2004-11-24 15:10
2004.12.26
Client-Servet виснет


14-1102433005
Сергей Г
2004-12-07 18:23
2004.12.26
Куда мы катимся


4-1097473620
Rentgen
2004-10-11 09:47
2004.12.26
Включить компьютер.