Разработка модуля обработки информации о договорах в системе продаж АО "Петер-Сервис"

12

Merge_contract_into

Процедура слияния выполнена успешно!

13

Move_account_to_contract

Ошибка выполнения процедуры! Лицевой счёт с идентификатором 13365 не был найден в системе!

14

Move_account_to_contract

Ошибка выполнения процедуры! Договор с идентификатором 7 не был найден в системе!

15

Move_account_to_contract

Процедура выполнена успешно! Лицевой счёт с идентификатором 13364 был перенесён на договор с идентификатором 4.

Тестирование части представления будет осуществляться unit-тестами.

Unit-тестирование позволяет проверить отдельные модули программы. При написании тестов идея состоит в проверке отдельных методов на корректность результата, что позволяет при изменении кода программы проверить наличие ошибок в уже оттестированных местах. Unit-тестирование будет являться первой преградой к появлению багов в программе, впоследствии уже будут использоваться интеграционные тесты и ручное тестирование. Однако данный подход будет эффективен не всегда. Для недолго живущих проектов, а также для веб-приложений с большим объёмом статики тесты помощи не принесут. Подход будет полезен для долго живущих и масштабных проектов, где после внесения изменений, будет требоваться регрессионное тестирование.

Помощь в запуске разработанных unit-тестов будет оказывать инструмент на node.js под названием Karma. Данный инструмент позволяет запускать JavaScript код сразу в нескольких браузерах. Запуск самих тестов осуществляется из консоли с помощью простой однострочной команды. Результат выполнения тестов будет выведен на экран, а также может быть сформирован отчёт, с процентным соотношением покрытия кода тестами. Также имеется возможность добавить задачу на запуск тестов для сборщика проекта. В случае провала, хотя бы одного теста, сборка проекта остановится, выдав на консоль информационное сообщение. Открыв информационный отчёт, содержащий процент покрытия тестами кода, можно просмотреть какие конкретно строки кода были покрыты, а какие всё ещё предстоят покрытию unit-тестами.

Выполним сборку с помощью команды grunt [12].

Сборщик проекта Grunt выполнил все задачи, заведённые в конфигурационном файле. Для нашего проекта данными задачами являются:

· проверка качества js кода с помощью jshint;

· проверка стилизации кода с помощью jscs;

· создание документации на основе jsdoc;

· запуск unit-тестов с помощью KarmaJS.

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

В сформированном отчёте можно увидеть все тесты, выполненные удачно/провалившиеся (рис. 5.1).

Здесь изображён заголовок сформированного html-отчёта с помощью KarmaJS. В нём отображена информация по браузеру, в котором выполнялись unit-тесты, дата и время запуска тестов. В дополнительной информации отображена следующая информация: количество выполнимых тестов/ количество тестов, выполнимых с ошибкой/количество тестов, в которых произошёл сбой/количество пропущенных тестов/ время выполнения тестов.

Рис. 5.1 - Заголовок сформированного отчёта

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

Рис. 5.2 - Успешно выполненные тесты для формы listContracts

Также имеется возможность получить полную статистику по проценту покрытия юнит-тестами всего проекта в целом. На рисунке ниже (рис. 5.3) отображён процент покрытия юнит-тестами для ангулар формы listContracts.



Рис. 5.3 - Процент покрытия тестами формы listContracts

В сформированной таблице можно увидеть следующий набор столбцов:

File - Название файла, для которого была сформирована статистика.

Statements - Процент покрытия всевозможных состояний, в которых может находится форма (кол-во покрытых тестами состояний/ всего возможных состояний).

Branches - Процент покрытия всевозможных разветвлений в алгоритмах работы формы(кол-во ветвей, покрытых юнит-тестами/всего возможных разветвлений алгоритмов).

Functions - Процент задействования функций в юнит-тестах(Покрытые юнит-тестами функции/ Всего функций файле).

Lines - Процент задействования линий с кодом на форме(Покрытые юнит-тестами строки кода/Всего строк кода).

Заключение

В рамках данной работы решены следующие задачи

1. Разработана и внедрена сущность «Договор» в систему SFA;

2. Разработаны механизмы работы с новой сущностью;

3. Доработан действующий механизм синхронизации данных между SFA и BIS;

4. Разработан алгоритм построения клиентской иерархии.

Работоспособность системы была подтверждена тестированием на всех этапах разработки. Взаимодействие продукта SFA с продуктом BIS было протестировано посредством интеграционных тестов и показало высокую устойчивость к различным ошибкам.

Таким образом, введение новой сущности Договор решает множество имеющихся проблем:

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

· во-вторых, продажи и обслуживание получили возможность работать с существенно меньшим количеством объектов. Множество, можно сказать россыпь лицевых счетов, была заменена их агрегатом - договором. Добавлен поиск, благодаря чему при обращении клиента можно будет легко найти все лицевые счета, принадлежащие этому договору;

· ввод договора позволил ввести массовые операции на лицевых счетах для нового уровня иерархии. Т.е. одновременно на всех лицевых счетах договора теперь можно изменять тарифный план, добавлять или удалять услуги, агрегировать начисления;

