Прочитал большую ветку про остатки товара.
Да простят меня модераторы, надо было сразу сюда, а я вначале в форум Oracle.
Похожий аспект проблемы:
Система учета авиабилетов (БСО – бланки строгой отчетности).
В общий чертах кассиры - получают от кого-то бланки, реализовывают их, передают другому (кассиру, кладовщику).
Операций в общем случае две – расход (расходный ордер), приход (приходный ордер) (в принципе, может быть операция – отказ от приема бланков по причинам несоответствия реально переданных бланков расходному ордеру, но на это пока не стоит обращать внимание).
Каждый бланк характеризуется типом, например, ”555”, серией (“420”), номером (“1234567”). Совокупность этих параметров уникальна.
Ордер описывает: кто передает (получает), кому, дата операции, № ордера и записи следующего содержания - тип, серия и диапазон номеров (передаются пачками без дыр в нумерации) начальный - конечный. Имеем как бы таблицы операций – ордера и пачки бланков в них.
Если кассир просто реализовал бланк (продал билет, испортил бланк) то оформляется расходный ордер на самого себя.
Задач несколько:
1. Знать сколько бланков было у кассира на утро определенного дня
2. Знать сколько бланков у него сейчас
3. Если кассир (или кладовщики) передал другому бланки, то до той поры, пока другой не отметится о их получении они числятся «в пути» (но при этом считаем, что на остатках первого кассира они уже не числятся). Учет бланков в пути.
4. И соответственно знать, сколько бланков было во всем агентстве (филиалах) на определенное число и на настоящий момент.
У меня есть некоторые идеи по общей организации БД, но пока не хочу их навязывать. Если тема вызовет интерес – обменюсь идеями.
С уважением.

Кассир, кладовщик формирует расходный ордер на передаваемые бланки и все это отправляет адресату по почте, курьерской службой (заказными письмами,...). Способы доставки роли не играют. Главное один передал ( с остатков у него они ушли), другой через некоторое время получил их, оформив приходный ордер на себя. Как только оформил ордер, бланки уходят с пути и становятся ему в подотчет (на остатки). В случае физического несоответствия бланков расходному ордеру - есть варианты. Думаю пока на них не надо заострять внимание.

>andsm В системе авиаперевозок нет единого стандарта, очень много разработчиков всяких систем. По-этому приходится изобретать велосипед. Тем более, что это только часть системы и если у тебя есть система билетопечати с хранением распечатываемой информации на сервере, система ввода отчетов кассиров то совсем необязательно приобретать только движение БСО.
Есть у меня желание обменяться идеями, нет ли у Вас подобного?
Вкратце суть нашего предполагаемого подхода:
1. 2 таблицы операций :
Первая - заголовок ордера -
iddoc, Дата,номер,тип (приход,расход),от кого, кому.
Вторая - сами пачки бланков -
idblank,iddoc,тип бланка, серия, начальный номер, конечный.
2. Таблица оперативного учета (по каждому бланку):
id,тип бланка, серия, номер, текущий владелец, статус и ряд служебных полей (дата создания записи, кто создал, дата последней модификации, кто модифицировал)
статус - пусто, значит есть у владельца
- 1 реализован
- 2 в пути (можно наверно завести поле кому отправлен)
На один бланк только одна запись, отражается только последнее состояние.
Если статус 2 - то он будет гореть до тех пор, пока новый владелец не получит бланк и поле текущий владелец станет равным новому, а поле статус станет пустым.
Подобная конструкция позволяет вести оперативный учет и ароеде есть возможность получить остатки на любой день, прогон таблицы операции с начала или с конца. Операций много, перемещения бланков идут постоянно, поэтому думаю о промежуточных итогах - остатках. Заводим таблицу остатки и время от времени сохраняем остатки на какое-либо число с большим гандикапом (например формируем остатки на 1 января только в феврале), думаю хватит или 1 раз в год или 2 раза в год. Гандикап нуден, чтобы больше никогда предыдущие данные не изменять, если ну очень хочется провести проводки сегодняшним числом. Бланки передаются так часто, контроль их наличия постоянен, поэтому, думаю, возможная ошибка выявится в течение месяца.
Народ - оцените пожалуйста.
> tertertertertertert Спасибо, сейчас поищу.

Я немного неправильно написал в разделе
2. Таблица оперативного учета (по каждому бланку):
id,тип бланка, серия, номер, текущий владелец, статус и ряд служебных полей (дата создания записи, кто создал, дата последней модификации, кто модифицировал)
Дата создания записи - это и есть дата постановки на учет (она не меняется)
Дата последней модификации - по смыслу. Если реализовали, значит ничего больше изменяться по этому бланку не будет.

>tertertertertertert
Нашел ветку, инициированную sp.
До логического конца не доведенное обсуждение, о расчете остатков на конкретное число там речи нет. Строится история перемещений бланка от начала до реализации (одному бланку соответствует много записей). Нет состояния "в пути", но можно и добавить. Получается, чтобы получить информацию о наличии бланков на конкретное число надо найти последнюю дату по каждому бланку до указанного числа, голова совсем не варит, не подскажете вариант запроса? Желательно для Oracle.
Кроме того, перемещения идут постоянно, от 1000 до 10000 в день, за год будет миллиона 3 записей. Немного наверно.

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

