Итоги работы с CENSUS за год (только техническая часть).

Сделали:

1. Создали и запустили в работу централизованную базу и программы.
2. Почистили базу и программы (размер уменьшился ~10 раз).
3. Упростили алгоритм и программы (примерно в ~100 раз).
4. Добавили работу с документами (реестр актов ввода/замены/проверок/уведомлений).
5. Создали программу позволяющую из одних отчётов делать другие (соединение таблиц, группировка).
6. Не существовало, и не существует, ни одного не однородного отчёта со списком ПУ, абонентов, улиц и т.д. (отчётов со строчкой "итого") Т.е. все отчёты можно быстро менять (все создаются единичным запросом к базе), все пригодны для дальнейшей автоматической обработки.

Появились не решаемые программно проблемы:

1. Отсутствует человек "менеджер программы", который должен весь день висеть на телефоне и составить:
  - спецификацию (описать пользователей и их задачи);
  - придумать решение каждой, обсудить со всеми и убедить всех что оно верное;
  - после добавления в программу убедиться, что все поняли что это и зачем;
  - через месяц поработать со всеми над ошибками, все ошибки это новые задачи о которых он сразу не сообразил.
  Например, очень тяжело идут задачи унификации: простейший реестр уведомлений делали/переделывали месяц, отчёт "количество средств учёта для квартального отчёта" за полгода смогли создать только для нескольких участков.
2. Отсутствует человек "администратор базы данных", непонятно что там с резервным копированием, аудитом, безопасностью, производительностью и прочим.
3. Отсутствует человек "администратор типов ПУ", невозможно создать справочник типов и окончательно решить вопросы наподобие "у такой марки ПУ не бывает такого класса точности"
4. Никто не знает что нам шлёт сбыт в файле оплат, хотелось бы увидеть хотя бы колонку "вид расчёта".
5. После добавления физ. лиц сервер начал тормозить, так как не хватает памяти что бы держать в ней базу целиком. (а для фотоархива - места на диске)
6. Каждый месяц танцы с бубном со связью с участками Камешково и Боголюбово. Обещают модернизацию в 2016 году.

"Никогда" не будет:

1. ПУ как железка, со своей историей, т.е. отслеживание за перемещением ПУ в ремонт и обратно, и между абонентами.
2. Пломба как объект, со своей историей, т.е. рождается, когда попадает к начальнику участка, умирает, когда её срывает абонент.
3. Дальнейшего развития КПУ, они уже сейчас очень сложные, нужна отдельная система балансировки. Возможно с ними сразу надо было работать отдельно.
4. Поддержка зон суток (день-ночь). Вообще не понятно, что с ней делать. Даже в АСКУЭ бытовых потребителей создать её полностью не удалось.
5. Как раньше в редакторе "импорта всего на свете": очень сложно создать, пример: импорт оплат.
5. Как раньше в редакторе "фильтров, как в excel": функциональность не поддерживается Qt.

==============

В будущем (задача {мысли про решение}):

=============================
============== Сложные задачи
=============================

- podkl, последний признак очищаемый в конце месяца, надоел.
  {продолжать работу по созданию истории ПУ, пока он не исчезнет}

- лицевые счёта у абонентов не уникальны на участке
  {решить что такое абонент, если это лицевой счёт, тогда объединить абонентов, сделать кнопки "объединить ЛС", "разделить ЛС", включить ограничение на уникальность в базе}

- категории, у каждого участка свои странные буквы
  {сделать единый справочник, перенумеровать, Д и НЖ и пр. в алгоритме и программе привязать к коду категории}

- категории, у них слишком много функций
  {это и комментарий, и работа с ОТКЛ и работа с НЖ, и расчёт статистики Д, т.е. нужно выделить каждую задачу отдельно. Собинка: так какая же категория у "стройка, превратится в неизвестно что"?}

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

- при добавлении и исправлении свойств абонентов и ПУ делается много ошибок
  {брать каждый признак, например:
  "балансовая принадлежность" - решить: ПУ без неё не бывает. Менять базу и программу.
  брать каждую пару, например:
  "год выпуска" - "год поверки" - решить: поверки раньше выпуска не бывает. Менять базу и программу.
  и так бесконечно, сотни комбинаций.
  }

- при выборе типа ПУ делаются ошибки, выбираются "похожие"
  {сделать окошко "выбор типа", там: слева поиск по названию и список типов, справа - галочки рядами, первый: класс точности, ставим галочку 0.5 - из списка исчезают типы у которых такого класса нету, и наоборот, выбираем тип - ставятся галочки, т.е. что бы было наглядно}

- пломбы на крышке: у одних это дата поверки, у других пломба на автомате, у третьих - пусто.
  {удалить? переименовать?}