· наконец, благодаря введению договоров завершен процесс по переходу на полноценную клиентскую иерархию со множеством договоров и лицевых счетов. Это упрощает работу с системой в целом.

Список использованных источников

1. Проектная документация SFA [Электронный ресурс] - Режим доступа https://confluence.billing.ru, 2016, свободный - Загл. с экрана.

2. Иерузалимский Р. Программирование на языке lua [Текст] / пер. А. И. Боресков - 1-е изд. - М. : ДМК Пресс, 2014. - 382 с.

3. Закас Н. JavaScript .Оптимизация производительности. [Текст] / пер. А. Киселёв - М. : Символ-Плюс,2012. - 256 с.

4. Леффингуэлл, Д. Принципы работы с требованиями к программному обеспечению. Унифицированный подход. [Текст] : / Д. Леффингуэлл, Д. Уидриг - М. : Вильямс, 2002. - 448 с.

5. Хавербэк М. Выразительный JavaScript. [Текст] : / В. Голованов, 2011. - 438 с.

6. П. Козловский, П. Б. Дарвин Разработка веб-приложений с использованием AngularJS. [Текст] : пер. А. Киселёв- М. : ДМК Пресс, 2014. - 394 с.

7. Angular Documentation [Электронный ресурс] - Режим доступа: https://docs.angularjs.org/guide,2017, свободный - Загл. с экрана.

8. Конноли, Т. Базы данных. Проектирование, реализация и сопровождение. Теория и практика. [Текст] : / Т. Конноли, К. Бегг - М. : Вильямс, 2017. - 1440 с.

9. Фейерштейн, С. Oracle PL/SQL. Для профессионалов. [Текст] : / С. Фейерштейн, Б. Прибыл, пер. Е.А. Матвеев - 6-е изд. - М. : Питер, 2015. - 1020 с.

10. NodeJS Documentation [Электронный ресурс] - Режим доступа: https://nodejs.org/en/docs/ ,2017, свободный - Загл. с экрана.

11. GruntJS Documentation [Электронный ресурс] - Режим доступа: https://gruntjs.com/getting-started,2017, свободный - Загл. с экрана.

Приложение А

Алгоритм синхронизации данных

Приложение Б

Разработанное API для взаимодействия с БД

1. Процедура создания договора:

PROCEDURE create_contract(

Ip_cust_id IN NUMBER,

Ip_cntr_num IN VARCHAR2,

Ip_cntr_type_id IN NUMBER,

Ip_cntr_status_id IN NUMBER DEFAULT C_CNTR_STATUS_OPEN,

Ip_cntr_name IN VARCHAR2,

Ip_cntr_subj IN VARCHAR2,

Ip_segment_marke IN VARCHAR2,

Ip_segment_inner IN VARCHAR2,

Ip_sale_direction IN VARCHAR2,

Ip_fam_id IN NUMBER,

Ip_fsm_id IN NUMBER,

Ip_sign_date IN DATE,

Ip_expire_date IN DATE DEFAULT NULL,

Ip_navi_user IN VARCHAR2 DEFAULT NULL,

Op_cntr_id OUT NUMBER,

Op_double_cntr_id OUT NUMBER);

Описание входных параметров:

· ip_cust_id - уникальный идентификатор клиента, к которому будет привязан созданный договор;

· ip_cntr_num - номер договора;

· ip_cntr_type_id - уникальный идентификатор типа договора (берётся из справочника типов договоров) ;

· ip_cntr_status_id - уникальный идентификатор статуса договора (берётся из справочника статусов договоров), по умолчанию договор при создании всегда в статусе Действующий;

· ip_cntr_name - наименование договора;

· ip_cntr_subj - субъект договора;

· ip_segment_market - рыночный сегмент договора;

· ip_segment_inner - внутренний сегмент договора;

· ip_sale_direction - направление продаж договора;

· ip_fam_id - уникальный идентификатор федерального аккаунт-менеджера, ответственного за договор (берётся из таблицы операторов) ;

· ip_fsm_id - уникальный идентификатор федерального сервис-менеджера, ответственного за договор (берётся из таблицы операторов) ;

· ip_sign_date - дата создания договора;

· ip_expire_date - дата расторжения договора;

· ip_navi_user - оператор, создавший договор в системе.

Описание выходных параметров:

· op_cntr_id - уникальный идентификатор созданного договора;

· op_double_cntr_id - уникальный идентификатор найденного договора дубликата (совпадающий по ключевой атрибутике), означает ошибку, новый договор не был создан.

2. Процедура обновления договора

