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

Приложение 1

Соглашение

о порядке использования интернет ресурса «Личный интернет-кабинет»
на сайте ОАО «Екатеринбургэнергосбыт»
от «____»_____________2016г. № #abonent_id#
ОАО «Екатеринбургэнергосбыт», именуемое в дальнейшем "Поставщик", в лице Начальника Управления по работе с коммерческими потребителями Григоровой С.М., действующей на основании доверенности №10/292Д от 24.12.2015г., с одной стороны, и #abonent_organization_name#, именуемое(ый) в дальнейшем "Абонент", в лице #abonent_director_name_position#, действующего на основании #abonent_on_basis_of#, с другой стороны, заключили настоящее соглашение о нижеследующем.

1. Предмет соглашения

1.1. Настоящее соглашение определяет порядок совершения сторонами определённых действий по использованию Абонентом ресурса «Личный интернет – кабинет», в дальнейшем «Услуги» на сайте Поставщика, с целью получения дополнительных услуг в интерактивном режиме. Объем и условия предоставления Услуги Абоненту по настоящему соглашению, следуют из условий использования Личного интернет-кабинета, расположенного на страницах web-сайта Поставщика «www.eens.ru» в разделе «Личный кабинет». На момент заключения настоящего соглашения предусмотрены следующие возможности:

А) Просмотр общих данных о договоре.

Б) Просмотр данных об объектах потребителя (группы оборудования, точки учёта, приборы учёта, схема учёта, показания, почасовые объемы).

В) Просмотр финансовых данных абонента (счета, оплаты, акт сверки).

Г) Возможность распечатать квитанцию, счёт и счёт-фактуру.

Д) Возможность передавать показания (интегральные).

Е) Возможность оставить вопрос ответственному инженеру по договорам.

Ж) Возможность передавать почасовые объемы электропотребления.

Поставщик оставляет за собой право в любое время модифицировать предоставляемые Услуги.

1.2. Абонент, подписав данное соглашение, подтверждает свое согласие с условиями предоставления услуг.

1.3. Идентификация Абонента и подтверждение авторства и подлинности документа, предоставленного Абонентом в
электронной форме с использованием Интернет ресурса «Личный интернет-кабинет» производится Поставщиком с помощью идентификатора Абонента и пароля.

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

1.5. Стороны признают применение системы Личный интернет-кабинет в соответствии с настоящим Соглашением достаточным для обеспечения конфиденциальности, авторства и целостности электронных документов, предоставляемых Абонентом, а также невозможности их фальсификации без нарушения настоящего соглашения и руководства пользователя.

1.6. Авторство и подлинность составленных Абонентом документов с использованием системы Личный интернет-кабинет гарантируются Абонентом и могут быть приняты Поставщиком к исполнению без дополнительных проверок.

2. Стоимость услуг

2.1. Услуга «Личный кабинет» предоставляется Абоненту безвозмездно.

3. Срок действия соглашения и порядок его расторжения

3.1. Соглашение вступает в силу с момента подписания его обеими сторонами.

3.2.Срок действия данного Соглашения 1 год с момента подписания. Если ни одна из сторон в установленном порядке не заявит о прекращении действия соглашения, то срок действия считается продлённым на следующий год.

3.3. Стороны вправе расторгнуть Соглашение в одностороннем порядке, путём письменного уведомления другой Стороны не менее чем за 2 недели до даты расторжения.

4.Прочие условия

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

4.2. Исполнитель вправе приостановить возможность использования Абонентом системы Личный интернет-кабинет в случае несоблюдения Абонентом требований по использованию системы Личный интернет-кабинет и обеспечению информационной безопасности, предусмотренных законодательством и условиями настоящего Соглашения.

Абонент	Поставщик
ИНН #abonent_inn#	ИНН 6671250899
КПП #abonent_kpp#	КПП 660850001
Адрес: #abonent_address#	620144, г. Екатеринбург, ул. Сурикова, дом 48
№ договора (контракта): #abonent_contract_number#	р/с 40702810316160030915 / к/с 30101810500000000674
ОКПО #abonent_okpo#	УРАЛЬСКИЙ БАНК СБЕРБАНКА РФ Г.ЕКАТЕРИНБУРГ
ОКВЭД #abonent_okved#	БИК 046577674
Адрес эл.почты: #abonent_email#	ОГРН 1086658002617
Контактный тел: #abonent_tel#	Тел.:359-07-59
___________________/ #abonent_director_name#	_____________________ / С.М. Григорова

Приложение 2

Оплата пластиковой картой.

Получатель: Екатеринбургэнергосбыт

Код запроса: 14016

Идентификатор транзакции: 3AE13108D95516A592D431F092B98E16

Дата проведения платежа: 20141022 12:42:56

