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

Сделали:

entiti:

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

census:

1. Добавили работу с разногласиями с привязкой к фотоархиву.
2. Добавили экспорт всех изображений из фотоархива с реестрами для юристов (обоснование всего ПО).
3. Добавили документы: акт недопуска, акты ограничения/возобновления.
4. Импорт из АСКУЭ byt теперь осуществляется не по заводскому номеру, а по коду ПУ в базе.

обе:

1. Добавили связь с АСКУЭ byt, для нерасчётных ПУ в АСКУЭ byt добавлена технологическая привязка. Участок редактирует адреса, причины почему не принят к расчёту и прочее. Удалили признак "УПУ".
2. Чётко определили распределение счётчиков АСКУЭ между:
 - pyr ("Репорт/Балансы"): ПУ по которым нужны профили мощности;
 - byt: ПУ по которым нужны только показания на конец суток;
 и привели обе системы в соответствие, изменив схемы баз и программы сбора.
3. Теперь в фотоархиве населённые пункты читаются из census, а потребители из entiti.
4. Документы ввод/замена/осмотр/проверка/уведомление/пломбы/безучётка сделали едиными.

Не решаемые проблемы:

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

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

census:

1. Дальнейшего развития КПУ, они уже сейчас очень сложные, нужна отдельная система балансировки. Возможно с ними сразу надо было работать отдельно.

entiti:

обе:

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

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

- добавить в АСКУЭ byt населённые пункты 
 {по аналогии с тех. привязкой}

- сделать отчёт: кол-во ПУ/абонентов/точек в населённых пунктах
 {как бы в entiti "заставить" всех проставить нас. пункт...}

- объединить справочник "марки ПУ"
 {сражаться с классом точности в entiti, добавить её в справочник, а затем построчно соединять}

- неизвестно что делать с буквами в марке ПУ, ток и напряжение и наличие интерфейсов тут никому не интересны, т.е. попытался сократить марки до класса точности и наличия тарификатора, но в entiti интересует можно ли включить в наше АСКУЭ установив СИМ-карту в счётчик (буква G у меркуриев = GSM-модем), или докупив только модем.
{может быть отдельный признак в таблицу "марки ПУ"? С объяснением когда выбирать именно эту марку... Или признак в таблицу ПУ? Добавить меркуриям "точку G"}

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

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

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

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

- пломбы (census, после объединения и entiti), сейчас можно только добавлять пломбу, но не менять предыдущую. Но добавление это не всегда "опломбировка", например это - исправление, перенос пломбы на автомате из поля "пломба на крышке" в поле "пломба на автомате"
  {дать возможность редактирования нельзя, например, испортятся заявки}

- фидер 0.4 нужно добавить в обе системы, рядом с опорой (для census Собинка просит её в обходной), возможно добавить номер фидера по 0.23

- норматив в census создан совсем не так как в entiti, а может быть они одинаковые? возможно ли слияние?

- Лёша: прикрутить схемы 6-10, типа фотоархива, поопорные вместе с обходными.
  {пока нет пользователей и ясного понимания, что и зачем, т.е. спецификации - нет смысла браться}

- сделать по всем полям TRIM, удалить сдвоенные пробелы, поменять редактор что бы не писали пробелы спереди и сзади
 {частично реализовано в entiti, возможно приведёт к перестроению кода изменяющего поля в census наподобие entiti}

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

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

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

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

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

- добавление/удаление в архив - нужно пересчитывать ПО, сделать расчёт на лету.

- (Ковров) мы занесли заранее уведомления, период перевели, и теперь они в предыдущем. Это про все документы.
  {может дать возможность удалять из предыдущих периодов, т.е. тут ясность базы важнее отчётных реестров?}

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

- в редакторах сделать переключалку на другие участки без ввода пароля (для ПО и управления)

- редакторы: документы/события: когда создаём документ и меняем ему дату на дату документа такого же типа получаем PK violation, исправить на "документ уже существует"

- Надя: создать систему учёта дисплеев (матрица, РиМ и т.д.)

