Суть:
Врач работает по Специальности в Отделении в Больнице

задача - ввести лимитирование на типы приема на каждую из этих четырех групп

по интервалам


например врач может принять не более двух пенсионеров в день, 5 в неделю 15 в месяц
все терапевты отделения - 6/15/30 соответственно

как организовать метаданные для расчета?

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

лимиты задаются на сегмент групп пациентов
т.е. есть группы пациентов
ДМС согаз
ДМС альфа
ОМС приписанное
ОМС меж тер
наличные

лимит задается на сегмент
например ОМС
или ДМС

Первое, что ы голову приходит:

Измерения
   ПериодПланирования - первый день месяца, можно стандартный период
   ГруппаПациентов - справочник этих твоих групп
   Объект - врач либо подразделение, составной тип. Название измерения сам придумывай
Ресурсы
   ВДень
   ВНеделю
   ВМесяц

Вопрос о том, как по пациенту угадать, в какой он группе, уже решен или это тоже надо придумывать?

"например врач может принять не более двух пенсионеров в день, 5 в неделю 15 в месяц
все терапевты отделения - 6/15/30 соответственно " - Какой-то странный расчёт имхо.

То ли у вас в месяце всего две недели (для всех), причем для одного - три недели, то ли я чего-то не понял.

Самое главное-то и не написал - это регистр остатков. Документ планирования делает приход, документ \, которым прием оформляется, делает расход. Остаток по этому регистру......... нетэтовсёкуета

ВДень и ВНеделю не может быть остатком, ибо тогда надо ПеиродПланирования на каждый день размножать, а это хреново

А если сделать его - регистром сведений?..

это интересно

Тогда понадобится реистр накоплений, об которого сверять эти сведения и смотреть, осталось ли на день/неделю или нет.
Получается, что регистр остатков, в котором одно из измерений будет День, все равно нужен, ибо иначе как получить, сколько сегодня бабушек принял врач Околелов Герольд Фастович...

не рекомендую флудить в этой ветке и засорять форум бессмысленными сообщениями. Ни кому.

А чего удалили то? Задача неэтична. Цель - отказывать пенсионерам в мед. услугах.

спр врачи. реквизит спец
рн
врач сегмент принято
рс
спец сегмент вдень внеделю вмесяц
при проведении проверять остаток по рн по периодам и сравнивать с рс

(8) Одним имхо не обойтись. Для недели и месяца тоже понадобится (судя по цифрам в (0))

(12) да, я тоже подумал, что надо три, но как-то очканул, что заклюют местные иксперты

(11) я вот этого вообще не понял: "при проведении проверять остаток по рн по периодам и сравнивать с рс"
это ты о чем? Шотакоэ "проверять остаток по периодам"?

(15) сумму оборота

(13) Хотя, может, можно и одним регистром обойтись, но не знаю, где алгоритм расчета будет сложнее.

(16) я не понимаю. Запрос может покажешь? Я не понимаю, как из регистра накопления со структурой "врач сегмент принято " получить, сколько доктор Околелов сегодня уже принял и сколько за всю неделю.

(11) всё верно

Недавно делал такую задачу, там были лимиты трудоемкости по изделию.

З.Ы. Но ставить лимиты на мед. услуги пенсионерам я бы отказался.

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

А вот надо ли при этом пациентов на конкретное свободное время записывать?

(21) ну, в (0) задача поставлена как "при записи на прием, узнать доступные остатки"

Регистр остатков с измерением "вид счетчика" и "остаток лимита".

"Вид счетчика" это справочник, формируется динамически по разным параметрам, можно ПВХ заюзать.

В начале каждого периода происходит "взвод счетчика", ставится допустимый максимум по счетчику, каждой "прием пациента" уменьшает счетчик.

(19) зря
это же нужно пенсионерам,чтобы получить в платной клинике бесплатную помощь

(18) посмотри сам рн обороты и периодичность разная

(25) а не получится дофига большой справочник или ПВХ? Там ж записей будет всего вдвое меньше, чем в регистре в итоге...

(25)+ В смысле каждый документ "прием пациента" подбирает виды счетчиков по правилам, смотрит/проверяет остатки по ним по регистру и если все ОК то при проведении делает -1.

(27) ну, то есть я правильно догадался - черная магия с оборотами, которая в пределе скатится в колбасню с физической таблицей.
Три регистра от этого спасают, имхо.

(0) задача с учетом корректировок решается двумя документами установки лимитов, одним Рг накопления и движениями существующим мед.документов

важно вынести период в измерение и писать лимит ранним периодом

(28) Нормально, кол-во "видов счетчиков" будет в зависимости от кол-ва " видов лимитов" * "кол-во сегментов"

(30) нет не правильно
есть такой объект - регистр накопления. он бывает вида Обороты
http://www.v8.1c.ru/overview/Term_000000176.htm#05

(32) а "день" - будет разрезом справочника или нет?

(34) зачем? Период и так есть

(32)+ Кста ПВХ не обязателен, но смотря какие будут хитрые правила для лимитов.