Назначение платежа: Договор купли-продажи № 18960 от 01.01.2013 г. Отделение: ОКП Октябрьский Платеж за мощность в соответствии с договором купли-продажи № 18960 от 01.01.2013

Сумма платежа, руб.: 170996,09

Сумма комиссии, руб.: 2393,95

К зачислению на счет, руб.: 168602,14

Результат проведения платежа: Банк оплату не разрешил

Приложение №3

Инициирование платежа

Для инициирования платежа магазин после формирования корзины (заказа) выполняет переадресацию на адрес Web-сервера Банка-эквайера

Пример адреса для инициирования платежа:

http://pps.intervale.ru/payment/start.wsm?lang=ru&merch_id=7BF970824904C6E7F0C03AA2334367E5&back_url_s=https://merchant.ru/succeeded.jsp&back_url_s=http://merchant.ru/failed.jsp&o.order_id=28735

Двухфазный сценарий взаимодействия с магазином

В процессе проведения платежной транзакции сервер банка дважды взаимодействует с магазином.

Первая фаза взаимодействия называется CheckPaymentAvail и предназначена для проверки возможности проведения платежа в магазине.
Запрос CheckPaymentAvailRequest содержит параметры операции:

1. 
   OrderParams – именованный набор параметров платежа. Набор параметров и их названия определяются магазином. Примеры параметров:
   

• 
  phone=79263324234, amount=1000 (оплата за телефон)
  
• 
  contract=321489723487, amount=1500 (оплата по номеру договора)
  

2. 
   TransactionID – идентификатор транзакции в PPS.
   
3. 
   Language – код языка, используемый для формирования описания покупки клиенту (ISO-639).
   

Ответ личного кабинета CheckPaymentAvailResponse определяет возможность совершения запрошенной покупки:

• 
  ResultCode – результат проверки возможности платежа.
  
• 
  ResultDesc – описание результата.
  
• 
  PurchaseDesc – описание запрошенного клиентом платежа на языке, переданном в запросе CheckPaymentAvailRequest. Описание не должно содержать сумму покупки, т.к. сумма передается отдельным полем Amount. Примеры описаний:
  

1. 
   Пополнение счета 79053324234
   
2. 
   Пополнение счета по Договору №321489723487
   
3. 
   Книга «UML. Специальный справочник»
   

• 
  Amount – сумма покупки.
  
• 
  AccountId – идентификатор счета магазина в PPS. Необязательное поле, при условии наличия у магазина только одного счета в данной валюте.
  

В случае если ResultCode=2 (CPA Rejected – ошибочное проведение платежа), поле содержит параметр CPAFailDescription, описывающий причину неудачи при выполнении первой фазы платежа.

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

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

Запрос RegisterPaymentRequest содержит результат проведения платежа:

• 
  ResultCode – результат проведения платежа.
  
• 
  ResultDesc – описание результата.
  
• 
  TransactionID – идентификатор транзакции. Используется для сопоставления запросов первой и второй фазы.
  
• 
  TransmissionDateTime – время и дата из авторизационного запроса в формате MMdd HH:mm:ss.
  
• 
  RRN (Retrieval Reference Number) – идентификатор платежа в процессинговом центре.
  

В случае если банк не получил ответа от магазина, система продолжит посылать запросы в режиме offline с определенным временным интервалом. Запрос RegisterPaymentRequest доставляется в магазин до тех пор, пока на него не будет получен ответ RegisterPaymentResponse, указывающий на то, что личный кабинет успешно принял информацию о платеже. В случае если количество интервалов исчерпано, система генерирует event с большим приоритетом.

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

Для взаимодействия с магазином в качестве транспорта используется защищенное соединение HTTPS с basic-аутентификацией. В настройках необходимо указать параметры подключения имени (HTTP AUTHENTICATION LOGIN), пароля (HTTP AUTHENTICATION PASSWORD) и сертификат взаимодействия в HTTPS (SSL TRUSTED CERTIFICATES). Поле Common Name в SSL-сертификате сервера должно совпадать с IP или DNS-именем сервера личного кабинета.

Приложение 4

1. Проверка возможности приема платежа

Сборщик платежей перед приемом платежа формирует запрос вида:
https://lk.eens.ru/paymentinfo/%name%/checknls.php?nls=5181037005
Где nls – номер лицевого счета, полученный от плательщика.

%name% - уникальное имя для сборщика платежей
Сервер возвращает ответ:




1

5181037005

800.06

10.05

Район: Кировский, Ответсвенный за участок: Лукина Алена Ивановна, Телефон: 215-76-26


Где,

1 – платеж можно принимать по виду перевода «электроэнергия», 2- платеж принимать нельзя по виду перевода «электроэнергия»,