PROCEDURE update_contract(

Ip_cntr_id IN NUMBER,

Ip_mode IN VARCHAR2,

Ip_cntr_num IN VARCHAR2,

Ip_cntr_name IN VARCHAR2,

Ip_cntr_subj IN VARCHAR2,

Ip_segment_market IN VARCHAR2,

Ip_segment_inner IN VARCHAR2,

Ip_sale_direction IN VARCHAR2,

Ip_fam_id IN NUMBER,

Ip_fsm_id IN NUMBER,

Ip_sign_date IN DATE,

Ip_expire_date IN DATE DEFAULT NULL,

Ip_oper_id IN NUMBER,

Ip_navi_user IN VARCHAR2 DEFAULT NULL,

Op_cacnt_ids OUT t_varchar12,

Op_double_cntr_id OUT NUMBER);

Описание входных параметров:

· ip_cntr_id - уникальный идентификатор договора, обновление которого будет производится;

· ip_mode - режим обновления:

o 1 - на договор проливаются только не пустые значения;

o 2 - на договор проливаются все значения.

· ip_cntr_num - номер договора;

· ip_cntr_name - наименование договора;

· ip_cntr_subj - субъект договора;

· ip_segment_market - рыночный сегмент договора;

· ip_segment_inner - внутренний сегмент договора;

· ip_sale_direction - направление продаж договора;

· ip_fam_id - уникальный идентификатор федерального аккаунт-менеджера, ответственного за договор (берётся из таблицы операторов) ;

· ip_fsm_id - уникальный идентификатор федерального сервис-менеджера, ответственного за договор (берётся из таблицы операторов) ;

· ip_sign_date - дата создания договора;

· ip_expire_date -дата расторжения договора;

· ip_oper_id - уникальный идентификатор оператора системы SFA, выполняющего обновление;

· ip_navi_user - пользователь БД, под которым выполняется обновление;

Описание выходных параметров:

· op_cacnt_ids - уникальные идентификаторы лицевых счетов, принадлежащих договору, информацию по которым необходимо будет отправить в BIS на синхронизацию данных;

· op_double_cntr_id - уникальный идентификатор найденного договора дубликата (совпадающий по ключевой атрибутике), означает ошибку, обновление не было выполнено успешно.

3. Процедура получения договора:

PROCEDURE get_contract(

Ip_cntr_id IN NUMBER,

op_cntr_id OUT NUMBER,

op_cust_id OUT NUMBER,

op_cntr_num OUT VARCHAR2,

op_cntr_type_id OUT NUMBER,

op_cntr_type_name OUT VARCHAR2,

op_cntr_status_id OUT NUMBER,

op_cntr_name OUT VARCHAR2,

op_cntr_subj OUT VARCHAR2,

op_segment_market OUT VARCHAR2,

op_segment_inner OUT VARCHAR2,

op_sale_direction OUT VARCHAR2,

op_fam_id OUT NUMBER,

op_fsm_id OUT NUMBER,

op_sign_date OUT DATE,

op_expire_date OUT DATE,

op_start_date_utc OUT DATE,

op_end_date_utc OUT DATE,

op_faf OUT VARCHAR2);

Описание входных параметров:

· ip_cntr_id - уникальный идентификатор договора, информацию по которому необходимо получить;

Описание выходных параметров:

· op_cust_id - уникальный идентификатор клиента, к которому привязан договор;

· op_cntr_num - номер договора;

· op_cntr_type_id - уникальный идентификатор типа договора (берётся из справочника типов договоров) ;

· op_cntr_type_name - наименование типа договора (требуется для отображения на UI) ;

· op_cntr_status_id - уникальный идентификатор статуса договора (берётся из справочника статусов договоров) ;

· op_cntr_name - наименование договора;

· op_cntr_subj - субъект договора;

· op_segment_market - рыночный сегмент договора;

· op_segment_inner - внутренний сегмент договора;

· op_sale_direction - направление продаж договора;

· op_fam_id - уникальный идентификатор федерального аккаунт-менеджера, ответственного за договор (берётся из таблицы операторов) ;

· op_fsm_id - уникальный идентификатор федерального сервис-менеджера, ответственного за договор (берётся из таблицы операторов) ;

· op_sign_date - дата создания договора;

· op_expire_date - дата расторжения договора;

· op_start_date_utc - дата начала действия записи о договоре;

· op_end_date_utc - дата окончания действия записи о договоре;

· op_faf - признак Friend&Family на договоре;

4. Процедура получения списка договоров:

