{"id":14271,"url":"\/distributions\/14271\/click?bit=1&hash=51917511656265921c5b13ff3eb9d4e048e0aaeb67fc3977400bb43652cdbd32","title":"\u0420\u0435\u0434\u0430\u043a\u0442\u043e\u0440 \u043d\u0430\u0442\u0438\u0432\u043e\u043a \u0438 \u0441\u043f\u0435\u0446\u043f\u0440\u043e\u0435\u043a\u0442\u043e\u0432 \u0432 vc.ru \u2014 \u043d\u0430\u0439\u0434\u0438\u0441\u044c!","buttonText":"","imageUuid":""}

Как интегрировать 1С с сервисом заявок так, чтобы ни одна заявка не потерялась

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

В условиях дефицита конструкторов ПО для бизнеса 1С выглядит перспективно на ближайшее время, поскольку закрывает множество задач для различных подразделений и типов компаний – от малого бизнеса до клиентов уровня enterprise – с возможностью модификации под самые необычные потребности. В этом материале вместе с аккаунтом проекта Михаилом рассказываем, как решали задачу по интеграции 1С с сервисом заявок для нашего клиента – федеральной логистистической компании.

Особенности проекта

Исходная ситуация. Есть два сервиса:

  • сервис обработки и приема заявок, написан на Python
  • сервис обработки заявок – внутренний сервис – 1С:Предприятие

Процесс создания и обработки заявок выглядел так:

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

Весь этот процесс сопровождался такими ошибками, как:

  • потеря заявок (пропустили письмо)
  • долгая обработка (поскольку все делается вручную)
  • ошибки при переносе данных из письма в 1С (человеческий фактор)
  • для клиента – задержки в обновлении статуса и информации по заявке

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

Сейчас схема работы выглядит следующим образом:

Поясним. Входящее движение: клиент с помощью web-формы отправляет заявку через СОЗ в 1С. Есть мастер-система 1С:Предприятие, в которой хранится вся информация по заявке: автор, содержание, исполнитель и т.д. Кроме этого, в ней заложена логика расчетов различных параметров, например, рейтинги исполнителей, вознаграждения, комиссии и т.д.

Исходящее движение: есть сервис обработки заявок (СОЗ), куда должны отправляться данные из 1С для дальнейшей обработки исполнителем.

Чтобы предотвратить потерю заявок в случае проблем с каким-либо из сервисов (например, если он недоступен несколько), двусторонний обмен информацией (от 1С к СОЗ и обратно) мы настроили через брокер сообщений rabbitMQ по принципу точка-точка. Кроме этого, сделали интеграцию с КриптоВС для подписания документов ЭЦП и с 1С ОКС для обработки документов и отчетности.

На данный момент у клиента полноценно функционирует работа с заявками (обычные заявки, аукционы, торги, тендеры, отчетность, ЭЦП, обновление справочников и прочее).

Как это работает

Авторы заявок, отправив данные в 1С, инициируют процесс работы 1С и отправку обработанных данных в СОЗ для создания заявки на исполнение. Таким образом в rabbit кладется регламентированное сообщение с определенными заголовками и параметрами. На основании этого сообщения СОЗ создает объект: заявку, объект справочника, отчет. Далее отправляет в 1С подтверждающее сообщение о том, что сообщение принято и обработано – при условии, что всё хорошо. В противном случае передается сообщение с ошибкой.

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

1С записывает полученные сведения в базу и отправляет в СОЗ, когда это необходимо (например, при запросе документа).

Проблемы и решения

Первая проблема – необработанные сообщения в 1С или в СОЗ. Из-за этого происходит рассинхронизация в двух системах.

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

В дальнейшем мы дополнительно планируем автоматизировать процесс. Для этого нужна:

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

Еще одна проблема – не срабатывали задачи по отправке сообщений из СОЗ в 1С из-за отсутствия обязательных атрибутов сообщения.

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

На проекте не были выстроены коммуникации, отсутствовали «правила игры» между разработчиками-приверженцами разных систем. На первый взгляд это может не показаться сколько-нибудь значимым фактором. Казалось бы, что может быть проще взять и договориться. Но на практике, если не обозначены и со всеми не согласованы «правила игры», огромное количество времени уходит на переговоры на тему, чье решение главнее и правильнее. Именно так здесь и происходило. Чтобы прекратить подобного рода дискуссии, мы организовали несколько созвонов, на которых были определены и всеми согласованы «правила игры» и далее записаны в правила проекта. Также определили лидера, уполномоченного принимать финальное решение, за ним – последнее слово.

Резюме

Как мы уже упоминали, 1C – гибкая платформа, способная подстроиться под различные задачи и интегрироваться с различными сервисами. Фактически 1С – конструктор, из которого при наличии компетентного специалиста можно собрать и систему работы с заявками, и HR-систему, и CRM для работы с клиентами, и ЭДО – все будет зависеть от задачи и цели заказчика.

Еще один важный момент – команда, где есть и 1С-разработчик, и эксперт в той области программирования, в которой создан сервис: в нашем случае – Python-разработчик. Работа на стыке двух разных языков программирования требует особого подхода в работе: необходимо больше контроля, взаимодействия и живого общения для выявления возникающих проблем на старте, а не после релиза.

1С относительно гибко настраивается, модернизируется и интегрируется. Сегодня это является несомненным плюсом для компаний, которые ранее пользовались другими системами (сейчас недоступными).

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

0
Комментарии
-3 комментариев
Раскрывать всегда