Faq registry active — различия между версиями

Текущая версия на 11:44, 21 декабря 2018

Актуальность связей в регистре

Проблема

В некоторых РГК столкнулись с большой проблемой в учёте, связанной с изменением учёта несколько лет назад. Выяснилось, что не смотря на то, что в регистре ПлощадкиПоДоговору указано ЕстьСвязь, связи может не быть фактически, или имеется несколько актуальных связей с различными характеристиками одновременно (например одна площадка может принадлежать одновременно нескольким потребителям). Такая ситуация не верна.

Подобное относится также к другим связям, например РегистрСведений.УзлыУчетаПлощадок, РегистрСведений.УстановленноеИзмерительноеОборудование (реквизит Установлено), но далее мы сосредоточимся на описании прежде всего на примере ПлощадкиПоДоговору как самого важного и характерного.

Если имеется возможность, мы настоятельно рекомендуем разорвать связь со старыми объектами! Обратите внимание, т.к. это регистры, то вся история сохраняется и будет доступна для просмотра и после этого. Данный же признак должен отвечать, по логике вещей, за текущую взаимосвязь объектов. Я общался по этому поводу с поддержкой Аудит НТ - получить внятного ответа почему такое имеет место быть не удалось. Кому интересно, привожу полный лог беседы. Если же будет принято решение не снимать со старых связь, то приведённый запрос не обязателен к исправлению, вместо этого будет использован описанный подход определения предпочтений, как воркараунд.

Применяемая эвристика

Рассматривается как воркараунд.

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

Для выборки текущей, актуальной записи анализируются следующие параметры:

1. Потребители помеченные удалёнными рассматриваются в последнюю очередь (Договор.ОсновнойДоговор.Владелец.ПометкаУдаления)
2. Приоритет по статусу, выбирается с наибольшим:
   1. «Не заключен» — 0
   2. «Завершен в плане поставок» — 0
   3. «Расторгнут» — 0
   4. «Исключен» — 0
   5. «Завершенный» — 1
   6. «Плановый» — 2
   7. «Предварительный» — 3
   8. «В стадии заключения» — 3
   9. Остальные — 10
3. Затем идет сортировка по дате окончания договора — предпочтение тем, у кого она больше.
4. По дате начала договора (например, если дата окончания не указана).
5. Период (применяется только для связи ТП с площадкой) - последняя по времени запись.

Используются всегда все признаки. Таким образом, расторгнутый договор будет проигнорирован, даже если дата окончания его больше, чем у действующего. Если есть 2 договора с одинаковым статусом (например, действующие основной и дополнительное соглашение, или ошибочно 2) — возьмется тот, у которого дата окончания больше. Если в этом случае даты окончания пустые или равны — тот, у которого дата начала больше.

  Реализовано простым упорядочиванием в запросах и выборкой последней строки

Для запросв 1С в общем виде просто добавляется УКАЗАНИЕ ПОРЯДКА ВЫБОРА:

ORDER BY
	obj // Основной выбираемый объект
	,CASE WHEN ISNULL(Основание.ДатаИзменения, DateTime(0001, 1, 1)) > &CurrentDate THEN 0 ELSE 1 END // CHANGE IN the future
	,CASE (Договор.СостояниеДоговора.Наименование)
		WHEN "Расторгнут" THEN 0
                WHEN "Исключен" THEN 0
		WHEN "Завершенный" THEN 1
		WHEN "Плановый" THEN 2
		WHEN "Предварительный" THEN 3
		WHEN "В стадии заключения" THEN 3
		ELSE 10
	END
	,Договор.ДатаКонца
	,Договор.ДатаНачала
	,Период

Будет взята последняя строка с данным объектом. Ошибка в отчёте по остальным возможным строкам не будет встречаться.