Как интегрировать 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С относительно гибко настраивается, модернизируется и интегрируется. Сегодня это является несомненным плюсом для компаний, которые ранее пользовались другими системами (сейчас недоступными).
Посмотрите наши кейсы и напишите о ваших задачах. После уточнения деталей предложим варианты решения.