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

Я бы сделала два регистра сведений - отдельно продажи и отдельно использование со всеми необходимыми реквизитами для отчетов. А третий регистр сведений с двумя ресурсами для остатков и авансов пакетов без данных о движениях. Но возможно это устаревший вариант архитектуры и сейчас можно лучше.
Тем более что непонятно что эффективнее - джойны или отборы и в каких СуБд.

А списание регламентным заданием с заданной периодичностью, которое если обнаружит превращение в тыкву - запишет в регистр "остатков" новую цифру с какого-то момента.

Если я правильно понимаю, документов нет. Только записи регистра. Или только документы, тогда индексы отдельно включать (теоретически). Событие при записи выполняет пересчет остатков.
Для остатков взаиморасчетов желательно основание(ссылка), которую регистр не предоставляет.

Регистры не нужны, храни все в справочнике "Пакет услуг"
- Вид услуги
- Дата начала
- Дата окончания
- Клиент

Сейчас в моде будет база на sqlite с данными по услугам и на внешнем источнике данных с ЕРП.

(5) 1С начала нормально с sqlite работать?

(0) В Рознице типовой это давно есть. Бонусы. Сгораемые.

Измерения
  ДокументПродажи (для отслеживания даты продажи и любых других связанных данных)
  Клиент (что бы удобно строить отчеты)
  ВидПакета (что бы удобно строить отчеты)
Ресурс
  Количество
  Активно (булево)
Реквизиты
  ДатаПродажи (чтобы удобнее было анализировать записи в регистре)

сразу делаем 2 записи с разными датами, вторую делаем с количеством = 0 и активно = ложь

(7) вот спасибо! Оказывается это боооонусы сгорают так....

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

но изобретать свою параллельную систему типовой нахер не надо

(1)
>Я бы сделала два регистра
>а третий регистр
Так два или три? Или пока мысль разворачивается появится четвертый? Какой то поток сознания. С непонятно зачем лишней кучей сущностей. Можно чуть подробнее. Какой регистр с какими значениями, кто и что туда будет писать? Исходные данные есть в (0)

(2)Какие-то действия регламентными заданиями здесь зачем? Если по факту все происходит здесь и сейчас?
(3)В моем понимании есть. Два. Чек Пишет в плюс, свой документ в минус.

(4)Почему именно так?

(8)Какой в этом смысл? чтобы убрать не нужное? Так я и так буду отсекать по дате записи регистра

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

(10)не совсем понятно, бонусы или подарочные сертификаты?
>небольшая допилка расширением возможно потребуется
Ну как небольшая. Мне нужно хранить количество минут, и списывать их при расходовании клиентом. Я же не буду чек ему пробивать как будто он товар какой-то купил при списании. Если использовать подарочные сертификаты, мне нужно отличать их от настоящих подарочных сертификатов, чтобы проводить аналитику по продажам, чтобы не пробивать их как подарочные сертификаты(они пробиваются по ККМ как аванс). Мне нужны будут отчеты о том, как расходуются минуты, сколько когда использовано, сколько сгорело сколько осталось. Достаточно функционала, чтобы почувствовать неудобство при использовании механизма сертификатов. Если бы ты понимал как это работает и подсказал как сделать, это конечно было бы удачнее, но спасибо и на этом.

Вам это в какую примерно конфигурацию? Розница, ут, ЕРП, БГУ?

(14) Извините, плохо понимаю размышления "иди сделай два регистра или три, один из них используй для чего ни будь одного а второй для чего ни будь другого". Возможно вам кажется, что все очевидно, а это не так. Или наоборот все очевидно, а я туповат. В любом случае ничего не понятно. Сколько должно быть регистров и зачем.

(16) Розница

(0) Самое короткое решение - добавить в регистр накопления измерение "Пакет" типа дата, и списывать остатки пакетов с истекшим сроком

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

(20) Будет пухнуть регистр очень сильно и очень быстро. Да и какой смысл в этом всем? Если измерение к примеру "срок годности" будет первым и проиндексировано? То разница между отборами по отрицательным остаткам и отборами по истекшему сроку годности отсутствует. причем отбор по первому проиндексированному измерению тут даже выигрывает.

Может быть на регистре расчета сделать?