- пломбы (Кольчугино): если пломбы уже висят, а мы вешаем ещё одну (например антимагнитную), то если в программу добавить только её


- опоры заносят из кучи мест, а в программе они только во "ввод показаний"
  {их бы в тех. привязку ещё. И фидер 0.4 нужно добавить в базу.}

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

- добавить дату с которой пошёл расчёт по нормативу
  {и многим другим полям. Подумать: это событие? Это про документ? Или это про расчёт?}

- реестр актов (возможно другие отчёты) на любой месяц любого года

- алгоритм: не брать оплату по старому ПУ при замене если техник ввёл списание (пример: Гусь 403410867), иначе приходится подключать старый ПУ в след. месяце и минусовать, (может быть так делать только для оплат без дат).
  {возможно лучше реорганизовать закрытие ПУ}

- про КПУ: нужно пройти по всем отчётам и решить по каждой выборке из базы, КПУ тут нужно или нет, например списание по КПУ сейчас списание, замена КПУ сейчас замена, а в "почти" всех остальных отчётах КПУ как бы не существует.
  {т.е. просмотреть, продумать и изменить все запросы к таблице ПУ, и составить внятную документацию почему тут так, а тут - иначе}

- файл ПО: вероятно лучше КПУ не дописывать к расчётному ПО справа, а сделать отдельными строчками

- алгоритм: что то сделать с оплатой по КПУ
  {а ещё потери при расходе по КПУ?}

- вновь установленные ПУ: показание из акта ввода - это тоже списание, а сейчас - когда как.
  {нужно превратить начальные показания в настоящие списания, возможно добавить признак в таблицу списаний}

- закрытые ПУ: сейчас для корректировки их подключают и закрывают списанием
  {возможно нужны признаки "подтверждённое списание" и пр.}

- функция "запретить редактирование всей базы для участка" работает плохо, лучше было бы "запретить редактирование полезного отпуска"
  {сейчас пользователя можно перевести в режим только чтение и назад, а так как в оракле(может через аудит это работает?) нет поддержки прав "только чтение" на отдельные колонки, то реализовывать надо программно}

- техник ждёт когда его переключат на след. период и хочет "ввод показаний по след. периоду"
  {придумать, как не запутаться в датах разных периодов}

- списание на 1-ое число на самом деле сделано не 1-ого числа, сделано в конце прошлого месяца, но в базу не вносилось что бы не путать сбыт.
  {разрешить во "ввод показаний" вносить дату из любого периода - плохо, сами запутаемся в ошибках...}

- техник хочет красивую таблицу со списком ПУ на улице для редактирования тех. привязки.

- функция для исправления базы "привязать все ПУ на улице к одной ТП" всем понравилась, возможно и для других характеристик абонента и ПУ нужно сделать возможность групповых изменений

- запутались замены: старый ПУ у одного абонента, новый у другово. Старый ПУ - подкл, новый - откл.
  {попробовать всё поправить выборками из базы. В редактор добавить кучу проверок. Пока не хочется т.к. лучше сначала уничтожить podkl, что бы это всё не переписывать}

- когда у одного абонента несколько ПУ, и были замены, невозможно разобраться что на что менялось
  {возможно ввести определение точки учёта, а может - просто как то группировать ПУ. Кстати, в историю ПУ нужно вывести информацию про замену.}

- Лёша: поопорную схему (хотя бы фото), держать вместе с обходным.

- Лёша: техприсоединения?

- Лёша: может быть абоненту нужен справочник состояний:
- Нормальный абонент
- Проблемный абонент (сюда неплательщиков сбыта, по кому присылают уведомления, наших проблемных, к кому не можем попасть)
- Заявка на отключение
- Договор расторгнут (проверить подключение)
- Демонтирован/отключён.
- Абонент заменён (сюда тех, кто уехал и продал дом другим).
- Бездоговорник (?)
  {это про те же категории абонентов, но другими словами... Вероятно, нам нужно начинать не со справочника, а с задач, каждую решать по одной, в конце концов мы придём к грамотному справочнику. Либо всё сразу досконально продумать.}

- улицы, так и остались "примечанием к абоненту", может быть сделать настоящие улицы

- сделать по всем полям TRIM, удалить сдвоенные пробелы, поменять редактор что бы не писали пробелы спереди и сзади

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

- переделать импорт из АСКУЭ (сделать без промежуточного файла excel), продумать как быть с округлениями до кВт

- когда при вводе показаний обрывается связь, показывается ошибка и программу надо перезапускать
  {сделать что бы вылезало окно "попробовать снова?" и в потоке для ввода показаний перезапускалась сессия к базе}

- привести колонки в базе (со свойствами) к одному виду и избавиться от -1 в колонке код нового ПУ и категория
  {решить как же лучше: во всей базе сделать NULL? Или "неизвестная улица"? Сейчас в свойствах ПУ в основном NULL, а в свойствах абонента в основном "неизвестный"}