Если они будут пересекаться то пипец, типа можно принять 5 пациентов по "Согаз" или по "Альфа". Т.е. разные складывания/вычитания условий

(33) а, регистр ОБОРОТОВ. Ясно. То есть, доступный лимит - это разность между данными РС и результатом трех запросов к оборотам за разный период. Понятно.
Тож вариант.

(34) Неа, день (период в целом) он внутри "вида лимита" засунут. Каждый период (день, неделю и т.д.) нужно счетчики нужные взводить - плюсовать по ним расходы.

(30) после запроса получится чтото типа
врач сегмент оборотзадень оборотзанеделю оборотзамесяц рсвдень рсвнеделю рсвмесяц
вася пенсионер     1             1             8       2      5       15
сравниваем циферки и ок

(38) то есть, про один множитель ты коварно слукавил в (32) :)
реальное количество записей " видов лимитов" "кол-во сегментов" "день".
Как по мне,так избыточно. Главным образом, у пользователя мозг выкипит при работе с обоими справочниками и надо будет городить тьму кода, чтобы интерфейс понятный сделать.

(40) согласен период лимита тоже в измерение надо

(41) + причем с датами с .. по ..

(42) а ну как пересечения?.. я чо-та опасаюсь периодов с-по в измерениях. Не по-христиански это как-то...

(43) Дык справочник же "Периоды лимитов".

По сути это система бюджетирования...

+(43) во всяком случае 3 РН с остатками на день, неделю и месяц как-то субъективно более по-божески выглядят. Кода по карйней мере на порядки меньше надо писать, чтобы задним числом пользователи не разбуярили всю базу.

(45) Да но вариант отдельных РН на разные периоды не гибкий нифига, вот захочется лимит на полгода или год и шо?

(46) горевать

(46) Знаешь притчу про глупого кота, который в первый день всех мышей переловил? :))

т.е. пока решение - на каждый период по РН оборотному
установка лимита - + на начало периода
далее списание по дням

проверка лимита - обороты за период НАЧАЛОПЕРИОДА(&ДатаПроверки,МЕСЯЦ/НЕДЕЛЯ)

Не показывайте эту ветку Охотнице.

(49) один рн
лимиты - рс

(49) один РН, у которого период - это какое-то хитрое измерение-справочник, обозначающее период (неделя, месяц, день). Или перечисление.
Три регистра - это действитеьно негибко совсем

+(52) это для фактических значений. Для плановых - РС с тем же хитрым измерением. Ибо там на вес месяц одна запись нужна

плясать мы начинаем от дня
надо показать расписание на день

на этот день получаем список лимитов - из РС
т.е. РС  - начало периода - конец периода - действующий лимит (справочник) - сумма

из лимита получаем описание периода (строкой?) допустим НачалоПериода("ДатаРасписания",МЕСЯЦ) - КонецПериода...

по том по получившимся настройкам надо получить обороты за период по выбраным лимитам


вопрос в том, что это вроде как кроме как запросом в цикле не решить

расписание выводится пользователю на неделю по 10-20 специалистов

6*10 - 60-100 дней просчитать