PROCEDURE get_contract_list(

Ip_cust_id IN NUMBER,

Ip_cntr_id_arr IN t_varchar12,

Ip_cntr_type_id_arr IN t_varchar12,

Ip_cntr_num IN VARCHAR2 DEFAULT NULL,

Ip_cntr_status_id_arr IN t_varchar12,

Ip_cntr_name IN VARCHAR2 DEFAULT NULL,

Ip_segment_market_kn_arr IN t_varchar32,

Ip_segment_inner_kn_arr IN t_varchar32,

Ip_sale_direction_kn_arr IN t_varchar32,

Ip_fam_id_arr IN t_varchar12,

Ip_fsm_id_arr IN t_varchar12,

Ip_sign_date_beg IN DATE DEFAULT NULL,

Ip_sign_date_end IN DATE DEFAULT NULL,

Ip_expire_date_beg IN DATE DEFAULT NULL,

Ip_expire_date_end IN DATE DEFAULT NULL,

Ip_faf IN NUMBER DEFAULT NULL,

Ip_offset IN NUMBER DEFAULT NULL,

Ip_limit IN NUMBER DEFAULT NULL,

Ip_col_order IN VARCHAR2,

op_cntr_id_arr OUT t_varchar12,

op_cust_id_arr OUT t_varchar12,

op_cntr_num_arr OUT t_varchar256,

op_cntr_type_id_arr OUT t_varchar12,

op_cntr_type_name_arr OUT t_varchar12,

op_cntr_status_id_arr OUT t_varchar12,

op_cntr_status_name_arr OUT t_varchar256,

op_cntr_name_arr OUT t_varchar256,

op_cntr_subj_arr OUT t_varchar512,

op_segment_market_arr OUT t_varchar128,

op_segment_inner_arr OUT t_varchar128,

op_sale_direction_arr OUT t_varchar128,

op_segment_market_kn_arr OUT t_varchar128,

op_segment_inner_kn_arr OUT t_varchar128,

op_sale_direction_kn_arr OUT t_varchar128,

op_fam_id_arr OUT t_varchar12,

op_fsm_id_arr OUT t_varchar12,

op_sign_date_arr OUT date_array,

op_expire_date_arr OUT date_array,

op_start_date_utc_arr OUT date_array,

op_end_date_utc_arr OUT date_array,

op_faf OUT byte_array);

Описание входных параметров:

Входные параметры представляют из себя атрибуты договора, по которым необходимо произвести фильтрацию при необходимости, в дополнение к ним имеется три дополнительных параметра:

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

· ip_limit - ограничение на количество возвращаемых записей (требуется для порционности данных при оформлении постраничного вывода) ;

· ip_col_order - название столбца, по которому необходимо произвести сортировку выводимых данных.

Описание выходных параметров:

Список выходных параметров аналогичен процедуре получения одного договора, отличие заключается в том, что выходные данные представляют из себя массивы значений.

5. Процедура получения списка статусов договоров:

PROCEDURE get_contract_status_list(

op_id OUT t_varchar10,

op_key_name OUT t_varchar32,

op_name OUT t_varchar256);

Описание параметров:

· Op_id - уникальный идентификатор статуса договора;

· Op_key_name - кейнейм статуса договора;

· Op_name - наименование статуса договора.

6. Процедура получения списка типов договоров:

PROCEDURE get_contract_type_list(

Ip_mode IN NUMBER DEAULT NULL,

op_id OUT t_varchar10,

op_key_name OUT t_varchar32,

op_name OUT t_varchar256);

Описание входных параметров:

· ip_mode - режим работы процедуры:

o 1 - получить типы договоров, без учёта GF (Требуется для филиалов, ещё не участвующих в проекте GreenField) ;

o 0/NULL - получить все типы договоров.

Описание выходных параметров:

· op_id - массив уникальных идентификаторов типа договора;

· op_key_name - массив кейнеймов типа договора;

· op_name - массив наименований типа договора.

7. Процедура получения идентификатора типа договора, по его кейнейму:

PROCEDURE get_contract_type_by_kn(

Ip_key_name IN VARCHAR2,

op_id OUT NUMBER);

Описание входных параметров:

· ip_key_name - кейнейм искомого типа договора;

Описание выходных параметров:

· op_id - уникальный идентификатор найденного типа договора;

8. Процедура переноса лицевого счёта с одного договора на другой:

PROCEDURE move_account_to_contract(

Ip_cacnt_id IN NUMBER,

Ip_cntr_id IN NUMBER,

Ip_oper_id IN NUMBER);

Описание параметров:

· ip_cacnt_id - уникальный идентификатор переносимого лицевого счёта;

· ip_cntr_id - уникальный идентификатор договора, на который будет осуществлён перенос лицевого счёта;

· ip_oper_id - уникальный идентификатор оператора SFA, который выполняет перенос.

9. Процедура закрытия договора:

PROCEDURE close_contract(Ip_cntr_id IN NUMBER);

Параметры процедуры:

· ip_cntr_id - уникальный идентификатор договора, который необходимо закрыть.

10. Процедура объединения договоров:

PROCEDURE merge_contract_into(

Ip_cntr_id IN NUMBER,

Ip_into_cntr_id IN NUMBER,

Ip_oper_id IN NUMBER);

Параметры процедуры:

· ip_cntr_id - уникальный идентификатор первого договора, участвующего в объединении;

· ip_into_cntr_id - уникальный идентификатор второго договора, участвующего в объединении;

· ip_oper_id - уникальный идентификатор оператора, выполняющего объединение.

11. Процедура проверки возможности редактирования договора:

PROCEDURE check_contract_edit(

Ip_cntr_id IN NUMBER,

Ip_cntr_num IN VARCHAR2,

Ip_segment_market IN VARCHAR2,

Ip_segment_inner IN VARCHAR2,

Ip_sale_direction IN VARCHAR2,

Ip_fam_id IN NUMBER,

Ip_fsm_id IN NUMBER,

Op_res OUT NUMBER,

Op_res_msg OUT VARCHAR2,

Op_potentional_action OUT VARCHAR2,

Op_join_cntr_id OUT NUMBER,

Op_consume_cntr_id OUT NUMBER);

