БД для сети аптек

[rusl_92]

Здравствуйте. Работаю на Delphi XE и FierBrid 2.5.
Мне нужно сделать программу (точнее несколько) для сети аптек. Интересует оптимизация работа с конкретными данными:
-Работа с остатком товаров;
-Работа с ценами продажи.

Я сделал предварительную БД, но мне кажется что она не достаточна быстра.
Может кто сталкивался - прошу ответить

[eval]

с вашей базой вряд ли кто сталкивался

[Stilet]

Я сталкивался с товарооборотом. Что тебя интересует?

[rusl_92]

Сообщение от Stilet

Я сталкивался с товарооборотом. Что тебя интересует?

Про кол-во(остаток) товаров:
Я собираюсь сделать следующее:
В спр.тов. добавит поле "Остаток по коду товара", а после сохранения нового прихода прибавлять пришедшее кол-во к нужным товарам. Если по одному коду товара (в одном приходе) будет несколько карточек(напр. - с разными ценами), то суммировать по коду товара и прибавлять к текущим остаткам в спр. товаров. - Так будет правильно по кол-ву?

Про цену продажи:
По одному коду товара может быть несколько карточек(несколько приходов), все они хранятся в табл.Приходов, а в окне продажи должны выводится все товары(где имеется остаток), цены продажи, остаток(это основное), а цена должна выбираться из самой старой карточки, где есть остаток. Т.е. для 5000 товаров при каждом обновлении запроса - будет выводиться цена из мин. карточки по коду. Я сделал это с помощью Grou by, но всё равно не достаточно быстро. Может хранить цену вместе с тек. остатком в спр. товаров? и каждый раз пересчитывать - так вроде не правильно.. Как мне с тек. ценой продажи работать?

[Stilet]

Так будет правильно по кол-ву?

Здорово придумано. Вот тебе ситуация: Ты принял товар от поставщика - 50 штук остаток на начало периода. Все прекрасно, ты продал до 12-ги числа почти половину, и вдруг Лукашенко ввел эмбарго на украинские конфеты (простите не удержался, но для примера пойдет). Твой оставшийся товар ты больше толкнуть не сможешь, но и вернуть его тоже нельзя - Украина забанит.
Однако законом тебе обязательно нужно от этого товара избавится. Вопрос: Что ты будешь делать? Аннулировать товар убрав его из ассортимента? Балланс периода не сойдется. Сальдо нулевое не получишь, потому что половину уже продал. Причем накладные выписанные на этот товар, если ты его уберешь из базы, окажутся фиктивными, ибо они больше никуда указывать не будут (это от налоговой привет).
Ни в коем разе нельзя смешивать остатки прихода и расхода со справочником ассортимента!!!
Ни в коем!
Делай как полагается - приход\расход отдельными документами, которые потом аналитическими моделями (функциями, методами) консолидируются в сальдовую ведомость.
Т.е. у тебя будет куча записей с полем-флагом приход или расход, а далее запрос типа

select tovar, count(tovar),sum(kolvo) from prihod group by tovar where period between 01.01.2013 and 31.01.2013
select tovar, count(tovar),sum(kolvo) from rashod group by tovar where period between 01.01.2013 and 31.01.2013

Дадут тебе обликово-сальдовую (сорри не помню как на русском звучит это) по товару за январь. Разница между ними - балланс, четкий и не зависящий от ассортимента. В данном случае prihod и rashod - это таблицы карточек (накладных в смысле), tovar - номенклатурный номер товара, kolvo - кол-во отпущенного по накладным. Ну суммировать уже сам додумайся.

а цена должна выбираться из самой старой карточки, где есть остаток.

Это с какого перепуга?
Ты продаешь чупачупс по 5 баксов, вдруг цены на бензу повышают его до 6 баксов.
Ты уже проданный товар тоже будешь в итоговом отчете по новой цене считать?

Как мне с тек. ценой продажи работать?

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

[rusl_92]

Сообщение от Stilet

Это с какого перепуга?

У меня заказчик сам так пожелал сделать. В окне продажи, для одного товара будет:
-Одна строчка с общими данными - общий остаток и цена из мин. карточки, но цену продажи можно изменить;
-А в доп. окне можно будет просмотреть все карточки по товару(где есть остаток) и выбрать нужную карточку(по серии, цене...) и продать.

Тогда мне надо сделать отдельную табл. для остатков, прибавлять после прихода, отнимать после продажи. так?

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

Главное чтобы быстродействие не пострадало от этого.

[Stilet]

заказчик сам так пожелал сделать.

Так ерунда какая-то получается. или ты не так понял. Получается я босс-барбос, сегодня продаю Ренни по одной цене, завтра по другой, послезавтра по третьей... Махинации какие-то.
Ну как быть в случае смены цены до закрытия периода, особенно если не весь товар распродан без ввода нового товара, без приема его на приход по другим накладным? Не понимаю...

Тогда мне надо сделать отдельную табл. для остатков, прибавлять после прихода, отнимать после продажи. так?

Отдельную не обязательно. И приход и расход можно хранить в одной, лишь бы было поле, по которому различается накладная - приход это или расход.
Но в принципе да - можно две разных таблицы.

Для цены может сделать в т.Приходов доп. поле, в котором будет отмечаться что цена из данной карточки является - текущей ценой продажи

Еще раз спрошу, как быть с товаром, который продать по старой цене не успели? Переоценку делать?

[Sciv]

rusl_92, я бы Вам вообще посоветовал взять за шкирку бухгалтера этих самых аптек и потребовать от него полного расклада: как и что должно считаться. Потому что ни один программист не знает всей этой каши досконально. Вам тут просто повезло, что Виталий довольно прилично в этом разбирается. А так - подобные системы пишутся в тесном взаимодействии с теми, кто в них работать должен. Вот когда ясно себе уясните, как это работает, сразу сможете без всяких вопросов решить, как это делать.

[Stilet]

в тесном взаимодействии с теми, кто в них работать должен.

Как???

У меня заказчик сам так пожелал сделать.

Ну как с такими заказчиками общаться???
Вот же камень преткновения. rusl_92 может быть в чем то и прав, ТЗ то четкого нет. Но если это так то это просто глупость какая-то.

[rusl_92]

Сообщение от Sciv

rusl_92, я бы Вам вообще посоветовал взять за шкирку бухгалтера этих самых аптек

Я с ними советуюсь, у меня только вопросы по тому как мне правильно сконструировать БД, чтобы быстро инфо. выводилась. Для аптекарей нет разницы как программа работает-лишь бы работала, а для меня головная боль при проектировании БД.)