1 – платеж можно принимать по виду перевода «ограничение/включение», 2- платеж принимать нельзя по виду перевода «ограничение/включение»

- номер лицевого счета, совпадет с номером в запросе.

-содержит информацию о задолженности по виду перевода «электроэнергия», в текстовом формате.

- содержит информацию о задолженности по виду перевода ограничение/включение, в текстовом формате

- дополнительная информация, в т.ч. о причинах невозможности приема платежа по указанному лицевому счету.

2. Передача информации о принятых платежах от физических лиц

Сервер банка имеет перечень принятых платежей от физических лиц, информацию о которых необходимо передать в ОАО «Екатеринбургэнергосбыт».

Код операции	Сумма	Время	№ лицевого счета	№ счета	Период оплаты
Ghj34j546	100.23	2012-06-12 12:11:11	1346087007	18	05.2012
645h764jk	200.50	2012-06-12 12:11:11	2568884001	12	07.2012

Операции передаются по одной в запросе методом GET
Сервер Банка поочередно для каждой операции формирует Web запрос. В запросе передает все параметры операции.
Пример:

https://lk.eens.ru/paymentinfo/%name%/checkpayment.php?trx_id=999999xxxxx&datetime=2012-03-25 22:12:01&type_oper=1&doc_num=234&amount=1000,21&nls=1346087007&opl_group=1&period=05.2102&p1=произвольный текст(10)&p2=произвольный тест(50)&p3=произвольный текст(макс)&show0=2234,34&show2=3345,87
Где

%name% - уникальное имя для сборщика платежей

trx_id – уникальный код операции в системе банка.

datetime - дата и время операции в формате гггг-мм-дд чч-мм-сс

type_oper – тип операции. 1 – поступление денег, 2 – отмена операции

doc_num – номер счета по которому производится оплата (если есть)

amount – сумма платежа

nls – номер лицевого счета.

opl_group - Группа оплаты (целое число 1-по виду перевода «электроэнергия», 5 – по виду перевода «ограничение/включение»)

period – период за который производится оплата (месяц и год в формате мм.гггг)

show0 – показание дневной или пиковой зоны (если нет то не передается или передается 0) (только для вида перевода «электроэнергия»)

show1 – показание полупиковой зоны (если нет то не передается или передается 0) (только для вида перевода «электроэнергия»)

show2 – показание ночной зоны (если нет то не передается или передается 0) (только для вида перевода «электроэнергия»)

p1 – произвольный тест длина 10

p2 – произвольный тест длина 50

p3 – произвольный тест длина максимум
В ответ Банк получает XML содержащий результат обработки запроса нашим сервером:
    

     999999xxxxx

    1

    OK

 
Где id – передаваемы Банком код операции

Code – код результата обработки нашим сервером (1 – успех, 2 – неуспех по причине «Отправлено повторно», 3-неуспех по другим причинам)

Desc – текстовое описание результата обработки нашим сервером.
Банк, получив ответ об успешной обработке операции помечает ее как переданную и больше к ней не возвращается.
Не получив ответа, или получив ответ о неуспешной обработке, Банк помечает операцию как непереданную.

Банк повторяет попытки передачи по непереданным операциям минимум каждые 10 минут.

5Технические требования

Аппаратные ресурсы

Аппаратные ресурсы предоставляются заказчиком в срок не позднее 1 октября 2016 года.

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

Две виртуальных машины на сервере x86-архитектуры со следующими характеристиками:

Машина 1

4 ядра в логическом разделе;

16 ГБ оперативной памяти;

Дисковое пространство: 200 ГБ дискового пространства

Сеть: Минимум 1 Gbps Ethernet.

Установленная операционная система: Windows Server 2008 R2 SP1
Машина 2

4 ядра в логическом разделе;

16 ГБ оперативной памяти;

Дисковое пространство: 1000 ГБ дискового пространства

Сеть: Минимум 1 Gbps Ethernet.

Установленная операционная система: Windows Server 2008 R2 SP1

Установленная СУБД SQL Server 2014

Архитектура решения

Система должна состоять из сервера баз данных и сервера приложений, расположенных на отдельных серверах.

Все интерфейсы должны быть построены по Web технологии.

Интерфейс должен корректно работать в браузерах Internet Explorer, Mozilla, Chrome активной на момент сдачи системы версии.

Передача данных между сервером приложений и пользователем должна осуществляться по протоколу HTTPS.

Внутри локальной сети аутентификация пользователей должна осуществляться автоматически через службу каталогов (Windows - авторизация).

Внешние пользователи личного кабинета авторизуются используя внутреннюю систему полномочий приложения.

Интерфейс должен автоматически адаптироваться под разрешение экрана, в том числе обеспечивать работу на мобильных устройствах.