Описание входных параметров:

· ip_cntr_id - уникальный идентификатор проверяемого договора;

· ip_cntr_num - номер договора;

· ip_segment_market -рыночный сегмент договора;

· ip_segment_inner - внутренний сегмент договора;

· ip_sale_direction - направление продаж договора ;

· op_fam_id - уникальный идентификатор федерального аккаунт-менеджера, ответственного за договор (берётся из таблицы операторов) ;

· op_fsm_id - уникальный идентификатор федерального сервис-менеджера, ответственного за договор (берётся из таблицы операторов) ;

Описание выходных параметров:

· op_res - результат выполнения процедуры:

o 1 - можно выполнить редактирование договора;

o 0 - редактирование договора выполнить нельзя.

· op_res_msg - вспомогательное сообщение, сопутствующее результату;

· op_potentional_action - возможные альтернативные действия для изменения договора:

o JOIN - возможно присоединение к другому договору;

o EDIT_AND_CONSUME - возможно сохранение и поглощение другого договора.

· op_join_cntr_id - уникальный идентификатор договора, к которому возможно присоединение;

· op_consume_cntr_id - уникальный идентификатор договора, поглощение которого возможно.

Приложение В

Тестовые наборы данных

Тестовый набор данных №1.

Ip_cust_id = 1

Ip_cntr_num = CNR-721658

Ip_cntr_type_id = 10

Ip_cntr_status_id = 1

Ip_cntr_name = NULL

Ip_cntr_subj = NULL

Ip_segment_market = B2B_SBO

Ip_segment_inner = B2B_SCN

Ip_sale_direction = DIRECT

Ip_fam_id = 101

Ip_fsm_id = 64

Ip_sign_date = 21.06.2016

Тестовый набор данных №2.

Ip_cust_id = 1

Ip_cntr_num = CNR-721658

Ip_cntr_type_id = 1

Ip_cntr_status_id = 1

Ip_cntr_name = NULL

Ip_cntr_subj = NULL

Ip_segment_market = B2B_SBO

Ip_segment_inner = B2B_

Ip_sale_direction = DIRECT

Ip_fam_id = 1000000001

Ip_fsm_id = 64

Ip_sign_date = 21.06.2016

Тестовый набор данных №3.

Ip_cust_id = 1

Ip_cntr_num = CNR-721658

Ip_cntr_type_id = 1

Ip_cntr_status_id = 1

Ip_cntr_name = NULL

Ip_cntr_subj = NULL

Ip_segment_market = B2B_SBO

Ip_segment_inner = B2B_

Ip_sale_direction = DIRECT

Ip_fam_id = 101

Ip_fsm_id = 64

Ip_sign_date = 21.06.2016

Тестовый набор данных №4.

Ip_cntr_id = 2

Ip_mode = 1

Ip_cntr_num = CDT-211658

Тестовый набор данных №5.

Ip_cntr_id = 1

Ip_mode = 1

Ip_cntr_num = CDT-211658

Тестовый набор данных №6.

Ip_key_name = TEST

Тестовый набор данных №7.

Ip_key_name = GF

Тестовый набор данных №8.

Ip_cntr_id = 2

Тестовый набор данных №9.

Ip_cntr_id = 1

Тестовый набор данных №10.

Ip_cntr_id = 5

Ip_into_cntr_id=6

Ip_oper_id=64

Тестовый набор данных №11.

Ip_cntr_id = 2

Ip_into_cntr_id = 6

Ip_oper_id=64

Тестовый набор данных №12.

Ip_cntr_id = 1

Ip_into_cntr_id = 3

Ip_oper_id=64

Тестовый набор данных №13.

Ip_cacnt_id = 13365

Ip_cntr_id =7

Ip_oper_id=64

Тестовый набор данных №14.

Ip_cacnt_id = 13364

Ip_cntr_id =7

Ip_oper_id=6

Тестовый набор данных №15.

Ip_cacnt_id = 13364

Ip_cntr_id =4

Ip_oper_id=64

Приложение Г

Исходный код пакета SFA_CONTRACT_PG

create or replace package body sfa_contract_pg IS

--

---@ SFA_BASE

----- Базовая функциональность системы автоматизации процесса продаж

------ 006.00

--

-- Copyright (c) 2011-2017 CJSC PETER-SERVICE.

--

---------------------------------------------------------------------------

-- Функция создания договора

-- %author Gennady.Savinov 19.04.2017

-- %param ip_cntr_num - номер договора

-- %param ip_cntr_name - имя договора

-- %param ip_cntr_subj - тема договора

-- %param ip_segment_market - Рыночный сегмент

-- %param ip_segment_inner - Внутренний сегмент

-- %param ip_sale_direction - Направление продаж

