Сценарии использования API 2 СБИС

Вариант 1. Необходим максимально простой вариант, клиент готов работать в личном кабинете СБИС.

Имеет смысл рассмотреть вариант использования СБИС Коннект. Это будет принципиально проще и с тем же результатом. Исключение составляют не Windows платформы.

Отправка

Стандартная отправка в соответствии с руководством.

Обработка служебных

Не реализуется - делается в ЛК СБИС.

Обработка статусов

Либо не реализуется, т.к. делается в ЛК СБИС, либо стандартная обработка статусов в соответствии с руководством.

Обработка входящих

Не реализуется - делается в ЛК СБИС.

Загрузка утвержденных входящих

Сценарий:

Пользователь заходит в ЛК СБИС, просматривает входящие документы. Принимает решение утвердить/отклонить. Для тех документов что он собирается утвердить сначала синхронизирует номенклатуру (чтобы не забыть может быть использована дополнительная фаза внутреннего документооборота). После утверждения ИС автоматически загружает все утвержденные документы (перед загрузкой в ИС ищутся документы по реквизитам, если не находятся то создаются новые, если находятся то перезаписываются – прорабатывается вопрос как такие документы в системе потом находить и проводить).

Алгоритм загрузки утвержденных входящих:

1. В цикле обработки результатов метода СписокИзменений отбираем только события, у которых:

• Документ.Направление = «Входящий»
• Документ.Событие.Название = «Уведомление о приеме»

1. По полученному списку вызываем по идентификатору редакции метод ПрочитатьДокумент.
2. Загружаем в систему вложения из раздела «ВложенияУчета» (данные вложения при запросе сгенерируются на лету по данным ЛК СБИС – с распознанной номенклатурой).

Вариант 2. Необходимо обрабатывать документы в своей системе, на рабочих станциях есть доступ в интернет. (загружаю в ИС только то, что необходимо).

Организация хочет работать с ЭДО в своем интерфейсе и готова сделать минимум доработок. Предполагается, что каждый пользователь ИС работает со СБИС через API от своего имени. Система не хранит никакой лишней информации. Списки электронных документов каждый раз запрашиваются через API. Для предварительно просмотра документов используются сервисы СБИС.

Отправка

Стандартная в соответствии с документацией.

Обработка служебных

Стандартная в соответствии с документацией.

Обработка статусов

Стандартная в соответствии с документацией.

Обработка входящих

Сценарий:

В ИС показывается окно входящие аналогично интерфейсу ЛК СБИС, данные запрашиваются при помощь метода СписокДокументовПоСобытиям. Пользователь просматривает документы, принимает решение утвердить/отклонить. Синхронизирует номенклатуру. После чего выбирает документы, которые необходимо загрузить в ИС и загружает.

В ИС необходимо реализовать:

• интерфейс показывающий список входящих документов аналогично ЛК СБИС с необходимой фильтрацией (СписокДокументовПоСобытиям).
• форму просмотра входящего документа средствами API (показывается HTML представление аналогичное ЛК СБИС). (ПрочитатьДокумент по идентификатору редакции, ссылки на HTML представления на вложении)
• интерфейс синхронизации кодов номенклатуры поставщика с хранением результатов сопоставления либо в ИС либо в ЛК СБИС (документации пока нет)
• интерфейс принятия решения по входящим документам либо из списка входящих документов, либо из формы просмотра.
• Интерфейс поиска документов в ИС по их реквизитам, чтобы дать пользователю информацию о том есть данные документы в системе или нет. Отличаются ли имеющиеся документы.
• Загрузку основных типов/версий вложений.

Вариант 3. Необходимо обрабатывать документы в своей системе, на рабочей станции нет доступа в интернет (гружу все в ИС и там уже разбираюсь).

Организация хочет работать с ЭДО в своем интерфейсе и готова к значительным доработкам своей ИС. ИС сама администрирует полномочия своих пользователей и обеспечивает подписание документов нужной подписью. Доступ конечных пользователей в интернет ограничен. Поэтому весь в

Предполагается, что организация не хочет администрировать доступ в ЛК и использовать средства проверки полномочий ЭП под документами, она полностью полагается на свою систему. С этой целью, возможно закрытие доступа конечным пользователям в ЛК СБИС, а доступ оставляется только у администраторов и служебных учетных записей под которыми работает ИС.

Отправка

Сценарий:

При нажатии кнопки отправить, ИС подготавливает и подписывает документы, помещает их в очередь на отправку. Учитывая, что подготовленный пакет документов должен перед отправкой хранится в какой-то очереди, а также предполагается, что хочет хранить архив электронных документов. В этом случае рекомендуется для этих целей использовать те же «буферные таблицы», что и для входящих документов (описано ниже).

