Есть прикладная задача для обучающего центра. Пользователь покупает абонементы, которые могут иметь ограничение по числу и типу занятий (или не иметь) и по сроку (или также не иметь). Т.е. можно 8 занятий танцами в течение месяца, можно сколько угодно плавания в течение месяца, можно любого спорта на выбор - 20 занятий и т.д.

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

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

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

Можно, ввести дополнительный регистр сведений со статусами, но тогда непонятно как сделать его управляемым при изменении даты.

Может, есть и еще какое-нибудь более элегантное решение?

Заранее благодарен за совет!

Расскажи свои варианты. Глядишь, и подскажут их плюсы и минусы

Так я ж вроде и рассказал.
Вариант 1.
2 регистра: 1 (сведения) = даты, 2 (наколение) = остаток занятий. Расчет статуса проводится на лету

Вариант 2.
3 регистра: те же, что и в 1 + регистр "Статусов". Соответственно при проводке "Отчета занятия" проверяется, как изменилась дата и остаток и вычисляется значение статуса.

Вариант 3.
Любой более элегантный

(0)  абонемент уникален получается и отсюда две таблицы . Таблица абонементов и таблица продаж абонементов.  Вроде все.

И главное .... не усложняйте

rsv, Спасибо, но к сожалению не понял Вас (((

Петров может купить более одного абонемента (например, на плавание на месяц и на борьбу на 8 занятий). Это все будет зафиксировано документами "продажа абонемента".
Теперь через какое-то время Петров приходит в группу борцов. Администратор центра должен знать:
1) Имеет ли вообще Петров право прийти на занятие (не окончился ли абонемент)
2) Не нужно ли Петрову напомнить, что абонемент заканчивается и в следующий раз надо захватить деньги.

Как это сделать в 2 таблицах?

...т.е. система должна проверить: а) окончание срока абонемента (если он имеет срок); б) окончание лимита занятий (если таковой имеется).

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

...и проблемных статуса минимум 2: "завершается - надо напомнить" и "завершился - на занятие не допускать"

(5) Фишка в том что продажи и характеристики абонементов разные вещи . Ну ...  разведете полями в таблице абонементов  возможные состояния оного.

После занятия Администратор создает документ "отчет занятия", где указывает, что прошло занятие по борьбе, где были Иванов, Петров и Сидоров. Все остались довольны

rsv, Так и есть. Есть справочник абонементы. В нем указано "борьба на 8 занятий". Дальше, есть регистр сведений, где указано: Иванов 8.09 купил этот абонемент (регистр управляется документом "продажа абонемента". Он ведь может покупать этот абонемент сколько угодно раз

Так что, 2 таблицы есть. Вопрос только в том, как лучше контролировать "проблемность" абонемента

(0) В данном случае, регистры не нужны. У вас два документа: продажа и посещение. Больше не предвидится. Вот и оставайтесь с этими двумя документами. Зачем вам регистр?

Справочник. Регистр ненужен

Всё что стремится к нулую делай регистр остатков. Регистр сведений не нужен.

РС состояние абонемента
РН Количество посещённых занятий

(0)  какая наивная постановка задачи.  А если человек заболеет , безлимитка пересчитается или нет?

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

Есть перерасчеты пропопущеных занятий по вине центра.

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

magicSan, спасибо! А как тогда лучше учесть Безлимит в регистре накопления?

torgm, ну почему наивная? Я просто несколько упрощенный пример показал, чтобы зря текст не писать.
Вся дополнительная логика в этих регистрах не отображается, а используется в момент проводки соответствующих документов.

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


В любом случае (с) усложнять - не строить ) Расширять потом систему придется, но надо бы хорошо сделать базовую основу

magicSan, и еще вопрос. Какой документ будет делать записи об остатке дней до даты истечения абонемента?

itlikbez, спасибо большое!
Если я Вас правильно понял, что для того, чтобы подсветить по-разному действующие и просроченные абонементы мне в соотв. форму нужно будет встроить:

1) Запрос определяющий, не просрочен ли каждый абонемент (к документам "Продажа" и справочнику "Абонементы")
2) Запрос, определяющий, сколько занятий на каждом абонементе (это ИМХО сложнее, т.к. не исключено, что человек неделю ходил по безлимиту на плавание, а потом купил 8 занятий).

В принципе Вы этот подход предлагаете?

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

простите, фоБка (вот она автозамена)

(0) >> Можно сделать ... регистр накопления с остатком занятий.

Он в ноль будет когда нибудь выходить?

(20) Примерно так. Только двумя запросами вы не обойдетесь.
Не пытайтесь в декларативный язык (язык запросов) запихнуть всю бизнес-логику.

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

А, если мне еще в ряде форм то же самое надо - то везде программно его заполнять?

Я когда-то делал подобный код, но, по-моему, это не самый элегантный вариант.

Матиус, конечно будет. Вот Вы бы, купив абонемент использовали бы все занятия? Думаю, да.

(25) Делаешь функцию СтатусыАбонементов(массивАбонементов) и размещаешь ее в общем модуле.

(25) От дополнительных регистров ваша сложная бизнес-логика простой не станет.

itlikbez, Ну вот для примера.
Мне нужно сделать автоформат в форме "Отчет занятия", в котором красным будут показаны те, у кого осталось 1 занятие или 7 дней до окончания абонемента.

Как построить второе условие в запросе мне понятно. Как сделать первое? Группировкой во вложенном запросе?

Условным оформлением

DrShad, условное оформление задавать средствами формы или программно?

(26) Я, конечно, старался бы использовать все занятия. Но иногда я болею, иногда уезжаю на Бали, изредка мне просто лень. Остатки не использованных дней прошлых лет так и будут болтаться в БД до скончания времен?

(0)
1. Срок действия абонемента надо отделить от состава занятий. ТО есть состав занятий - это оборотный регистр, в котором план-факт по количеству, а измерения - абонемент и виды занятий. Срок действия - отдельный РС, хранящий период действия для абонемента.
2. Взаиморасчеты и оплата - две отдельные темы, я бы их не смешивал. Признак того, что абонемент оплачен, я бы в отдельном РС дублировал, чтобы быстрее получать (иначе придется в обороты без периода лазить).
3. Продажу от оплаты я бы тоже отделил. Потому, что сегодня так, а завтра они рассрочку введут и вся твоя автомтаизация по звезде пойдет. Отдельный документ "выдает" абонемент и фикирует дебиторку с планом занятий. Отдельный - оплату фиксирует. Пока нет рассрочек, можно прикрутить какую-нить плюшку, чтобы много времени не тратить на ввод двух документов. Документ оплаты гасит дебиторку, наворчивает взаиморасчеты, устанавливает факт оплаченности по абонементу.
4. Статус "заканчивается" и "осталась одна неделя" - это регламентными заданиями каждую ночь (или минуту или секунду - пофиг). По идее тут даже лучше стартовать на кого-то бизнес процесс по отработке этого события (кто-то ж должен позвонить и попытаться пролонгировать, да?) Иначе смысла в этом сосотянии нет - ну 1 днеь и один день, всем пох.

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