- добавить счётчику признак "через другой ПУ", это если у обоих договора со сбытом, но один питается через другого (один такой в Коврове, возможно в Суздале есть)
  {НЕЛЬЗЯ делать как в юр. лицах, через костыль: в файле ПО писать такого абонента как две строки с плюсом и минусом. Нужно: писать его как одну строку, ПО ставить нуль, и вид расчёта "учтён в расходе по другому ПУ"}

- признак УПУ кандидат на (возможно частичный) перенос в таблицу "типы ПУ"

- (Гороховец) КПУ переводим в расчётный ПУ, но начальные показания по нему не те что нужно... (Сейчас делает "ручная корректировка")

- добавить работу с заявками на опломбировку

=============================
============== Задачи попроще
=============================

- (Камешково, и, видимо, только они озаботились этим) По уму, договор должен закрываться так: сбыт шлёт уведомление о расторжении, вместе с ним заявку на отключение. Заявка отдаётся в РЭС. Абонент убирается в архив. На деле уведомления шлют не всегда, заявки тоже как получится. Участок: мы хотим знать, выезжали мы(РЭС) к этим абонентам с закрытыми договорами или нет, было отключение на самом деле или нет.
  {возможное решение: ввести у отключенного ПУ (у закрытого ЛС) признак "не выезжали, проверить". Такой ПУ убирать из файла ПО, но в обходном его оставлять, вместо ЛС там писать "Договор расторгнут, проверить откл. ПУ"}
  
- добавить "вынос на ГБП без замены", это для произв. показателей
  {в историю событий ПУ}

- для признака "ГБП" нужно отличать потребительские ТП от наших
  {видимо добавить отдельный признак "принадлежность ТП"}

- в отчёте филиал-свод списания разбить на списания и списания по АСКУЭ

- после добавления замены техник не смотрит и на новый ПУ, и на старый ПУ
  {добавить всё про новый ПУ в окно замены, что бы нужно было вводить сразу,
   про старый ПУ - добавить монтёра}

- добавить среднее за год во "ввод показаний", оно хоть и напечатано в обходном, но иногда(когда?) неудобно

- (Аня) создать новый отчёт: "кол-во у кого не были 3 года, с разбивкой по РЭС, по месяцам"

- добавить генерацию бланков документов (возобновление, отключение и пр.)

- обходной: не печатать улицы без абонентов

- добавляем второй ПУ абоненту => не показывается новый заводской, нужно переходить к другому и назад

- перевести copy/paste в выпадающих меню на русский

- (Ю-П) что бы фамилии были всегда заглавными буквами
  {видимо при записи в базу конвертировать в верхний регистр}

- год выпуска в окне добавление абонента сделать по маске 20хх

- просмотреть все поля с датами в которых их можно стереть, что бы можно было написать 13, нажать enter и там появлялось 13.08.2015 (текущий период)
  {ещё просят сделать так что бы точки в дате не писать}

- нарастающий ТП + нас. пункты, в запросе выключен фильтр на нас. пункты где все абоненты в архиве (тормозит неизвестно почему)

- при удалении сотрудника проверять не только списания, но и все документы

- поменять вид расчёта "статистика" на более подробный:
  - из 2-х списаний
  - из 2-х оплат
  - из 1 списания и одной оплаты

- в фильтр в редакторе добавить фильтрацию по тех. привязке (например Судогда правила привязку у архивных абонентов, а их нет ни в одном отчёте)

- (Марина) перенести отчёт "количество ПУ", на вкладку филиал, что бы не собирать его из 20 файлов
  {например сделать 20 листов в excel - по участкам, и последний - по филиалу}

- после перемещения последнего ПУ у абонента в другого абонента, первый не исчезает из списка абонентов

- после перемещения ПУ из абонента в другого абонента, очищается список ПУ у старого абонента, хотя они есть (приходится переходить на другого и назад, что бы список обновился)

- у абонента один счётчик, он отключён, нажимаем "замена", добавляем ПУ => в карточке абонента он всё ещё в архиве, и на показания не переходит. Нужно ткнуть на другово абонента и обратно тогда всё становится красиво.

- просят добавить кол-во ПУ с классом точности 2.5 в отчёт по нас. пунктам.

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

- (Ю-П) Добавить в справочник ПУ колонку: "межповерочный интервал", всем однофазным - 16, всем остальным - 10, а потом будем её потихоньку выверять (или сразу запросом получить список несоответствий с текущей базой и думать что править)

- (Ю-П) была замена, внесли её, потом проверка и опломбировка => идём в ввод показаний, заносим списание новой датой, хотим внести пломбу, а там стоит дата замены, приходится исправлять.