Обработка служебных

Стандартная в соответствии с документацией.

Алгоритм для систем доверяющим СБИС в части подготовки служебных документов:

1. В отдельном потоке через интервал настроенный в интеграционном решении вызывается метод «СБИС.СписокСлужебныхЭтапов». В результате получаем список событий для обработки.
2. Полученные события обрабатываем в цикле. Каждое событие (объект Документ) будет всегда содержать информацию о единственно возможном этапе и действии. Поэтому перебирать этапы и действия смысла нет, можно всегда безусловно брать первый элемент массива.
3. По каждому событию вызывается метод СБИС.ПодготовитьДействие. Проще всего параметры данного метода сгенерировать на основе записи события, дополняем информацией о подписанте, и переопределяем Этап и Действие взяв за основу их единственный элемент.
4. Подписываем файлы вложения.
5. Вызываем метод СБИС.ВыполнитьДействие передавая туда только подписи под документами (т.к. сами файлы уже сгенерированы при подготовке действия).

Обработка статусов

Стандартная в соответствии с документацией.

Обработка входящих

Сценарий:

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

Пользователь работает только с этими буферными таблицами, где повторяются все возможности ЛК СБИС – просмотр списка документов, просмотр карточки документа, принятие решения, синхронизация номенклатуры, поиск уже имеющихся в ИС документов по реквизитам.

По смыслу эти буферные таблицы являются электронным архивом.

Для наиболее полной реализации рекомендуется следующая структуру буферных таблиц.

Список необходимых доработок:

• интерфейс показывающий список входящих документов аналогично ЛК СБИС с необходимой фильтрацией.
• форму просмотра входящего документа (показывается PDF представление загруженное из ЛК СБИС).
• интерфейс синхронизации кодов номенклатуры поставщика с хранением результатов сопоставления либо в ИС либо в ЛК СБИС.
• интерфейс принятия решения по входящим документам либо из списка входящих документов, либо из формы просмотра.
• Обработку отозванных Отправителем документов. Если до утверждения документов ИС получает событие удаления документов Отправителем, то обработку таких документов необходимо прервать.
• Интерфейс работы с аннулированием документов.
• Интерфейс поиска документов в ИС по их реквизитам, чтобы дать пользователю информацию о том есть данные документы в системе или нет. Отличаются ли имеющиеся документы.
• Загрузку основных типов/версий вложений.

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

1. В цикле обработки результатов метода СписокИзменений отбираем:
   1. Непосредственно входящие пакеты ( Документ.Направление = «Входящий», Документ.Событие.Название="Получение") Далее по идентификатору редакции делаем ПрочитатьДокумент и помещаем всю информацию о пакете в буферные таблицы.
   2. Информацию о отзыве документа (Документ.Направление = «Входящий», Документ.Событие.Название="Уведомление об удалении на стороне отправителя"). Это означает что до того как Вы приняли документ пользователь его успел отозвать и прием такого документа не возможен. ИС должна найти в буферных таблицах такой документ и прервать его обработку (удалить/ проставить флаг/ запустить какую-то регламентированную компанией процедуру).
   3. Запрос на аннулирование (Документ.Направление = «Входящий», Документ.Событие.Название="Получение соглашения об аннулировании"). Добавляем в буферную таблицу аналогично п.1.1.

Алгоритм принятия решения по входящему документу / запросу на аннулирование из буферных таблиц:

1. Определяемся с решением, а также с ФИО которое в этом решении будет фигурировать.
2. Вызываем метод «СБИС.ПодготовитьДействие» (Утвердить, Отклонить, Документ аннулирован, Аннулирование отклонено) в зависимости от принятого решения, передаем методу ФИО подписанта который будет фигурировать в решении (подписей может быть много, а по формату некоторых документов он может быть только один). Предполагается, что организация использует стандартный регламент, поэтому запрашивать доступные варианты нет смысла. Если попытаться выполнить утверждение над уже утвержденным документом – вернутся ошибка.
3. В ответ получаем документы которые необходимо подписать для его выполнения. Сохраняем их в буферных таблицах (вложения привязанные к текущему событию – либо можно создать отдельное событие по названию решения).
4. Подписываем вложения выбранным сертификатом. Если нужно провести согласования, то по мере его проведения добавляем под этими вложениями подписи.
5. После последнего согласования. Вызываем метод «СБИС.ВыполнитьДействие», передавая в него все прикрепленные к нашему событию файлы и подписи.