Больше на ядро похоже, чем на модуль. Учетные периоды логичнее наверное было бы в ядро добавить.

А вот Управленческий баланс , тут пока не ясно. 2 разных баланса в ядре чтоли хранить.

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

А где все мое сообщение?

А... Понял...

вроде речь идет про ПРОИЗВОЛЬНЫЕ учетные периоды, т.е. он может быть и пару минут и пару лет, не совсем понятно как они должны коррелировать с бухгалтерскими месячными периодами...

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

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

Это вот сейчас к чему было написано?

вроде речь идет про ПРОИЗВОЛЬНЫЕ учетные периоды, т.е. он может быть и пару минут и пару лет, не совсем понятно как они должны коррелировать с бухгалтерскими месячными периодами...
а здесь сразу предлагается начать с конкретного решения....

я подобное скриптами реализовал, впринципе вполне удобно

то как вести перерасчеты если, что то меняется в следующем месяце, например клиент хочет расторгнуть договор 3 числа или меняет тариф или по какой то причине что то меняет, что приводит к перерасчету, лезть в прошлый месяц и менять в нем наработку?

В смысле вместо диапазонов трафика что вроде "пакетов" через тарифные опции скриптами активируешь?
Мне, если такое такое понадобится реализовать, придется делать это для модулей телефонии.

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

Если все договора работают по календарному месячному финансовому периоду, то прошлый месяц можно закрыть, например, 10го числа, если же финансовые периоды могут быть сдвинуты, то закрыть мы сможем только через месяц. Но тут, понятно, проблема не в самом пересчете, а то что может быть затронута наработка периода по которому уже выставлены документы. В таком случае перерасчет должен осуществляться с учетом периода, а значит вначале алгоритм должен разделить по группам договора с одинаковым периодом и, затем, для каждой группы сделать пересчет в рамках финансового периода.

звучит не очень хорошо, я как начинаю представлять как это реализовать, становится страшно

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

P.S. мне до сих пор так и не понятно на фига такие сложности....

ну так 30 дней это же не месяц, или я чего то не понимаю?

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

Это смотря для кого, для меня, сидящего за тремя мониторами с толпой терминалов и intellij, не принципиально, а для генерального директора принципиально, конечно.
Как, например, объяснить автоплатежу сбербанка, что надо платить раз в 30 дней, а не раз в месяц определенного числа?

А директор почему хочет 15-15? Он же как то это мотивирует???
Так же как автоплатеж за квартиру с разными суммами каждый месяц...
Или автоплатеж по балансу за сотовый при балансе меньше заданого...