(22) регистр расчета это вытеснение по времени. И оно было бы очень круто, если бы у него была возможность а) не ограничивать начало и окончание и б) вытеснять любое количество раз.
А оно так не работает(

То есть регистр расчета без периодичности было бы очень круто..

(23) А чем под условие "купленный пакет имеет срок действия" не подходит? Как раз всегда получается что есть начало и конец действия пакета...

Период действия бонуса не должен будет выходить за пределы периода ?

(0) Пакеты со сроками действия хранятся в справочнике.

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

(15) не убедил, твои минуты это как раз и есть аванс, а вот когда их тратят это основная оплата

(28)+ Твоя контора же основной вид деятельности не продажа минут/часов а нечто вроде предоставление какой то услуги в размере оплаченных минут

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

Есть некоторая хрень,которую можно есть по частям,и у нее есть срок годности,когда она "потухает".
Так как срок от "съедания" не зависит,то храним его в отдельном регистре,где каждому элементу хрени будет соответствовать дата начала и дата окончания,сюда же можно запихать количество,которое было изначально.
Если не предполагается,что количество можно будет докупать,то регист непериодических.
Далее,в обычном регистре накопления мы фиксируем съеденное,и есть можно,пока остаток по регистру меньше записи в регистре сведений.

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

(20): самое правильное решение.
при этом по каждому расходу - кроме движения-расхода минут еще лезть вперед на срок окончания пакета и с этой датой делать сторно расхода "списания остатка". кстати и при проведении расход проверять на непревышение остатка на дату оуончания срока пакета.

(28)Это не так. Это разовая продажа доступа с ограничением по объему. Как например продажа абонемента в спортзал. Там может быть абонемент на 5 посещений, а может быть безлимит. Во всех случаях услуга предоставлена в момент продажи: доступ предоставлен, срок и количество посещений не имеют значения.

(31)Почему я не могу сделать просто вот такой регистр накопления:
Измерения
ДатаПротухания
ДокументПродажи
Клиент
И откидывать при построении отчетов или списании минут пакеты сразу с отбором ДатаПротухания меньше текущей даты? Простая штука же вроде?

(33) Продажа услуг в розницу это тонкий момент.
https://kontur.ru/ofd/news/6669

Процитирую:
"Если клиент получил товар или услугу не в момент оплаты, нужно формировать два чека. Первый — при поступлении денег на счет, второй — при отгрузке товара или выполнении услуги."

Услуга же не продажа абонемента а то что доступ к чему он предоставляет, сами посещения.
Поэтому моментом расчета в рознице становится момент отгрузки товара или оказания услуги.
Короче вы один хрен обязаны по 54-ФЗ будете пробивать чеки по ККТ на каждое посещение.
Для безлимитов же все тяжко и спорно, тут запрос в ФНС думаю надо как правильно по ККТ пробивать.

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

(34) Можешь. Осталось только выделить пакет в отдкльную сущность. См. (27).

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

(38) Затем, что в регистре ей не место, это не измерение. Ты как собираешься закрывать регистр по этой дате?


P.S. А наименование клиента не хочешь включить в измерения? А то, знаешь ли, лишнее соединение будет... :)

вот нахрена мутить новые регистры если 85-90% от необходимого уже реализовано и достаточно (см.(20),(32)) чуть подпилить алгоритмы, возможно(!) добавить один документ или просто доп.реквизит в документ - и накрутить отчеты... какой-то нубско-максималистский кодерский зуд...

(39)>>Ты как собираешься закрывать регистр по этой дате?
Точно также как и по любому другому измерению

>А наименование клиента не хочешь включить в измерения? А то, знаешь ли, лишнее соединение будет... :)
Наименование клиента не будет учувствовать в 99% запросов к регистру. Дата будет протухания будет

(40)>> вот нахрена мутить новые регистры если 85-90% от необходимого уже реализовано и достаточно (см.(20),(32))
(20)Предлагают раздувать таблицу остатков регистра(незакрытые остатки как вам наверняка известно, копируются на первое число каждого месяца), за ради меньшего количества разработки. Это решение имеет право на жизнь, но я не считаю его уместным. Но также и не считаю недопустимым. Разумеется можно как-то сворачивать это дело, корректировать, пересчитывать и тд. Это называется "Сначала создали себе проблему, а потом бросились ее героически решать".
(32) Предлагает отдельную жесть, какие то пересчеты при каждом проведении. Не прозрачный код, неочевидные движения. Сиди потом разбирай, почему остатки не идут и почему были сделаны именно такие движения. От таких вещей надо максимально отказываться если есть такая возможность. Еще оба варианта предполагают писать далеко в будущее, не вижу в этом криминала, в отличии от большинства посетителей этого форума, но мне это не очень нравится.

>>нубско-максималистский кодерский зуд.
Конечно, конечно, все кто делает задачу не так как вам она видится нубы и дураки.

Еще раз предлагаю не изобретать своих нетленок в типовой Рознице а просто использовать механизм приобретения подарочных сертификатов и оплатой ими посещений

(43)+ https://its.1c.ru/db/metod81/content/7018/hdoc

(44) сорри ссылка не та, там УНФ а Розница вот
https://its.1c.ru/db/metod81/content/7675/hdoc

(43)Я рассмотрю этот вариант, мне кажется допилок будет больше чем профита. Но посмотреть посмотрю обязательно

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

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

>>открывается своя формочка, вводит туда сумму и опс все сделалось и строчка в чек для пробивки/оплаты встала
Наличие таких формочек даже не обсуждается. Почти на каждую допилку(если она предполагает доп взаимодействие с пользователем) в РМК рисуется отдельно кнопка. В данном случае это будет происходить тоже. Чтобы был надо было выбрать клиента, вид продаваемого пакета, а все остальное конечно РМК должна сделать сама. В том числе описанные тобой действия. Будет там под капотом механизм сертификатов юзаться или свой регистр, вопрос чисто технический. Свой регистр в данном случае мне кажется более простым вариантом.

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