Здравствуйте!

Я работаю в аптеке и мучит одна проблема.

В лекарственных средствах (ЛС) есть такое понятие как государственная регистрация, она дается каждому препарату на срок 5 лет. Регистрация позволяет производителю ЛС торговать ним на территории страны. Также каждому ЛС присваивается госуд. регистрационный номер, который является уникальным. По истечении рег. срока, если производитель пожелает и подаст заявку на рег. вовремя, ему продлевают рег. с сохранением прежнего рег. номера. Но если производитель не вовремя подал заявку то тот же медикамент регистрируют по новому и с новым рег. номером. Так вот, аптекам очень важно следить за этой регистрацией, потому что отпуск незарегистрированного препарата наказывается штрафными санкциями.
Нашли одну фирму, которая предоставляет ПО для учета движения товара и много всякой полезной информации для фармацевтов: справочники медикаментов, инструкции, классификация медикаментов, регистрация и д.р. За эту инф. естественно каждый месяц нужно платить :) В этой фирме все унифицировано с поставщиками по ихнему уникальному коду препарата. Все удобно, поставщик сбрасывает электронную приходную накладную, она загоняется в программу, вуаля, осталось только в полуавтоматическом режиме произвести наценку.
Так вот, в чем проблема! В базе есть таблица товар, уникальным полем является это их уникальный код. При продлении регистрации на медикамент в таблице товара создается новая запись с новым уникальным кодом, а старый товар с простеночной регистрацией дальше телепаеться. В итоге в таблице набирается куча никому не нужных дубликатов так сказать, потому что товар по сути тот же, даже рег. номер, только регистрация на него продлилась! Поставщики товара должны тоже завести новую запись, с новым уникальным кодом но они этого НЕ ДЕЛАЮТ или делают но не так ответственно! Они как я понял просто меняют дату и все а уникальный номер нет. В итоге, при импорте прихода у нас появляется товар с простроченной рег.. И приходиться выяснять правильную дату рег. на сторонних источниках. Редактируем запись, вписываем достоверную информацию в свойства товара и при следующем обновлении базы она благополучно переписывается на не верную! Это начинает бесить!

Так вот я подумал, что для торговли это не годиться :) И начал подумывать, так для себя, как бы можно было решить эту проблему, какая должна быть схема БД.

Не можно ли было создать таблицы:
Регистрация ( Ид ,Рег.номер, Название медикамента( по рег. свидетельству), ид_периоды рег ., и др.) - в этой таблице хранить данные о регистрации
Периоды регистрации ( Ид , Номер приказа МЗО, Дата приказа, Дата начала рег., Дата конца рег., и др.) - в этой таблице хранить номера приказов на основании которых была продлена регистрация
Товар ( ИД , Название, форма, един. измер., ид_регист. и др) - Таблица товара, название товара можно здесь привести к читабельному виду, потому что по рег. данным названия бывают очень длинные и не очень удобно.

Я думаю что при таком подходе будет один товар, к нему привязан номер регистрации а к номеру рег. приказы МЗО в которых он продлевался. Таким образом не надо будет плодить кучу одинакового товара и поставщикам не придется при каждой новой рег. переписывать уникальные кода. Один рас связали и все! Может я конечна что то намудрил :)

Извините меня за этот не маленький пост и возможно дурацкий :) Просто меня мучили эти мысли а поделиться не с кем. Нет у меня друзей увлекающихся компьютерами, программированием и базами данных. :)

Спасибо тем кто дочитал до конца и что нибудь понял из написанного!

tanglirPostX, если не нужно разделять товар с просроченной и непросроченной регистрацией (она, если я правильно понимаю, касается товара как класса, а не отдельных партий), то можно так сделать.

А вот за это я и не подумал :) Спасибо

А если выбирать товар в один запрос с группировкой по товару и максимальным значением даты рег.?

guest_20040621> для торговли это не годиться


> какая должна быть схема БД

