Программа ENTITI, функциональная спецификация. Спецификация не закончена. Смысл работы: Сменить идеологию базы: - сейчас это отчёт на текущий период и архив отчётов, изменить это на точки учёта с историей показаний; Упростить администрирование: - объединить базы данных(БД) и перенести на центральный сервер; - включить автоматическое обновление программ; Упростить поддержку: - упростить и уменьшить кодовою базу; - избавиться от закрытых и непереносимых "компонент"; Подготовится к дальнейшему развитию: - выявить криво работающие части, и составить план что с ними делать. Общий план: 1. Создать трансляторы для перевода текущих баз на сервер. (сделано) 2. Разработать новую схему базы и написать конвертор по переносу данных. 4. Создать новую программу отчётов для всех пользователей комплекса. 5. Создать программу редактирования базы для участков. 6. Исправить (список без учёта сложности/приоритета/порядка): =============== Смешалось в кучу: - работа со сбытом; - работа с балансировкой; - работа с балансировкой для МРСК. Нужна: база реальных показаний ПУ. Из которой получается: 1. Работа со сбытом. - подгонка в базе (заёмы); - удаление из excel потребителя "население"; - удаление из excel точек проходящих по другим "отчётам". 2. Работа с балансировкой. В базу добавляется: - население; - расходы по фидерам; - безучётка. 3. Работа с балансировкой для МРСК: - подгонка в базе для красоты. В будущем, вероятно, после объединения справочников "ПС - фидер -ТП" всех систем (хотя эту работу некому делать), следует отделить балансировку в отдельную систему, т.е. автомат будет выбирать "ПС - фидер": расход по фидеру из entiti, список юр. лиц из entiti, список физ лиц из census и т.д. и т.п. (расход по фидеру не из АСКУЭ, т.к. в entiti его можно вручную ввести и ещё 100 проблем) =============== Схема будет теперь такая: потребитель - точки - ПУ (не бывает точки без ПУ) Виртуальные ПУ помечены или как "норматив" и расход по нему или как "транзиты" (сейчас: отрицательными коэфф. трансформации) Разделение таблицы точки на две таблицы: точку и ПУ сделано что бы: 1. Добавить в базу замены. Т.е. в точке будут существовать заменённые и отключённые ПУ. 2. Место установки = это точка, т.е. с потерями, коэфф. трансформации, списком ТТ и прочим. ---- Транзиты, бывают двух видов: 1. ----- ПУ1 ------- сети абонента ------- ПУ2 ----- субабонент на договоре со сбытом т.е. в текущей системе он: абонент: ПУ1 абонент: -ПУ2 субабонент: ПУ2 при этом: для точки с отрицательным коэфф. трансф. не вводится номер ПУ2, что бы его небыло в таблице ПУ. Нет соответствия, какой -ПУ2 к какому ПУ2 относится. 2. Физ. лицо через юр. лицо в базе CENSUS он с плюсом, а тут - с минусом 3. пока не понял (такого не существует?) т.е. в текущей системе он: абонент: ПУ по СН2 абонент: -часть ПУ по СН2 абонент: +часть ПУ по НН при этом: нет соответствия между точками, заводской пишут только для "ПУ по СН2" Лёша: предложение: привязывать одну точку к потребителю/лям несколько раз, с разными коэффициентами и разными "видами расчёта ПО", например "Родомир": вид расчёта "только потери в кабеле". Непонятно как это реализовать (будут точки без потребителей? С нарастающими ужас: точку дабавили/убрали, уже ничего не видно (т.е. надо сразу историю создавать)?), поэтому: 1. соответствие и расход будет задоваться ссылкой транзита на его плюсовую составляющую. 2. во втором случае надо какой то признак плюсу (как он называется?) =============== Что изменим при переезде: Специальные потребители: "таксофоны" "население" "отпуск с шин" (новый) "балансы по ТП" (новый) эти 4-ре не отправляются в сбыт, применяются для создания балансировки (поступление в сети РЭС, отпуск из сетей РЭС) Как сделать балансировку: захреначить отдельным потребителем, т.е. фидер - это точка учёта у потребителя "отпуск с шин". плюсы: 1. Ко всем точкам учёта привязаны ПУ, т.е. автоматом будет работа с заменами, списаниями, расчётом расхода, ТТ и т.д. (сейчас в таблице ПУ forein key на таблицу точек) 2. У техника сейчас есть население, добавление нового специального потребителя не вызовет вопросов. 3. Не нужно создавать в редакторе окошки "тут ПУ на фидере", "тут ПУ у потребителя" (сейчас эти окошки есть). минусы: 1. Работа со сбытом и с балансами у техников чётко разделена (юр.лица таксофоны + население + фидера). 2. У точки масса полей не имеющих смысла для фидера РЭС (принадлежность, граница, потери в линии, привязка к ТП), а у фидера есть поле которого нет у точки (тех. потери в фидере рассчитанные РАП) 3. Во всех запросах к таблице ПУ и таблице точек придётся писать условие: если потребитель не население и не отпуск с шин (сейчас этот процесс называется "чистка файла для работы со сбытом", делается Ирой вручную). 4. Для потребителя "отпуск с шин" будет специальная таблица расчётных значений для помесячного отчёта небалансов в фидере (приём + отдача + % тех потерь из РАП + население из потребителя население), а для остальных - нет. 5. Эти спец. потребители будут мешаться в алгоритме расчёта расхода, например, по фидеру РЭС не бывает разногласий, безучётки. Потребителя подгоняют под сбыт, фидер и население нет... Альтернатива: выделить баланс по фидеру в отдельное понятие. Реализация: 1. Население, это отдельная таблица: список нас. пунктов, разбитых по ТП, и ещё одна таблица: период + расход. 2. Таже хрень по таксофонам(?), две таблицы. 3. В таблицу фидеров добавляем колонку "тех. потери из РАП" 4. Сейчас есть таблицы: sch, tt связаные с точкой. В них придётся добавить ещё одну колонку nullable forein key на таблицу фидеров и check: когда точка NULL тогда фидер NOT NULL При работе с таблицей pkz (расчётные значения)... Возможно в ней вообще для фидера ничего не писать. 5. И ещё будет таблица расчётных значений pkz_feeder (фидер - период - тех. потери РАП - отпуск - сумма по населению - сумма по юр. лицам) 6. Тогда сразу и pkz_tp нужно делать? Пример работы: 1. Работа со сбытом похожа на census (на экране таблицы: список потребителей, список точек, список ПУ для одной точки, это для редактирования карточек. И вторая вкладка: список потребителей, список ПУ для потребителя (в ней колонки: показания прошлого месяца, текущего и пр.), это для ввода показаний). 2. Редактируем население: на экране таблица: ПС - фидер - ТП - нас. пункт - расход авг. - расход сент.; и кнопка "добавить нас. пункт" 3. Редактируем список ПС, фидеров, ТП: как в census это отдельная операция в отдельном окошке "привязка". 4. Редактируем ПУ и вносим показания на фидерах: всё тоже самое что и в пункте 1, но, вместо потребителей - ПСии, вместо точек - список фидеров на ПС. Вместо карточки точки - карточка фидера. 5. Для подгонки под сбыт, МРСК и пр. есть две отдельных колонки (укажите показание и расход) 6. Сама подгонка: идём в итоговые отчёты, там всё считаем, идём опять в программу, правим, выгружаем итого, проверяем. Т.е. никаких красивостей по мере ввода... Развитие: 1. Редактируем ПУ и вносим показание на ТП: всё тоже самое что и в пункте 3, но, вместо фидеров - "фидер + ТП". Карточки ТП нету(?). 2. Хотим свой, особый небаланс, например между фидером и технический учётом в ТП. А никак его не сделать. 3. ??? PS: пля, окон в 2, а то и в 3 раза больше чем у деда Дима: от фидера РЭСу надо: расход, потери из РАП, транзиты ВКС неучтённые в его базах, недоучёт. Добавим в точку признак для "чистки", это те который в сбыт не отправлять. Все "ПУ" без заводского номера с положительным коэф. трансф. (может с нулевыми начальными показаниями в прошлом месяце?) окажутся с галочкой "норматив" и с расходом равным прошлому месяцу. Их надо будет проверить. Это что бы сразу стало ясно где ПУ реальные, где виртуальные. Так как ТП скачут между фидерами понадобится таблица "расчётные значения для пофидерного баланса". == Расчётные показания: помимо списания и расхода добавляем новое понятие "расчётное показание". В базе физ. лиц оно необходимо: 1. обеспечивает связь между показаниями ПУ и мешаниной алгоритма и другой работы (оплаты, статистики, корректировки) 2. что бы расчёт отталкивался только от предыдущего показания, не учитывая историю (работает не всегда, см. алгоритм: оплата не равна предыдущей, статистика) + независимость от алгоритма: неважно каким методом в предыдущие месяцы посчитался такой кривой расход. 3. Коррекции: неверные списани и т.п. навсегда остаются в базе, а мы скорректировав.... не видим почему ))) Добавим их в эту базу, получаем алгоритм: 1. == Акты безучётки сделаем простыми, как в CENSUS. Контрольные ПУ, вообще непонятно, пока думается их всех удалить и начать сначала. Отчёты: по одному ПУ: 1. История показаний по одному потребителю: 1. В будущем: история расходов по точкам. 2. Бланк акта снятия показаний, по потребителю. по участку: 1. Список точек и ПУ с показаниями на конец месяца для отправки в сбыт. 2. Баланс отпуска ээ за месяц (пофидерный баланс, т.е. фидера ПС, итого, фидера след. ПС, итого), в будущем: что бы суммы были за период. 3. Группировки по категориям (46-я форма и пр.) 4. Группировки по категориям помесячно, по квартально и т.д. (46-я форма и пр.) 4. В будущем: кол-во ТУ (квартальный отчёт) 5. В будущем: баланс по ТП по филиалу: 1. Полная база ПУ, все колонки. 2. нарастающий: расходы по всем потребителям помесячно. 3. нарастающий: расходы по всем точкам помесячно. =============== Будущее: - списаниям нужны даты - списаниям нужен контролёр - списания появились из рапорта или акта - списаниям нужен импорт из АСКУЭ - (Собинка) потери ХХ по отключенным не нужны - (Собинка) хотим хранить предписания Лёша: нужен справочник для потребителей: -До 15 кВт -От 15 до 60 кВт -От 60 до 150 кВт -От 150 до 670 кВт -От 670 кВт до 10 МВт -Более 10 МВт. Киржач: хотим норамльные переходы через нуль (сейчас дописываем в кон. показания с переди единицу, на след. месяц нужно не забыть её из начальных стереть) хотим сезонные потери мы называем транзиты контрольными ПУ ============================================================================ Пользователи, сценарии работы: Ира, Марина (08:22:41) бу будет вноситься, когда формируются балансы