Интеграция 1С: Документооборота и 1С: Бухгалтерии для регистрации платежей

У заказчика КОДАР заявки на оплату обрабатывали в «1С:Документообороте», а платёжные поручения создавали в «1С:Бухгалтерии». Мы связали эти действия: теперь бухгалтер выполняет задачу в Бухгалтерии, получает готовое поручение, а статус оплаты возвращается в исходную заявку.

Как бухгалтер работал до настройки

В компании использовали две системы. Документооборот отвечал за задачи сотрудников, Бухгалтерия — за бухгалтерские документы. Из-за этого регистрация одной заявки на оплату требовала нескольких действий в разных базах.

1. Бухгалтер открывал задачу в Документообороте и выполнял её.
2. Переходил в Бухгалтерию и вручную создавал платёжное поручение.
3. Переносил данные из заявки, заполнял реквизиты и проверял документ.

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

На иллюстрациях показан пример работы в тестовой базе. Реквизиты организаций и персональные данные закрыты.

Рисунок 1. Исходная заявка на оплату в Документообороте до регистрации платежа.

Что должно было происходить в Бухгалтерии

Мы договорились о конкретном сценарии. Бухгалтер получает задачу из Документооборота прямо в Бухгалтерии. Когда он выполняет задачу «Зарегистрировать», программа создаёт платёжное поручение по данным заявки на оплату.

Рисунок 2. Задача из Документооборота в Бухгалтерии: команды «Зарегистрировать» и «Не регистрировать».

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

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

Как настроили создание платёжного поручения

За основу взяли штатный механизм бесшовной интеграции. В проекте использовали КОРП-версии программ и настроили веб-публикацию баз. Возможность применить такой механизм нужно проверять для конкретных редакций и релизов систем.

Затем настроили перенос данных из заявки в платёжное поручение. Часть реквизитов заполнялась фиксированными значениями, часть — по заданному алгоритму. Дополнительные реквизиты заявки также использовали при заполнении документа в Бухгалтерии.

В исходном сценарии поручение создавалось по команде «Создать на основании». Заказчику было удобнее выполнять задачу и сразу получать документ, поэтому мы доработали создание поручения при выполнении задачи «Зарегистрировать».

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

Рисунок 3. Созданное по задаче платёжное поручение. После отражения списания его состояние — «Оплачено».

Как статус оплаты возвращается в заявку

В заявке Документооборота использовали два дополнительных реквизита: «Статус оплаты счёта» и «Дата оплаты». Их значения заполняются по данным Бухгалтерии.

• «В реестре (ожидает оплаты)» — платёжное поручение создано, оплата ещё ожидается.
• «Оплачен» — по поручению отражена полная оплата. В заявке появляется дата соответствующего списания с расчётного счёта.
• «Частично оплачен» — поручение оплачено не полностью. По принятой в проекте логике поле «Дата оплаты» остаётся пустым.
• «Отклонён» — банковский документ получил соответствующее состояние.

Для определения статуса интеграция анализирует состояние платёжного поручения в регистре «Состояния банковских документов» и сопоставляет суммы. В этом проекте обмен настроили с интервалом пять минут: именно такой режим выбрали с учётом нужной скорости обновления и нагрузки на сервер.

Рисунок 4. Исходная заявка после оплаты: заполнены статус «Оплачен» и дата оплаты.

Какие проверки выполняются перед созданием документа

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

Проверка вида документа. Задача «Зарегистрировать» может относиться к разным документам. Система проверяет, что перед ней именно заявка на оплату.

Проверка организации. В одной базе Документооборота заказчик ведёт несколько организаций, а для каждой организации используется своя Бухгалтерия. Если заявка относится к другой организации, поручение в текущей базе не создаётся. Задача остаётся невыполненной, а пользователь получает объяснение.

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

Рисунок 5. Предупреждение о похожих платёжных поручениях с вариантами «Да», «Нет» и «Отмена».

В предупреждении показываются номер, дата, получатель, сумма и ответственный по найденным документам. Пользователь может выбрать один из трёх вариантов:

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

Так бухгалтер проверяет конкретные документы до создания ещё одного поручения. При этом система не считает любое совпадение суммы и контрагента безусловной ошибкой.

Проверки перед запуском

• Проверить заявку своей организации и заявку другой организации: во втором случае поручение в текущей Бухгалтерии создаваться не должно.
• Проверить все три решения при обнаружении похожего платежа: создать поручение, выполнить задачу без нового поручения, отменить действие.
• Сопоставить полную и частичную оплату с реквизитами заявки, затем проверить обновление статуса после очередного обмена.

Что изменилось после запуска

В пиковые дни через интеграцию проходит до 50 платёжных поручений. Для каждого из них данные берутся из заявки: повторно заполнять поручение вручную больше не требуется.

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

После запуска мы продолжали дорабатывать обмен. Часть данных сначала передавалась с ошибками: в двух системах использовались разные справочники и правила заполнения. Эти ситуации разобрали и исправили.

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

Материал подготовлен командой КОДАР. Описанный порядок работы необходимо проверять для используемых редакций, релизов и настроек информационных баз.