(48) Да знаю, но не могу лень перебороть ((

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

Как вариант, можно лимиты записать в плановых оборотах, а талоны с=записывать в фактических оборотах.

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

(57) На оборотах тебе в запросе придется сравнивать не с 0 а с некими разными установленными лимитами где то.

Но плюс то не требуется заранее лимиты прописывать, они онлайн будут.

Но минус при работе задним число (док приема пациента) будут дикие тормоза и не стыковки.

И да задачку из 0 моя бы решить отчетом который каждый день автоформируется, автораспечатывается и кладется на стол глав врачу для оргвыводов.

Где +/- показаны переборы лимитов для врачей, а делать запрет для работы считаю глупостью как и вывод предупреждения при работе.

(59) я только вот, что не понимаю: при проведении документа, который факт должен записать, как находить элемент этого твоего справочника с периодами?
Находить все, у которых период включает СЕГОДНЯ? и делать движения по всем элементам по очереди?

(61) Угу правильно догадался (по дате дока выбирает все элементы из справочника периоды с попадающей датой) и аналогично при отмене проведения не забыть это.

(62) при отмене какой смысл? Зачем-то надо выключить удаление движений при отмене что ли? Зачем?

или речь про какой-то умозрительный документ "отмена приема потому, что бабушка не явился"?

(63) Перепроверка точнее, вдруг некто вумный уже после проведения дока даты в справочнике "периоды лимитов" взял и поправил

(59) // Но минус при работе задним число (док приема пациента) будут дикие тормоза и не стыковки.

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

(65) воооо. Это то, что я говорил, когда имел в виду килотонны кода, чтобы задним числом не разломали. Этот спрвочник не должен руками меняться. Должна быть какая-то лютая форма, в которой шаг влево и шаг вправо будут полностью невозможны.
Цена решения, однако. Хотя и не такая уж, чтобы высокая, с учетом того, что добавления промежуточных и более широких периодов планирования в результате - это всего-лишь перепроведение массива документов и оно само

(67) а массив документов планирования может быть минимальным. Проводить так и вовсе можно одним единственным документом. Промежуточные документы завотделами пишут,, а итоговый - главный провел и все увидел. Подпись там покрасивей отобразить... даже на весь экран вывести и та-дам воспроизвести на динамики.

(68) неее, я говорю про перепроведение документов факта. Если у тебя задним числом добавляется период планирования, например, квартал, то, чтобы по текущему кварталу факт появился, надо документы факта с начала квартала перепровести.
Но это в общем не большая беда, я считаю.

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

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

(66) При оборотном регистре лимиты в регистр не пишутся, значит их нуна получить из общего нечто где все установки лимитов.

А там за года работы накопится просто овердофига... и при получении задним числом будет запрос по всем будущим записям.

(72) как это "при оборотном не пишутся" - в текущем состоянии у постановщика задачи они вообще никак не пишутся.

Зачем их писать "овердофига" ?

Мы говорим об оборотном регистре планирования.
Потребуется измерение "ВидЛимита", в котором будет определяться в плане по какому значению лимитирования будет выставлено оборотное значение. Да, очевидное несоответствие с размерами периодов, когда у этого периода начало, когда у него конец - это проблема методического характера и ее потребуется определить с максимальной однозначностью.

Например, если у меня в планировании был установлен период планирования Месяц, а горизонт планирования Год, то соответственно этой установке все плановые значения записывались с датой на 01 число каждого Месяца в Году.
Когда заикнулись о периоде планирования Декада, то соотв. 01 11 21 и с обработкой конца периода (выравниванием на конец месяца) и тогда запрос по оборотам за период в плане всегда с корректным результатом, хотя дата начала и дата окончания произвольная... Подход примерно такой.
Естественно, что периодичность День и лимит 2 штуки - это незачем записывать в плане на каждый день года. Так же с периодичностью на Год в принципе, если оно не меняется произвольным образом.

з.ы. У меня было произвольные (гибкие) значения планирования, поэтому никакого выигрыша в количестве записей от замены оборотного регистра на периодический не получалось. Но и задача была не в больницах :)

запись на прием идет одним документом привязанным к БП

списывать лимиты - РН с измерениями
отделение специальность кабинет врач + сегмент групп

первая часть определяется по данным - куда записан
вторая - это все сегменты в которые входит группа пациента

т.е. на одну явку - может быть от одной до десяти и более записей в списание лимитов

______________________________________________
______________________________________________

данные об установленных лимитах - пишем в РС
Измерение - Ключ аналитики (отделение специальность врач кабинет) + дата начала + дата окончания

проблема в том, что расчет расписания будет слишком долгим при таком подходе - придется считать каждый день по отдельности (или даже каждый лимит на день)

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

как вариант - писать списание лимитов по всем возможным установленным лимита

т.е. запись на прием будет проводится дольше (но фоновые никто не отменял)
зато считать отчет будет быстро
ну и заднее число (изменение установленных лимитов) считать  надо будет

т.е. иметь один РС (все-таки РН) Ключ аналитики - лимит - списано - остаток


при проведении явки искать все лимиты на которые она влияет и делать запись о списании

+(75) если вот так?
каждый лимит (отделение + специальность + врач + кабинет + (вот тут важно) период действия)  писать в справочник "КлючиАналитикиЛимитов"

по каждому ключу делать "плюс" в РН
а каждая запись - соответсвенно минус по всем подходящим ключам

минусы:
справочник ключей будет расти бесконечно (ибо аналитика по периодам)
но историю можно не хранить

плюсы: быстрый расчет отчета

что насчет такого подхода скажите?

а справочник ключей аналитики - заменяем на документ установки лимита - там вся аналитика уже есть

(76) бесконечно - это пара тысяч элементов на весь период жизни базы.

(77) справочник тебе дает контроль над колдунствами с пеиродом пралнирования в заднем числе. Без справочника пользюки расхерачат тебе учет за неделю.

хотя - нет
документ может быть вида на 2016 год установить лимит 1 пациент в день

такой документ породит 357 ключей аналитики

(78) у меня пара тысяч будет только по условно постоянным ключам отделение специальность врач кабинет

умножаем это на 356 - т.е. как минимум 500 - 1000 тыс. записей в справочнике ключей на год

Зачем списание лимитов?
Лимит - план.
Прием у врача - факт.
Как план и факт с лимитами сделан - можно в типовых посмотреть.
Нафига кривые велосипеды?

(83) Затем, что до факта (собственно приёма), надо записать пациента, не выходя при этом за лимит.

(84)
Да, и поэтому нужно делать проверку лимита.
А списание лимита - это не проверка лимита.

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

т.е. согласен с (85) проверка все равно должна делаться всякий раз перед записью документа и сообщение юзеру должно выдавать всегда (методист должен решить по условиям выдачи предупреждений).