Faq cc actuality

Материал из ANT-Inform documentation
Перейти к: навигация, поиск

Актуальность СР выставляется по планам и с версии 1.8 по датам последнего распределения.

Исторические СР

Появилось множество заявок следующего вида: "Договорной отдел не работал в начале января, и мы сводили баланс, делали распределение и актировали на одних СР, а теперь их изменили, но они не меняются в ИМУС. Как быть?"

СР это фактически набор атрибутов, на который имеются некоторые данные

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

СР не могут быть изменены и никогда не обновляются 
Если появится план на новый состав атрибутов СР (может варьироваться от опций), то в ИМУС появляется новый СР с этой даты.
СР никогда не удаляются 
СР меняет автоматически только дату актуальности и может быть скрыт если не имеет на себе больше полезных данных

Пример

Для примера возьмём упрощённую схему что план ведётся на ТП, Договор и Договор закупки. Используется последняя актуальная версия ПО.

  1. Есть некий потребитель с договором Д1, ТП1 и ему выделены некоторые планы потребления на январь:
    Договор ТП Договор закупки Дата План
    Д1 ТП1 2015.01.01 10
    Д1 ТП1 2015.01.02 11
    Д1 ТП1 2015.01.03 12
    Д1 ТП1 2015.01.04 13
  2. Данные планы были загружены. В ИМУС создан СР1 c атрибутами Д1, ТП1
  3. Теперь предположим, что решили изменить планы. Обнаружили что была допущена ошибка и не проставлен договор закупки. Исправили указав Поставка1, перепровели планы за 3 и 4 число (тот же эффект будет если перепровели всё, но загрузили в ИМУС план только за 3 и 4 число)
  4. В результате получим следующую картину:
    Договор ТП Договор закупки Дата План
    Д1 ТП1 2015.01.01 10
    Д1 ТП1 2015.01.02 11
    Д1 ТП1 Поставка1 2015.01.03 12
    Д1 ТП1 Поставка1 2015.01.04 13

    А в ИМУС появится новый СР2 с атрибутами Д1, ТП1, Поставка1 и планами на 3 и 4 января 2015 года.

    СР Дата имеющегося распределения Дата актуальности ПО Признак Скрыт Примечание
    При этом актуальность будет следующей
    1 - 2015.01.02 нет Распределения нет - по последней дате плана
    2 - 2015.01.04 нет Распределения нет - по последней дате плана
    1 2015.01.03 2015.01.03 нет Дата имеющегося распределения больше даты плана - используется она
    2 - 2015.01.04 нет
  5. Теперь предположим что исправили и перепровели планы за весь период
    Договор ТП Договор закупки Дата План
    Д1 ТП1 Поставка1 2015.01.01 10
    Д1 ТП1 Поставка1 2015.01.02 11
    Д1 ТП1 Поставка1 2015.01.03 12
    Д1 ТП1 Поставка1 2015.01.04 13
    Д1 ТП1 Поставка1 2015.01.05 14
    СР Дата имеющегося распределения Дата актуальности ПО Признак Скрыт Примечание
    Происходит следующее
    1 - 2015.01.02 да Плана не стало вовсе, распределения не было - скрыт
    2 - 2015.01.05 нет Продлён по 5 число, т.к. загружено больше планов
    1 2015.01.03 2015.01.03 нет Плана не стало, но имеется распределение на 3 января - оно становится датой действия (актуальности) СР

Как можно "убрать" некорректные

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

  1. Исправить и перепровести все планы в АИС (как минимум за период, который был загружен в ИМУС)
  2. Загрузить планы за весь период, на который они имеются в ИМУС по данному СР[1].
  3. Если ранее уже было сделано распределение на данный субъект - выполнить перераспределение, высвободив данный СР (чтобы он больше не использовался ни в часовом ни в суточном).
Если выполняются действия отличные от манипулирования планами (перераспределение) загрузить план всё же придётся хотя бы за один день, хотя бы по одному потребителю[2], поскольку пересчёт актуальности происходит именно во время выполнения данной операции

Удобный просмотр в БД дублей СР отличающихся только не заполненной Поставкой

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

SELECT
	cc1.cc_id AS old_cc_id
	,(SELECT MAX(date_for) FROM cc_daily_plan pln WHERE pln.cc_id = cc1.cc_id) AS old_max_plan_date
	,(SELECT MAX(corr_time) FROM contr_arc_exps_h h WHERE h.cc_id = cc1.cc_id) AS old_max_h_date
	,(SELECT MAX(corr_time) FROM contr_arc_exps_d d WHERE d.cc_id = cc1.cc_id) AS old_max_d_date
	,'|new>'
	,cc2.cc_id AS new_cc_id
	,cc2.pcontr_id AS new_pcontr_id
	,(SELECT MAX(date_for) FROM cc_daily_plan pln WHERE pln.cc_id = cc2.cc_id) AS new_max_plan_date
	,(SELECT MAX(corr_time) FROM contr_arc_exps_h h WHERE h.cc_id = cc2.cc_id) AS new_max_h_date
	,(SELECT MAX(corr_time) FROM contr_arc_exps_d d WHERE d.cc_id = cc2.cc_id) AS new_max_d_date
FROM
	contract_connection cc1
	JOIN contract_connection cc2 ON (
		cc1.contract_id = cc2.contract_id AND cc1.pc_id = cc2.pc_id AND COALESCE(cc1.pr_mark_id, -1) = COALESCE(cc2.pr_mark_id, -1) AND COALESCE(cc1.cons_type_id, -1) = COALESCE(cc2.cons_type_id, -1)
		AND cc1.pcontr_id IS NULL
		AND cc2.pcontr_id IS NOT NULL
	)
WHERE
	cc1.cc_id = <ID>
Результат должен быть понятен без описания:
old_cc_id old_max_plan_date old_max_h_date old_max_d_date new_cc_id new_pcontr_id new_max_plan_date new_max_h_date new_max_d_date
21887 <null> 2015-01-13 20:00:00.0 2015-01-12 00:00:00.0 new> 21366 24 2015-01-31 00:00:00.0 2015-01-14 08:00:00.0 2015-01-13 00:00:00.0

Примечания

  1. ↑ Для ускорения операции можно запрашивать планы по конкретному потребителю если он известен.
  2. ↑ Можно совершенно по любому - просто это позволит передать минимальные изменения и выполнить операцию почти моментально
Источник — «http://ais-site.dgtserv.ru/wiki_/index.php?title=Faq_cc_actuality&oldid=1222»