Это правильнее того, что есть, но, вообще говоря, этого недостаточно. Здесь две задачи. Первая - регистрация ЛС (регистрация в смысле описания в базе данных) как набора химических соединений. Вторая - регистрация ЛС как объекта товарно-денежных отношений. Решение первой задачи будет основой для поиска аналогов. Решение второй - в том числе основой и для решения описанной вами задачи.

Это если простенько. Куча дополнительных аспектов - от товарных знаков до технологических особенностей.



В принципе, подобная схема у них реализована. У них есть справочник медикаментов, где на них есть инструкции, международные названия, состав, синонимы и т.д. И есть еще та самая таблица товар, где каждая строчка связана с медикаментами в в этом справочнике ЛС. Только товаре у них могут быть одинаковые записи, отличающиеся только уникальным кодом и сроком рег. Их там приличное количество, от чего таблица приличного размера и когда приходиться набирать приход вручную она, не то чтобы сильно, все таки притормаживает!

При гос. рег. ЛС составляется много документов на ЛС: инструкции, состав, клин. испытания, класификация АТС (по которой можно определить синонимы), полное и правильное название, вся эта информация привязана к рег. номеру. Вот я думаю что в моем случае в таблице Регистрация можно было бы и указать всю эту фарм. информацию. Это по сути и было бы ваше предложение по поводу рег. ЛС в базе

Спасибо за ответ!

[quot Last1Cmen]PostXНО зачем делить основания и периоды ?

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

[quot Last1Cmen]PostXпропущено...

а так всё верно вроде... по крайней мере так уже и реализовывали ;)

То есть? :)


Прошу простить меня за не правильную, не качественно проверенную информацию.

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

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

Но в итоге эта система все равно не достаточно корректно работает, я так понял проблема не в стыковке ихней базы и базы поставщика.

[quot Last1Cmen]PostXпропущено...

просто вот зачем хранить информацию о самом приказе и периоде его действия раздельно ? пусть будет одна таблица в которой будет информация как о приказе так и о его периоде действия... так же в неё пусть ссылка будет на сам товар ессно
ну не вижу я необходимости в выделении периодов и оснований для этих периодов... вы ведь не минздрав чтобы их за них вести :)... избыточность имхо для вас

Есть рег. свидетельство ЛС, у него есть уникальный номер который его определяет, название ЛС его форма, производитель, владелец лицензии, инструкция, состав и т.д. это все определяет рег. свидетельство а по сути его уникальный номер! У этого всего есть срок действия который определяется приказом Минздрав. Поэтому и хранить сроки отдельно, в случае продления рег. а не перерегистрации. Не создавать же каждый раз когда продлят регистрацию новую запись отличающийся только сроком рег.

ИМХО

Last1Cmen

Производитель может быть один и тот же а вот лицензиат разный. Также возможна обратная ситуация. Поэтому это понимается как два совершено разных товара.

у меня опыт Украины

я сейчас вот вспоминаю (давненько было) что работали с morion-ом likis-ом и фармтрейдом и синхронизация с поставщиком была по кодам этой самой системы мориона ликиса или фармтрейда и новые карточки товара (новые коды или новые объекты учета по большому счету) не появлялись вот так просто из ниоткуда просто потому что товар перерегистрировался



Их менеджер мне четко сказал "Новая рег., новый уникальный код, новая строка в товаре". Я думаю это и за того что у них много всяких ИТ проектов. Они собирают инф. со всех своих клиентов, анализируют ее и за отдельную плату предоставляют результаты анализа. Эти результаты каким то образом могут помочь повысить товарооборот аптеки. Вот тут я и думаю и важно, для этого глобального анализа продаж ЛС по стране, под чьей именно лицензией продался товар :) ИМХО

Last1CmenPostXглобального анализа продаж ЛС по стране, под чьей именно лицензией продался товар :) ИМХО

так это можно (если для задач отслеживать под чьей лицензией) вести там же где и поставщиков

Ну тогда не будет видно сколько товара зависло в аптеках. А вообще этот анализ сделан для аптек поэту и анализируют продажи в аптеках и по каким роз. ценам их продаю. Таким образом, как мне говорили в двух словах, они вычисляют оптимальную цену ЛС для конкретного региона страны. ИМХО