- Ксю (и Вася с точки зрения РЭС), создать систему работы с заявками на откл/возобновление:
  - заявки приходит из сбыта факсом или т.п.
  - ПЭС вносит в эксель
  - ПЭС вносит в фотоархив
  - ПЭС рассылает уведомления на участок (excel), участки ходят в фотоархив
  - участок говори РЭСу
  - если РЭС выполняет - акт выполненных работ появл. в фотоархиве
  - если РЭС выполняет - ?
  - если сбыт отменяет - ?
проблемы: до участков заявки не доходят, участки/РЭС про них забывают, и контроль исполнения хромает.
Руководство: такая система не нужна, у диспетчеров есть система "Заявки", там вся работа.

- Фотоархив: некоторые документы рассылают в pdf на все участки ПЭС (МТС и т.п.) и все участки хотят их добавить себе, но так как в базу можно добавить только одно изображение (проверяется md5), то им приходится печатать/сканить.
{может быть сделать фотоархив для договоров не в базах участков, а может, ради экономии места, сделать ссылки на одно изображение из разных участков}

- В census отключённые абоненты это и ОТКЛ, и примечание, и акт отключения, в entiti это и примечание и "без нагрузки" и акт отключения. Нужно убрать лишние признаки и сделать единую систему.

- "АКУЭ полностью" - добавить ещё ошибок: разные ТП на одном концентраторе матрицы.

- фотоархив "экспорт", сделать нормальные периоды

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

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
++ Будущее: census
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

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

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

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

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

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

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

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

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

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

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

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

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

- (Петушки) создать историю "заметок по абоненту", где можно отмечать смену владельцу, изменение ФИО, свои примечания и т.д. и т.д.
  {говорят: не нужно, можно всегда позвонить в сбыт}

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

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

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

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

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

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

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

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

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

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

- добавить счётчику признак "через другой ПУ", это если у обоих договора со сбытом, но один питается через другого (один такой в Коврове, возможно в Суздале есть)
(может быть это транзит как в entiti, а может быть как раз не надо как в entiti, например: писать его как одну строку, ПО ставить нуль, и вид расчёта "учтён в расходе по другому ПУ")

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

- (Меленки) нулевые показания это тоже списания, а на 1-ку вместо 0-ля некоторые абоненты возмущаются
  {с трудом добились что в начальных показаниях теперь можно ставить 0, а в списаниях - нет, нужно менять расчётную часть}

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

- показывать в файле ПО безучётку по архивным ПУ

- что-то сделать с КПУ (огромная задача), т.к. проблемы:
 - у КПУ есть ПО в PKZ, но они не входят в ПО (в summ из pkz везде фильтры на них)
 - у КПУ есть списания, оплаты, разногласия и т.д., они входят в списания, но не входят в кол-во ТУ
 - замены по КПУ и перевод их в расчётные и обратно.

- (Катя В) добавить работу с замерами нагрузки, вывести замеры в обходной
 {видимо нужно действовать через документы/события}

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

- (Юля К) что бы в "неоплаченные больше года" попадали те у кого одинаковые начисления каждый месяц.

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

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

- (Лена К) для признака "ГБП" нужно отличать потребительские ТП от наших
  {уже добавлен признак "принадлежность ТП", пора менять логику подсчётов}

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

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

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

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

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

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

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

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

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

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

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

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

- в фильтр в редакторе добавить фильтрацию по коду энергосбыта (в файле оплат присылают код, и его никак не найти если ПУ в архиве)

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

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

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

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

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

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

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

- (Лена) отчёт кол-во замен по уведомлениям, туда нужно не только замены, но и "откл."
{забыл, это я уже сделал?}

- (Лена) отчёт кол-во замен по уведомлениям, по Коврову за сентябрь 2015 не совпал с файлом ПО (фильтр по колонке подкл + уведомления, в файле ПО - больше)

- (Вязники) добавить отчёт с нарастающим, ПО по улицам, точно такой же как "кол-во списаний, ТП, улицы"

- (Лена) итого по филиалу, списание с ручной корректировкой попадает в оплаты, нехорошо... Да и вообще ручная корректировка в отчёте не продумана.

