Небольшая самописная конфигурация по учету подписных изданий.
Фиксируем факт подписки: Документ Подписка делает движение по регистру накопления ПодписныеИздания началом дня, например, 1 января 2014 г.
Но случается разное и от подписки отказываются. Чтобы учесть это в программе делаем минусовое движение по регистру ПодписныеИздания. Отказ надо сделать также 1 января.
Если сделать оба движения началом дня, это ведь некорректно?
Или сделать второе движение 1.01.14 00:00:01 ?
А как методически верно отразить в регистрах?

текущей датой логичней же

текущая дата 25.12.13, а подписан чел с 1.01.14.

(2) и что?

факт отказа произошел же 25.12

кстати, мы ещё ни разу не отказывались от фото

при подписке в движении указывается период, с которого подписка начнется, т.е. 1.01.14

(6) так...

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

подписные издания выдаются на торговых точках.
Есть переносы подписки с одной точки на другую (например, закрылась торговая точка временно, отправляем подписчиков  в др. место получать), есть отказы и до и во время подписки
Чтобы знать в любой день куда сколько изданий отправить и был придуман рег. ПодписныеИздания.
т.е.  в нем я тупо записываю:
1.01.14 начнем выдавать Иванову В ТТ1 газету,
10.01.14 Иванов уедет в гости, выдадим ему газету в ТТ2
18.01.14 Иванов снова начинает получать газету в ТТ1.

А Петров:
1.01.14 начнем выдавать Петрову в ТТ1 газету
1.01.14 перестанем ему газету выдавать.

как то так

(9) то есть, нужно хранить периодическую информацию такой вот структуры. так?

(9)Так регистр накопления или все-таки сведений?

я храню в рег накопления, а потом на нужную дату просто снимаю остатки

(12) это новая мода - эмулировать РС на РН

(13) остатки чего?

(15) срез последних остатков

(15) виртуальн.таблица ПодписныеИздания.Остатки

(17) он в курсе. остатки чего?

(14) мне кажется, РН здесь больше подходит

(17) 01.01.14 ТТ1 - выдать 1 издание,
10.01.14 ТТ2 - выдать 1 издание,
18.01.14 ТТ1 - выдать 1 издание

(0) а не проще убрать с проведения документ прописки чтобы движений вообще не было?

(21) чел подписался в октябре, по бухгалтерии это уже прошло, приходится учитывать, что это отказ

(20) настоящим уведомляю, что 1го января нужно выдать с ТТ1 одно издание. какое ещё накопление?

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

(22) про учет в бухгалтерии в (0) нет ни слова

+(25) и фото в Alyenka ни пиксела

(24) спс за аргументированный ответ,
(25) бух здесь не трогаем, не о ней речь.
Даже если это будет Регистр сведений, возвращаясь к ситуации в (0) как отразить отказ?
Если сделать оба движения началом дня, это ведь некорректно?
Или сделать второе движение 1.01.14 00:00:01

(26) какие фотки, дай прогу доделать до Нов года)))

(27) не надо выдавать одно издание с 1го января? удали запись

(28) с фоткой у тебя карма очистится и ангел прилетит помогать

сори, если элементарно, но тем не менее:

Иванов подписан на 1 полугодие

записываем в Регистр сведений:
начало подписки:
1.01.14 Иванов ТТ1 1 издание
Конец подписки: как отразить?

(31) 010114, 300614. или 010114, полугодие. внезапно, правда?

а не просматривается ли здесь применение регистров расчёта для задачи, не связанной с з/п? давно мечтаю практический пример встретить

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

(31)В РС можно завести "Начать" и "Прекратить". И по срезу последних на любую дату таскать.

В РН по остаткам, если будет зафиксировано
25.12.2013 -1 (отказ от подписки)
01.01.2014 +1 (подписка)

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

(0) что некорректного в двух движениях на начало дня?

(36) так вот и хотела понять: корректно/некорректно?

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

(37) и до сих пор не поняла, что городишь хрень?

(0) Период в регистре должен быть тот, когда движения были занесены, а сама дата подписки - это совсем другое, скорее всего реквизит справочника подписки или доп. регистра сведений, т.е. регистрируем факт подписки 20.12.2013 в регистр в период пишется 20.12.2013, регистрируем отказ от подписки 25.12.2013 период 25.12.2013. Сведения о начале подписки (т.е. 01.01.2014) хранятся в отдельном регистре. Думаю так должно быть

Например регистр сведений СведенияОПодписках, в которых храняться даты начала действия подписки и дата окончания и прочие сведения

(37) а ты попробуй
(38) +1

(38) Дату пихать в измерение РН - не есть гуд

Типовые извращаются ПериодамиЗавершения и хитропопыми запросами к ним. Видимо такой функционал реализован в восьмерке через задницу.

(0) Имхо, Ваши "отказы" - это "сторно" существующих(!) записей регистра. Другими словами, в записи сторнирования - все значения равны сторнируемой записи (кроме количества - оно с минусом, разумеется). Что смущает?

Если исходить из того, что "подписка" - это период по сути своей - то подписку тоже можно хранить в измерениях.

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

НО: запрос на остатки должен отбирать только "актуальные" подписки и нужно дополнительно "свертывать" остатки РН по периоду окончания подписки.

(+45) а как реализован механизм завершения подписки?

(46) Этого автор нам не озвучил так, как это считает несущественно и вопрос был про "два движения в один момент времени". Автора этот аспект смущает.

Вероятно, имхо, автор не в полной мере понимает термин "момент времени". И что бы автор совсем запутался :) - напоминаю: в записи РН кроме даты есть ещё регистратор :))

(43) Бери выше, измерение это вообще фигня, первый индекс всегда по периоду а он *заглядывает в блокнотик*....о ужас!!! Кошмарный тип "дата"!!!! Как же так?!

Дата в полях плоха тогда, когда она в составе составного типа - в книжках написано всё.

Есть некая конфа, которая сплошь и рядом в одну секунду в РС делает записи о состояниях. Постоянно путается последовательность записи, ещё хуже - это их просмотр через операции. Но встречается это только из-за того, что в РС по бизнес процессу пишет сразу два состояния один регистратор.

Если регистраторы разные - никакой путаницы и некорректности не будет - кто последний тот и па...следний, да.

Всё будет хорошо!

спасибо всем большое)

спасибо на рабочий стол не намажешь