-- %param ip_fam_id - ФАМ

-- %param ip_fsm_id - ФСМ

-- %param ip_sign_date - дата подписания

-- %param ip_expire_date - дата истечения договора

-- %param ip_navi_user - имя пользователя изменившего договор

-- %param op_cntr_id - ид созданного договора

-- %param op_double_cntr_id - ид найденного дубля договора

---------------------------------------------------------------------------

PROCEDURE create_contract

(

ip_cust_id IN NUMBER,

ip_cntr_num IN VARCHAR2,

ip_cntr_type_id IN NUMBER,

ip_cntr_status_id IN NUMBER DEFAULT C_CNTR_STATUS_OPEN,

ip_cntr_name IN VARCHAR2,

ip_cntr_subj IN VARCHAR2,

ip_segment_market IN VARCHAR2,

ip_segment_inner IN VARCHAR2,

ip_sale_direction IN VARCHAR2,

ip_fam_id IN NUMBER,

ip_fsm_id IN NUMBER,

ip_sign_date IN DATE,

ip_expire_date IN DATE DEFAULT NULL,

ip_navi_user IN VARCHAR DEFAULT NULL,

op_cntr_id OUT NUMBER,

op_double_cntr_id OUT NUMBER

) IS

lv_navi_user sfa_contracts.navi_user%TYPE := nvl(ip_navi_user, utl_pack.get_user_name);

lv_cur_date DATE;

lv_check_res t_contract_check_rec;

BEGIN

check_contract_new_atr(ip_exclude_cntr_id => NULL,

ip_cust_id => ip_cust_id,

ip_cntr_num => ip_cntr_num,

ip_cntr_type_id => ip_cntr_type_id,

ip_segment_market => ip_segment_market,

ip_segment_inner => ip_segment_inner,

ip_sale_direction => ip_sale_direction,

ip_fam_id => ip_fam_id,

ip_fsm_id => ip_fsm_id,

op_res => lv_check_res);

IF lv_check_res.is_error THEN

op_double_cntr_id := lv_check_res.double_cntr_id;

return;

--raise_application_error(-20001, lv_check_res.error_msg);

END IF;

INSERT INTO sfa_contracts

(cntr_id, out_cust_id, cntr_num, cntr_type_id, cntr_status_id, cntr_name, cntr_subj, segment_market,

segment_inner, sale_direction, fam_id, fsm_id, sign_date, expire_date, navi_user)

VALUES (SFA_CNTR_SEQ.NEXTVAL, ip_cust_id, ip_cntr_num, ip_cntr_type_id, ip_cntr_status_id, ip_cntr_name, ip_cntr_subj, ip_segment_market,

ip_segment_inner, ip_sale_direction, ip_fam_id, ip_fsm_id, ip_sign_date, ip_expire_date, lv_navi_user)

RETURNING cntr_id, start_date_utc INTO op_cntr_id, lv_cur_date;

make_contract_hist_rec(ip_cntr_id => op_cntr_id, ip_cur_date=> lv_cur_date);

EXCEPTION WHEN OTHERS THEN

raise_application_error(-20000, dbms_utility.format_error_stack || dbms_utility.format_error_backtrace);

END create_contract;

--

---------------------------------------------------------------------------

-- Функция изменения договора (Обновляться будут только явно переданные поля)

-- %author Gennady.Savinov 19.04.2017

-- %param ip_cntr_id - идентификатор договора

-- %param ip_mode - (!!! параметр не используется) режим изменения договора

-- 1 - на договор проливаются только не пустые значения

-- 2 - на договор проливаются все значения

-- %param ip_cntr_num - номер договора

-- %param ip_cntr_name - имя договора

-- %param ip_cntr_subj - тема договора

-- %param ip_segment_market - Рыночный сегмент

-- %param ip_segment_inner - Внутренний сегмент

-- %param ip_sale_direction - Направление продаж

-- %param ip_fam_id - ФАМ

-- %param ip_fsm_id - ФСМ

-- %param ip_sign_date - дата подписания

-- %param ip_expire_date - дата истечения договора

-- %param ip_oper_id - оператор CMS внесший изменения

-- %param ip_navi_user - имя пользователя изменившего договор

-- %param op_cacnt_ids - список ЛС, которые необходимо синхронизировать в БИС

-- %param op_double_cntr_id - идентификатор найденного дубля договора (обновление невозможно)

--------------------------------------------------------------------------

PROCEDURE update_contract