- при импорте из АСКУЭ списаний по КПУ не пересчитывается расход по КПУ

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

- при изменении названия ТП в привязке оно не меняется в основном окне, что бы увидеть изменение приходится переходить на другого абонента.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
++ Будущее: entiti
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

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

- рейд по фидеру и т.п., среднее считается по ПУ, как в census, может быть надо считать по точке?

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

- (Киржач, дог. 363) контрольный ПУ ведём как транзит, возможно нужно что-то подумать про это

- (Киржач) на вкладку ПУ/ТТ/ТН добавить "дата последней проверки", "последняя пломба". Хотя может и не надо, оно есть на вводе показаний.

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

- (Катя, Лена К) ВЛ/КЛ, сделать выбор из двух, зачем оно редактируемое?

- акт снятия:
    добавить среднее потребление (Лена К)
    хотелось бы видеть трансформаторы (Вязники)
    добавить расход предыдущего месяца
    добавить сноску про АСКУЭ (Катя)
    добавить свидетелей (см. ОДПУ Ковров, Муром)

- (Камешки) акт снятия: разбивать потребителей при печати на зоны куда будут поездки (например, две машины в один день едут в две зоны, а потребитель - один)

- акт проверки: (Катя В, Муром) добавить массовую печать актов, и в excel нет печати чётных/нечтных, т.е. возможно печатать в pdf {в окне где выбираются потребители для акта снятия добавить для выбранных потребителей список всех точек, точки попадают помеченными, можно пометку снять, снизу "акты проверки для всех"}

- не бывает:
  - точка с потерями - это всегда не на ГБП
  - одинаковых пломб (перекрёстный с census)
  - одинаковых ПУ, марка и заводской (перекрёстный с census)
  - место установки находится на объекте потребителя И место установки находится на ГБП И граница находится на объекте РСК и т.п.

- точка "без ПУ" меняется на "с ПУ" => некуда внести начальные показания (но с дугой стороны, если "с ПУ" меняют на "без ПУ", а на самом деле ПУ не сломался и меняют назад через несколько периодов, - то сейчас всё будет красиво)
{а по уму - этим "без ПУ" нужна своя история, может как с КПУ, признак рядом с расчётными показаниями?}

- (Лена К) добавить в "баланс кратко" колонки: кол. юр, кол. физ., кол. ТП (Ира: не портите этот отчёт, сделайте другой)

- (Киржач) потребители с потерями зависящими от сезона (зима/лето), надоело забывать

- рядом с "история точки" сделать как в census - показать фотоархив

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

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

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

- копирование точки: сейчас по новой точке не видно актов проверки которые были для этого ПУ в старой точке (если их добавлять руками в новую - будут 2 одинаковых акта и не получится реестр), т.е. нужна история копирований. И к тому же по базе непонятно, из какого договора точка попала в этот договор.

- (Катя В) бывает, что заносим показание с акта снятия, а потом оказывается что в рапорте больше, вносим из рапорта, источник показания: "рапорт", а ПО пытается по этим показаниям сосчитать сколько было актов снятия и ругается что мы не ездим
{вероятно нужно разделить показания на списания и оплаты(рапорта) как в census} {возможно акт снятия должен быть "документом"}

- (Катя, Ира С) в ТТ добавить заводской номер и пломбу на 3-х фазной группе

- развитие кнопки "расход": в точку копировать потери от другой точки: дог. 902, 9711

- (Лена К) историю точки показывать в окне, что бы не ждать пока excel сообразит её открыть

- (Катя) добавить в точку помимо адреса ещё телефон, чтобы можно было связаться с тем, кто близок к этому ПУ - это ФАПы, отделения банков и почты и т.п.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
++ Другое
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

counter_auto: если возникает TNS error сбор останавливается

counter_oper: на вкладку СИКОН добавить выбор М-230 / СЭТ

counter_oper: говорят (Киржач: Солнечный берег) что для счётчика ПСЧ-4ТМ.05 не показывается журнал отключений напряжения по 3-й фазе