Шаг 1. В тестовом окружении по адресу https://sandbox.goodfin.ru войти под учетной записью user_<serviceSystemName> (см. правила получения логина на шаге 1 в I. Подготовительные работы по интеграции c применением API) в личный кабинет поставщика сервиса с ролью "Администратор сервиса".
Если возникает ошибка входа, то возможно что-то с сервером пошло не так. Выполните проверку, как показано на рисунке ниже:
Шаг 2. После входа в личный кабинет поставщика сервиса перейдите к разделу "Продукты". Если Вы входите впервые и не импортировали еще ни одного продукта, то раздел будет пустой.
Шаг 3. Импортируйте созданный вами (согласно инструкции II.1. Создание продукта в виде конфигурационного файла yaml) конфигурационный файл продукта. Будет выполнена проверка синтаксической корректности файла.
Шаг 4. Если проверка прошла успешно, то система предложит закончить импорт.
Шаг 5. Результат импорта вы увидите в списке продуктов.
ВНИМАНИЕ!
Импортированный продукт, по умолчанию, отключен и не доступен для выбора клиентом в предложениях. Продукт станет доступен только после нажатия кнопки "Активировать продукт". Но пока к продукту не добавлено ни одного тарифа, пользователь не сможет по данному продукту отправить заявку в сервис.
Шаг 6. Для добавления/обновления тарифов по продукту перейдите в продукт.
Шаг 7. Импортируйте созданный вами (согласно инструкции II.2. Создание тарификатора в виде конфигурационного файла yaml) конфигурационный файл тарификатора. Будет выполнена проверка синтаксической корректности файла.
ВНИМАНИЕ!
При повторном импорте тарификатора будут удалены все ранее имеющиеся тарифы у продукта и загружены новые из файла.
Шаг 8. Если проверка прошла успешно, то система предложит закончить импорт.
Шаг 9. Результат импорта вы увидите в списке тарифов продукта.
Шаг 10. Для тестирования продукта активируйте его.
Шаг 11. Теперь продукт активен.
Шаг 12. Теперь требуется войти в систему как клиент с помощью тестовой учетной записи клиента cc_<serviceSystemName> (см. правила получения логина на шаге 1 в I. Подготовительные работы по интеграции c применением API)
Шаг 13. Выбрать любую клиентскую роль.
Шаг 14. Перейти в раздел "Моя компания" и в фильтре выбрать тот тип продукта, который тестируете.
Шаг 15. Далее в фильтре выберите свой тестируемый продукт.
На тестовом стенде наименования продуктов и сервисов будут выглядеть как в примере ниже:
Шаг 16. Для проверки обязательности заполнения полей карточки компании (в конфигурационном файле продукта это блок companyFields.required) вы должны очистить эти поля. Система в ответ должна подсветить их, показать в панели Категории счетчик ошибок, а в панели Навигатор ошибки типа "Требуется заполнить".
ВНИМАНИЕ!
Если вы обнаружили ошибки в настройке обязательности, то требуется исправить конфигурационный файл продукта, перезагрузить его (см. шаги 29-30). Затем снова вернуться в клиентский кабинет для тестирования исправленных настроек.
Шаг 17. Проверка настроек пакетов документов. Если документы уже прикреплены, то вы можете перевести их в статус "Архивный" (для этого у документа нажмите на иконку "Редактировать", далее нажмите "Перевести в статус Архивный" и вернитесь к списку документов). В системе документы в статусе "Архивный" считаются утратившими актуальность. Тогда можно увидеть и проверить работу настроенного пакета документа без правила применимости (у такого пакета отсутствует блок applicabilityRule).
ПРИМЕЧАНИЕ
При настройке пакетов документов возможно два варианта реализации:
1. Без правила применимости (без блока applicabilityRule), все документы в составе такого пакета считаются безусловно обязательными. И именно такой пакет документов срабатывает в момент включения фильтра на вкладке Документы в карточке компании.
2. с правилом применимости (оно срабатывает в клиентском кабинете, когда клиент просматривает возможные предложения и уже заполнил карточку своей компании и данные сделки), см. пример в шаге 26.
В примере настроек продукта (см. II.1. Создание продукта в виде конфигурационного файла yaml) есть один пакет документов без правила применимости:
- #docsPackage 7
#name varchar(500) NOT NULL
#Указать полное наименование пакета документов, включая наименование продукта и сервиса для полноты понимания
name: "Пакет документов для ЮЛ (БГ на исполнение, БИН)"
#shortname varchar(50) NOT NULL
#Указать краткое наименование пакета документов, чтобы по нему понять условия применимости пакета документов
shortName: "Пакет документов для ЮЛ (БГ, БИН)"
#description varchar(1000) NULL, описание пакета документов, которое может выводиться как подсказка в системе
description: NULL
#полный перечень типов документов см. в docs_types
#списком перечисляются мнемокоды типов обязательных документов в пакете
#полный перечень см. в справочнике docs_types
docsTypes:
- "CHARTER"
- "HEAD_APPOINTMENT_PROTOCOL"
- "HEAD_PASSPORT_COPY"
#нет applicabilityRule -пакет применим безусловно для всего продукта
Так при включенном фильтре показано срабатывание пакета документов, система требует прикрепить копию паспорта (HEAD_PASSPORT_COPY), т.к. он в статусе "Архивный":
Шаг 18. Проверка настроек фин. показателей. Чтобы проверить настройки обязательности отчетных периодов и показателей, вы можете очистить ячейки с данными.
При включенном фильтре система должна подсветить отчетные периоды (за это отвечает блок настроек продукта periodTypes), а также конкретные показатели (за это отвечает блок indicators.required).
В примере настроек продукта (см. II.1. Создание продукта в виде конфигурационного файла yaml) для Формы 1 по общей системы налогообложения настроены три периода.
- #form and indicators
formSet: "0710099"
form: "0710001"
periodTypes:
- "currentReportingPeriod"
- "previousYear"
- "yearPrecedingPrevious"
В примере ниже показано, что при очищении нескольких показателей автоматически включается подсветка, указывающая на обязательность заполнения.
Шаг 19. Создание сделки для проверки настроек продуктовых полей и просмотра предложений.
Шаг 20. Ввод минимально необходимых данных для создания сделки. Должен быть выбран тип продукта, соответствующий тестируемому продукту.
Шаг 21. Заполнение данных о сделке
Шаг 22. Проверка настроек обязательности продуктовых полей с помощью фильтра. Для проверки обязательности заполнения продуктовых полей в сделке (в конфигурационном файле продукта это блок productFields.required) вы должны очистить эти поля. Система в ответ должна подсветить их, показать в панели Категории счетчик ошибок, а в панели Навигатор ошибки типа "Требуется заполнить".
ВНИМАНИЕ!
Если вы обнаружили ошибки в настройке обязательности, то требуется исправить конфигурационный файл продукта, перезагрузить его (см. шаги 29-30). Затем снова вернуться в клиентский кабинет для тестирования исправленных настроек.
Шаг 23. Переход к просмотру предложений
Шаг 24. Просмотр предложения, проверка счетчиков. Счетчики предназначены для информирования клиентом о том, сколько еще обязательных элементов нужно заполнить, чтобы получить возможность отправить заявку в сервис.
Подробнее о работе со сделками см. Проведение сделок
ВНИМАНИЕ!
Для проверки правильности расчета предварительного тарифа вы можете оперативно менять значения полей сделки на вкладке "Шаг 1: Заполнение данных сделки", которые влияют на выбор тарифа. Сохранять изменения и проверять на вкладке "Шаг 2: Предложения" значение "Предварительный тариф".
Поле "Срок рассмотрения (раб. дней)" равно значению поля workTerm из конфигурационного файла продукта.
Если вы обнаружили ошибки в настройке тарифа, то требуется исправить конфигурационный файл тарифа, перезагрузить его (см. шаги 6-9). Затем снова вернуться в клиентский кабинет для тестирования исправленных настроек.
Шаг 25. Для дозаполнения обязательных параметров можно нажимать или на счетчики, или использовать контекстное меню.
Шаг 26. Пример срабатывания пакета документов, имеющего правило применимости.
В примере настроек продукта (см. II.1. Создание продукта в виде конфигурационного файла yaml) есть пакет документов с правилом применимости, который показан ниже.
- #docsPackage 3
#name varchar(500) NOT NULL
#Указать полное наименование пакета документов, включая наименование продукта и сервиса для полноты понимания
name: "Пакет БГ(И), Банк БАНК1: ЮЛ на ОСНО, сумма БГ на исполнение > 10 млн"
#shortname varchar(50) NOT NULL
#Указать краткое наименование пакета документов, чтобы по нему понять условия применимости пакета документов
shortName: "ЮЛ на ОСНО, сумма > 10 млн"
#description varchar(1000) NULL, описание пакета документов, которое может выводиться как подсказка в системе
description: NULL
#полный перечень типов документов см. в docs_types
#списком перечисляются мнемокоды типов обязательных документов в пакете
#полный перечень см. в справочнике docs_types
docsTypes:
- "TAX_DECL_VALUE_ADDED_TAX_LAST_TAX_PERIOD"
- "TAX_DECL_ORGANIZATION_INCOME_TAX_LAST_TAX_PERIOD"
#правило применимости пакета документов
applicabilityRule:
#name varchar(150) NOT NULL
#наименование правила применимости
name: "ЮЛ с налогообложением = ОСНО И сумма БГ на исполнение больше 10 млн"
#type varchar(50) NOT NULL, по умолчанию значение = "script"
type: "script"
#script character varying(4000) NOT NULL
#Скрипт правила в виде функции isAvailableForDealApplicationData(dealApplicationData), возвращающей TRUE, FALSE или NULL.
#Если функция возвращает true, то считается, что пакет документов применим и при заполении заявки у клиента будут запрошены документы в составе пакета
#примеры готовых скриптов см. в документации - статья "Правила применимости: productApplicabilityRule, applicabilityRule"
script: "function isAvailableForDealApplicationData(dealApplicationData) {
var companyClass = java.lang.Class.forName('com.keyintegrity.shb.company.query.dto.CompanyDto');
var clientCompany = dealApplicationData.fetchFields[companyClass][dealApplicationData.result.client.id];
if (clientCompany == null) {
return null;
}
var taxSystemClass = java.lang.Class.forName('com.keyintegrity.shb.company.query.dto.catalog.TaxSystemCatalogDto');
var taxSystemDto = dealApplicationData.fetchFields[taxSystemClass][clientCompany.taxSystem];
if (clientCompany.legalType == null || taxSystemDto == null || dealApplicationData.result.productDealState.amount == null) {
return null;
}
var taxSystems = ['OSNO'];
return taxSystems.indexOf(taxSystemDto.code) !== -1 && clientCompany.legalType.id == 'ORGANIZATION' && dealApplicationData.result.productDealState.amount > 10000000;
}"
В примере следки исправлена сумма БГ на 11 млн. и сохранены изменения. В результате, сработало правило применимости показанного выше пакета документов.
Шаг 27. Пример срабатывания валидаторов.
Шаг 28. Пример успешного заполнения обязательных данных, как это видит Клиент.
Шаг 29. Загрузка исправленного конфигурационного файла продукта и/или тарификатора.
Если были обнаружены ошибки в настройке продукта или тарифа, то требуется исправить соответствующий конфигурационный файл, перезагрузить его. Затем снова вернуться в клиентский кабинет для тестирования исправленных настроек.
Шаг 30. Предупреждение о перезаписи продукта, если он перезаписывается после исправления.
