Re: Учет медикаментов в ФБП. Метод сплошной идентификации



Posted by Анимица Анатолий on May 06, 1999 at 14:34:20:

In Reply to: Требуется настройка посерийного учета медикаментов в ФБП posted by Бутченко Игорь on May 06, 1999 at 03:05:54:

Задача складского и бухгалтерского учета медпрепаратов решена мною года два назад и с тех пор не требовала модернизации (как ни странно). Поэтому на выбор могу предолжить три варианта:
1) взять описание алгоритма (здесь и сейчас),
2) получить у меня эту реализацию as is,
3) попросить дописать ее по-человечески с использованием новых функций ultrah, а то в варианте 2 очень много кусков, в которых возможности, прямо прискутствующие в ultrah, реализуются разными искусственными методами. Бывает, сам не понимаю, что там написано (правда, работает).

Алгоритм. Балансовые счета (41,10) - синтетические. Учет по ценам приобретения (заготовления, производства). Естественно, НДС остается на фронтире 19-68 и в другие балансовые счета не попадает, кроме поглощения в 81. Розницы нет, поэтому не попадает и на 41. Существует единственнный счет "номенклатура", на котором медикаменты и всякие другие вещи, которые попадают в накладные, фактуры, чеки и так далее (напимер, транспортные издержки). Особой специфики кодирования обозначения нет, можно написать рядом VitaC и 41-vitac и Vitc05*200, т.е. можно заложить какой-то смысл в кодирование, а можно обойтись только удобством отбора (филитрации и формирования групп). Есть некоторый счет SKLADS, обозначающий список статических складов, на котором позиции номенклатуры находятся физически. Кроме этих SKLADS, существуют временные (и виртуальные) склады - например, некая транспортная партия представляет собой склад, точно так же склад представляют собой остатки мед.сырья в производстве до их списания (т.е. когда что-то уносят с 10 на 20 счет, оно там продолжает жить, пока с кредита 20 сумма не уйдет в дебет 37 или 40 счета - как построить учет выпуска и формирование себестоимости). Вещь одновременно находится в N ипостасях (каждая ипостась - это количество и сумма, цена не применяется принципиально):
У каждой позиции есть сумма и количество всего в виде экстрапараметров 'qty' и 'sum' на субсчете *a (позиция номенклатуры), они же на складе b=[n1 @SKLADS] в экстрапараметрах *a,b+'qty',*a,b+'sum', они же на складе b им на балансовом счете c (- 10,20,40,41,45, где (- это я не нашел, как лучше изобразить "принадлежит" *a,b+c+'qty'. И так далее, всего их там набирается до десятка, причем программы построены так, что всегда соблюдается принцип сохранения суммы и количества. Теперь к сериям. В процессе обкатки удалось выделить четыре существенных параметра, естественно, записанных в экстра:
а) серия - 11, а лучше 10 символов любой стркутуры - числа, буквы, знаки, как получается. Есть вариант, когда два поля вопросов операции (до 22 символов) применимы для обозначения серии, но на практике до этого не дошло. Потом покажу, почему это неудобно.
б) единица измерения, на одном *a этих единиц может быть сколько угодно (в ампулах, ЕДВ, г и коробках одновременно)
в) срок годности, у меня в формате ГГГГММ, можно как угодно
г) лот. Самый важный для обсуждения параметр.

Применяется метод сплошной идентификации объектов в пику всяким там FIFO и LIFO, которые суть частные случаи первого. Это значит, что выбор объекта происходит в три или четыре шага - где, еще раз где, что, лот. У каждого лота есть все - серия, единица измерения, количество, сумма и так далее. Формы-селекторы работают все над одним списком SKLAD (эта самая номенклатура), раскрывая разные детали номенклатуры на разных стадиях отбора.
Вот, собственно, и все.

Всякие формы типа сводки по складу отображают списки с оборотами и остатками с учетом аргументов. Недостаток количества кнопок было в свое время предложено компенсировать общим управлением группами аргументов чераз [user]+'arg(i)' в extrd.dat, но это дело не было доведено до конца - пользователи привыкли обходиться.

Складские карты представляют собой совершенно монструозные списки - представьте себе задачу выдать одновременно все складские карты на 1000 наименований медпрепаратов с 3..20 серий на каждом за год (один как бы лист на каждую серию) - это одновременно 10000 карточек в среднем по 3..10 листов. Смешно сказать, но однопроходный механизм формирования такого списка позволял на P233MMX получать это все за несколько десятков секунд за год без всяких fastfact, беда только, клиент clw.exe не умеет это делать для >16000 строк текста. Честно говоря, такой режим применялся пользователем только для ошеломления публики, а на практике их никто никогда не печатал - это никакой бумаги не хватит, при нужде печатался максимум список "все серии одного препарата за ограниченный период месяцев" - тоже листов по 30 печати, не так мало. Но это вообще за доли секунды сервера и несколько секунд, пока клиент движок окна формы до низу дотащит.

Забыл написать формат лота: lt - это номер лота.
*a+(все что было раньше насчет обособления на складе, счете и т.п.)+[intsn lt]+'qty' - это количество лота lt там где написано. И все остальное так же.


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

Желаю успехов.
ААА


Пpишедшие ответы: