Привет, коллеги!

Я тоже работаю в энергетике. Для своего отдела сбыта написал простенькую программку по обсчёту частников. Могу поделиться, если это кому-нибудь нужно. Правда, писал на связке Линтер/ЛАБ - дабы побыстрее заткнуть проблемный участок. А теперь потихоньку перевожу всесь комплекс сбыта электоэнергии (отделы договорной/частники/промсектор) на ФБ/Дельфи, на полноценную КИС.

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

Самое первая колонка "Картины расчётов" - флаг расчитанных записей. То есть вся картина делится как бы на две части: нижняя часть, отмеченная галочками в первой колонке - расчитанные записи; верхняя часть - нерасчитанные записи (галочки не выставлены). Потребление расчитывается очень просто, как разница текущих и предыдущих показаний. Соответственно, как только появилась расчитанная запись, на основании расчитанного потребления вычисляется стоимость (общая/льготная и т.д.), определяется сумма к оплате и т.д. Как только в любую запись вносится какое-либо изменение (изменение/добавление/удаление записи), то данная запись и все последующие сбрасывают флаг "Запись расчитана". На печать выдаются только расчитанные записи, то есть показанная на картинке квитанция получается только на основании расчитанной записи о потреблении (в данном случае - от 29.06.2001).

Скриншот можно посмотреть вот тут: http://tpaktop040310.pochta.ru/kr2.jpg

На картинке последняя колонка, "Долг", показывает задолженность потребителя перед поставщиком красным цветом, а переплату ("предоплату") - черным. Обратите внимание, что самая верхняя строка потребления, с датой 28.07.2002, пока ещё не расчитана и поэтому в колонках Расход, Стоимость, Оплата, Долг нет никаких цифр и галочка в самой первой колонке не проставлена.

Такая структура данных позволила отказаться от избыточных записей типа "Месяц - Предыдущие показания - Текущие показания". Мной использована более простая и надёжная структура "Дата - Показания".

Таким образом, "Картина расчётов" показывает всю историю взаимоотношений потребителя и абонента (клиента) - установку и снятие Аппарата Учёта (счётчик/по среднему), назначение льгот, потребления и оплаты и т.д. Самое главное - в любой момент постояно можно видеть картину изменения долга потребителя, то есть легко вычисляется кто есть кто - "злостный" задолженник или честный плательщик.

Привет!

ZmeisheТы из какого Энерго? Я собираю такие где используют IB/FB. В нашем полку г. Владимир, г. Cаратов, вполне возможно г. Тамбов.
г. Петропавловск-Камчатский

Zmeishe авторПотребление расчитывается очень просто, как разница текущих и предыдущих показаний.
Тебе повезло, либо у тебя абоненты дисциплинированные как немцы и аккуратно указывают показания счётчика, либо твоё Энерго уже перешло на технологию выставления счетов, когда за абонента показания указывают обходчики.
У нас показания снимают контролеры, т.к. основная масса счётчиков находятся вне квартир, на лестничных площадках. Те потребители, у кого счётчик внутри квартиры, сами приносят показания. Периодически их проверяют контролеры.

ZmeisheА мои могут вообще никаких показаний не указывать, только сумму. Либо указывают, но мне пришлось создать такую математику, которая перед вставкой в таблицу анализирует какое из них начальное, а какое конечное.
Нужно просто приучить потребителей, что каждый месяц, с немецкой точностью :-) к ним в почтовый ящик падает квиток с расчетом - потребление, стоимость, оплачено за период, итого к оплате. И они наглядно видят, как с каждым месяцем у них в квитках накапливается/уменьшается долг. Так что у нас потребители могут платить любую сумму - хоть несколько раз в день приносить по 100 рублей, хоть один раз в год заплатить 10 тысяч, это непринципиально.

Я думаю, что такие проблемы, как у тебя надо решать не программными средствами, а организационными, т.е. выстраивать работу с абонентами по определённым правилам. Например, так: в договоре указывается, что если у потребителя квартирный счётчик, то ему назначается некое потребление по среднему. Если абонент не предоставил в отдел сбыта к определённому числу показания своего счётчика, то за этот период ему начисляется потребление, установленное по договору. То есть абонент может пол-года не появляться в отделе сбыта, а потребление ему всё равно начисляется. Нужно приучать к порядку! 8-)

Zmeishe"Крышу сносит неспеша"
В общем я пришёл к выводу, что такая сортировка похожа на обработку деревовидной структуры. Начальное показание это ID, конечное - ID_PARENT. Обработка "дырок", когда квитанция потеряна, это доп. условия.
Чем сложнее логика, тем больше вероятности появления хитрой ошибки. У меня всё гораздо проще, логика чисто линейная. Если по какой-либо причине пропущена запись потребления, то абонент не получит квитанцию с расчётом, а на следующий месяц ему придёт квитанция, в которой автоматически накопилось потребление уже за два месяца (Операторы делают круглые глаза и уверяют клиента, что он сам должен следить за сохранностью своего почтового ящика :) ).

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

Логика должна быть железная и только однонаправленная:

Очередные показания аппарата учёта => Вычисление потребления => Вычисление стоимости потреблённой энегрии => Отнять льготы/Добавить долги => Итого к оплате

Иначе это будет не производство, а бардак.