(

ip_cntr_id IN NUMBER,

ip_mode IN VARCHAR2 DEFAULT NULL, -- Неиспользуемое поле, оставлено для обратной совместимости

ip_cntr_num IN VARCHAR2 DEFAULT sfa_common.GET_STRING_FAKE(),

ip_cntr_name IN VARCHAR2 DEFAULT sfa_common.GET_STRING_FAKE(),

ip_cntr_subj IN VARCHAR2 DEFAULT sfa_common.GET_STRING_FAKE(),

ip_segment_market IN VARCHAR2 DEFAULT sfa_common.GET_STRING_FAKE(),

ip_segment_inner IN VARCHAR2 DEFAULT sfa_common.GET_STRING_FAKE(),

ip_sale_direction IN VARCHAR2 DEFAULT sfa_common.GET_STRING_FAKE(),

ip_fam_id IN NUMBER DEFAULT sfa_common.GET_NUMBER_FAKE(),

ip_fsm_id IN NUMBER DEFAULT sfa_common.GET_NUMBER_FAKE(),

ip_sign_date IN DATE DEFAULT sfa_common.GET_DATE_FAKE(),

ip_expire_date IN DATE DEFAULT sfa_common.GET_DATE_FAKE(),

ip_oper_id IN NUMBER,

ip_navi_user IN VARCHAR DEFAULT NULL,

op_cacnt_ids OUT t_varchar12,

op_double_cntr_id OUT NUMBER

) IS

lv_navi_user sfa_contracts.navi_user%TYPE := nvl(ip_navi_user, utl_pack.get_user_name);

lv_sys_utc_dat DATE;

lv_atr_kname sfa_acnt_common_pg.tp_name_array;

lv_atr_value sfa_acnt_common_pg.tp_string_array;

lv_caatr_ids sfa_acnt_common_pg.tp_id_array;

lv_check_res t_contract_check_rec;

lv_contract sfa_contracts%ROWTYPE;

lv_cntr_num VARCHAR2(256);

lv_segment_market VARCHAR2(512);

lv_segment_inner VARCHAR2(512);

lv_sale_direction VARCHAR2(512);

lv_fam_id NUMBER;

lv_fsm_id NUMBER;

lv_cntr_name VARCHAR2(2000);

lv_cntr_subj VARCHAR2(2000);

lv_sign_date DATE;

lv_expire_date DATE;

BEGIN

BEGIN

-- Определяем все поля обновляемой записи

SELECT * INTO lv_contract FROM sfa_contracts WHERE cntr_id = ip_cntr_id FOR UPDATE;

EXCEPTION WHEN no_data_found THEN

raise_application_error(-20001, sfa_common.get_msg(407, ip_cntr_id));

END;

lv_sys_utc_dat := sys_utc_dat;

UPDATE sfa_contracts

SET cntr_num = lv_cntr_num

, cntr_name = lv_cntr_name

, cntr_subj = lv_cntr_subj

, segment_market = lv_segment_market

, segment_inner = lv_segment_inner

, sale_direction = lv_sale_direction

, fam_id = lv_fam_id

, fsm_id = lv_fsm_id

, sign_date = lv_sign_date

, expire_date = lv_expire_date

, navi_user = lv_navi_user

, navi_date = lv_sys_utc_dat

--, start_date_utc = lv_sys_utc_dat

--, end_date_utc = C_INFINITY_DATE

WHERE cntr_id = ip_cntr_id;

make_contract_hist_rec(ip_cntr_id => ip_cntr_id, ip_cur_date=> lv_sys_utc_dat);

FOR x IN (SELECT ca.cacnt_id, rownum

FROM sfa_cust_acnt ca

WHERE ca.cntr_cntr_id = ip_cntr_id

AND sys_extract_utc(systimestamp) BETWEEN ca.start_date_utc AND ca.end_date_utc

)

LOOP

sfa_acnt_common_pg.update_link_attrs_set

( ip_cacnt_id => x.cacnt_id

, ip_oper_id => ip_oper_id

, ip_attr_kname_arr => lv_atr_kname

, ip_value_arr => lv_atr_value

, op_caatr_ids => lv_caatr_ids

);

op_cacnt_ids(x.rownum) := x.cacnt_id;

END LOOP;

EXCEPTION WHEN OTHERS THEN

raise_application_error(-20000, 'Error update contract '||ip_cntr_id||' '||dbms_utility.format_error_stack || dbms_utility.format_error_backtrace);

END update_contract;

--

---------------------------------------------------------------------------

-- Функция закрытия договора

-- %author Gennady.Savinov 19.04.2017

-- %param ip_cntr_id - идентификатор договора

---------------------------------------------------------------------------

PROCEDURE close_contract

(

ip_cntr_id NUMBER

)

IS

lv_cnt NUMBER;

lv_end_date DATE := sys_extract_utc(systimestamp);

BEGIN

SELECT COUNT(*)

INTO lv_cnt

FROM sfa_cust_acnt ca

WHERE ca.cntr_cntr_id = ip_cntr_id

AND sys_extract_utc(systimestamp) BETWEEN ca.start_date_utc AND ca.end_date_utc;

IF lv_cnt > 0 THEN

raise_application_error(-20001, sfa_common.get_msg(401));

END IF;

UPDATE sfa_contracts

SET cntr_status_id = C_CNTR_STATUS_CLOSE

, end_date_utc = lv_end_date

WHERE cntr_id = ip_cntr_id;

make_contract_hist_rec(ip_cntr_id => ip_cntr_id, ip_cur_date=> lv_end_date);

EXCEPTION WHEN OTHERS THEN