Тихо сам с собою...
замкнуло, запрос на получение последней даты по каждому бланку
select id,max(data) from t1 group by id where data<'16.01.2004'
Кто работал с подобной организацией данных, не подскажете, как долго будет считаться на 10 млн. записей. Нужен будет индекс по id или по id +data?
Количество повторяющихся id будет очень большим, где-то до 100. Есть неявное условие - желательно, чтобы бланк должен быть реализован за два месяца.

>>sp
>просто там подразумевалось это делать триггером
>BlankID
>DateStart default(getdate())
>DateFinish default('01/01/3000')
>при вставке новой записи - последней "активной" записи >вместо '01/01/3000' - пишется текущая дата.
>а зпрос такой - показать по BlankID где Дата>=DateStart и Дата<DateFinish

Поясните, пожалуйста. Кроме таблицы перемещений бланка завести указанную таблицу, где на каждый бланк одна запись? datestart вводится один раз (при первичном попадании бланка в базу), datefinish - когда бланк снимается с учета (реализован,аннулирован,списан,...)? Я правильно понял?

Если да, то как получить остатки по конкретному кассиру на определенное число. Что-то не получается. Тогда либо в таблице перемещений две даты (начальная и конечная) и при новом перемещении в предыдущей пишем datefinish=getdate()-1 (или getdate()), а в новой datestart=getdate(),datefinish='01/01/3000'.

Создал для пробы таблицу перемещений (с диапазоном дат)
create table blank (iddoc number(38),idblank number(38),num char(14),ind number(4), status char(1),dbegin date,dend date,constraint pk_blank primary key (idblank)
iddoc-Ссылка на расходный/приходный ордер.
Дополнительно
create sequence sq_blank
Планируется работа следующим образом
Бланк ххх поступил кассиру 123
insert into blank values (111,sq_bank.nextval,'xxx',123,' ',sysdate,to_date('01.01.3000', 'dd.mm.yyyy'))])
(dbegin - sysdate или дата которой кассир заходит в систему)
Если бланк реализован - статус '1'
Если бланк передан кассиру 321,
update blank set dend=sysdate для этого бланка
и добавляется запись со статусом '2'
insert into blank values (222,sq_bank.nextval,'xxx',123,'2' ,sysdate,to_date('01.01.3000', 'dd.mm.yyyy'))])
Когда прийдет подтверждение, то во второй записи номер кассира изменится
на 321 и status=' '
Здесь, к сожалению не видно кому отправлен бланк, но информация об этом есть в расходном ордере.
и второе - (расчет остатков на конкретную дату) - насколько оптимален поиск по диапазону дат, может все-же завести одну дату и искать ближайшую дату до искомой?
У кого есть какие мысли?

Хорошо, не буду морочить людям голову, но и остатки хранить тоже не хочу.

>>ModelR Спасибо за ответ.
>>Бланк ('xxx')
??Статус ('xxx', дата1, где=123, на основании =док1, годен=да,..., >>датаокончания=дата2)
>>Статус ('xxx', дата2, где=в пути, на основании =док2, годен=да,..., >>датаокончания=)
>>Документ Док2 перевел бланк из одного состояния в другое.

Заводить в справочнике кассиров квази-кассира "в пути"?
Только необходимо знать, кому именно отправили бланк ххх. Поэтому я предполагаю во второй записи писать где=321 (кому), а в специальном поле статус - признак трансфера, по умолчанию там будет пусто (т.е. бланк числится у агента). а в первой записи поставить прзнак отправлен. Т.е. бланк в этот момент времени ни за кем не числится. Когда кассир 321 примет его статус станет пустым, dbegin=sysdate() т.е. бланк годен и находится у втрого кассира (трансфер завершен). Можно было бы использовать для подобного учета таблицу документов (ордеров), но так мне кажется будет быстрее вычислить и историю любого бланка и остатки по любому кассиру на любую дату. Если зря писал, прошу простить. :)

Люблю, когда по делу вопросы задают :))
Передача проводится в два этапа - в таблицу ордеров заводится расходный ордер, в котром сказано от кого, кому передана пачка бланков. Проверяется наличие данных бланков в таблице бланки (где они поштучно, со статусом пусто,т.е. принадлежеат данному агенту) (точнее их количестов count(*) where status=' ' and kassa=123). Если эти бланки есть, то им всем меняется статус в отправленr и для каждого бланка создается новая запись, где указана касса, которой отправляется (321) и статус - transfer и даты. Когда второй кассе прийдет оповещение о передаче, она просмотрит отпарвдленные ей бланки и если все нормально - примет их, т.е. оформит приходный ордер - в таблице ордеров появится соответствующая запись, а в таблице бланки у первой кассы можно поменять статус на окончательно отправлен, а у второй статус станет=' ', т.е. принадлежащим данной кассе. Трансфер завершен, приянть бланки отправленные не ей она не может. Единственно только по таблице нельзя отследить кто ей отправлял, поэтому в ней есть ссылка на талицу ордеров (документов), следовательно мы видим полную картину перемещений. И передача проходит в два этапа расход-приход с подтверждением. Так пойдет?