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

Версия 16:27, 14 января 2015

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

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

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

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

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

СР не могут быть изменены и никогда не обновляются 

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

СР никогда не удаляются 

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

Пример

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

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. Данные планы были загружены. В ИМУС создан СР₁ c атрибутами Д₁, ТП₁
3. Теперь предположим, что решили изменить планы. Обнаружили что была допущена ошибка и не проставлен договор закупки. Исправили указав Поставка₁, перепровели планы за 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

   А в ИМУС появится новый СР₂ с атрибутами Д₁, ТП₁, Поставка₁ и планами на 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>

Примечания

1. ↑ Для ускорения операции можно запрашивать планы по конкретному потребителю если он известен.
2. ↑ Можно совершенно по любому - просто это позволит передать минимальные изменения и выполнить операцию почти моментально