raise_application_error(-20000, 'Error close contract '||ip_cntr_id||' '||dbms_utility.format_error_stack || dbms_utility.format_error_backtrace);

END;

--

---------------------------------------------------------------------------

-- Функция переноса ЛС с одного изменения договора и объединения его с другим договором, после изменения

-- %author Gennady.Savinov 19.04.2017

---------------------------------------------------------------------------

PROCEDURE move_acount_to_contract

(

ip_cacnt_id IN NUMBER,

ip_cntr_id IN NUMBER,

ip_oper_id IN NUMBER

) IS

BEGIN

move_acount

( ip_cacnt_id => ip_cacnt_id

, ip_new_cntr_id=> ip_cntr_id

, ip_oper_id => ip_oper_id

);

END;

--

---------------------------------------------------------------------------

-- Функция объединения договоров

-- %author Gennady.Savinov 19.04.2017

---------------------------------------------------------------------------

PROCEDURE merge_contract_into

(

ip_cntr_id IN NUMBER,

ip_into_cntr_id IN NUMBER,

ip_oper_id IN NUMBER

)

IS

lv_into_cntr t_cntr_info_rec;

lv_acnt t_acnt_info_rec;

lv_join_cntr_sale_id NUMBER;

lv_cacnt_ids t_number;

lv_sys_utc DATE := sys_utc_dat;

BEGIN

--get_contract_active_sale

--( ip_cntr_id => ip_join_cntr_id,

-- op_sale_id => lv_join_cntr_sale_id

--);

--IF lv_join_cntr_sale_id IS NOT NULL THEN

-- raise_application_error(-20001, sfa_common.get_msg(402));

--END IF;

BEGIN

get_cntr_info(ip_cntr_id=>ip_into_cntr_id, op_cntr => lv_into_cntr);

EXCEPTION WHEN no_data_found THEN

raise_application_error(-20001, 'Contract "'||ip_cntr_id||'" for into merging not found.');

END;

-- перенос всех лицевых счетов(в том числе закрытых) на новый договор

FOR x IN (SELECT *

FROM sfa_cust_acnt ac

WHERE ac.cntr_cntr_id = ip_cntr_id

AND ac.pik IS NULL --ПИК перенесутся автоматом вследа за основным ЛС

)

LOOP

lv_acnt := convert_to_acnt_info(x);

move_acount

(ip_cacnt_id =>x.cacnt_id

,ip_new_cntr_id =>ip_into_cntr_id

,ip_new_cust_id =>NULL

,ip_oper_id =>ip_oper_id

,ip_acnt_info =>lv_acnt

,ip_cntr_info =>lv_into_cntr

);

END LOOP;

close_contract(ip_cntr_id);

END;

--

---------------------------------------------------------------------------

-- Получения списка статусов договоров

-- %author Gennady.Savinov 19.04.2017

---------------------------------------------------------------------------

PROCEDURE get_contract_status_list

(

op_id OUT t_varchar10,

op_key_name OUT t_varchar32,

op_name OUT t_varchar256

) IS

BEGIN

SELECT id, key_name, name

BULK COLLECT INTO op_id, op_key_name, op_name

FROM sfa_contract_status

WHERE rownum <=100; --защита от слижком большого кол-ва записей

END;

--

-----------------------------------------------------------------------------

-- Получения списка типов договоров

-- %author Gennady.Savinov 19.04.2017

-- %param ip_mode - режим получения списка договоров

-- 1 - не получать тип GF

-----------------------------------------------------------------------------

PROCEDURE get_contract_type_list

(

ip_mode IN NUMBER DEFAULT NULL,

op_id OUT t_varchar10,

op_key_name OUT t_varchar32,

op_name OUT t_varchar256

) IS

BEGIN

IF nvl(IP_MODE, 0) = 1 THEN

SELECT id, key_name, name

BULK COLLECT INTO op_id, op_key_name, op_name

FROM sfa_contract_types

WHERE rownum <=100

and key_name != 'GF'; --защита от слижком большого кол-ва записей

ELSE

SELECT id, key_name, name

BULK COLLECT INTO op_id, op_key_name, op_name

FROM sfa_contract_types

WHERE rownum <=100; --защита от слижком большого кол-ва записей

END IF;

END;

--

-----------------------------------------------------------------------------

-- Получение идентификатора типа договора, по его кейнейму

-- %author Gennady.Savinov 19.04.2017

-----------------------------------------------------------------------------

PROCEDURE get_contract_type_by_kn

(

ip_key_name IN VARCHAR2,

op_id OUT NUMBER

) IS

BEGIN

SELECT id

INTO op_id

FROM sfa_contract_types ct

WHERE ct.key_name = ip_key_name;

EXCEPTION WHEN OTHERS THEN

raise_application_error(-20000, 'Not found contract key name! ' ||dbms_utility.format_error_stack||dbms_utility.format_error_backtrace);

END;

BEGIN

END sfa_contract_pg;

Приложение Д

Презентационные материалы



Размещено на Allbest.ru

...