Начните с одного заказа и его изменений. Назначьте источники данных, различайте остаток, резерв и доступность, а повторную отправку и сбои проверьте до запуска. Способ подключения зависит от конфигурации, версии и доступов конкретной 1С.
Назначьте источники данных
Если один и тот же объект свободно меняется в нескольких системах, при обмене понадобятся правила разрешения конфликтов. Проще сначала определить владельца данных и направление передачи. Например, учётная система хранит номенклатуру, склад — события движения, а CRM — обращение и коммуникации.
Это возможная схема, а не универсальное распределение. В вашей компании складской учёт может полностью находиться в 1С, а внешняя система лишь показывать задания сотруднику. Таблица ответственности помогает понять, что интеграция читает и что имеет право изменять.
| Объект | Вопрос перед обменом | Результат решения |
|---|---|---|
| Номенклатура | Где создаются позиции, варианты и единицы измерения? | Один источник и устойчивый идентификатор позиции. |
| Контрагент | Как сопоставлять существующие записи? | Правила совпадения, дублей и новых записей. |
| Заказ | Кто меняет состав, сумму и статус? | Владелец каждого поля и версия заказа. |
| Остаток и резерв | Какие значения доступны менеджеру? | Отдельное значение физического остатка и доступного количества. |
Проверьте доступный способ подключения
Платформа «1С:Предприятие» поддерживает стандартный REST-интерфейс на основе OData. Его использование требует публикации и настройки доступа к объектам. В конкретном решении могут применяться HTTP-сервисы, предусмотренный обмен или файлы выгрузки; вариант выбирают после проверки конфигурации и требований.
Возможность прочитать объект не означает, что можно безопасно создать любой бизнес-документ. Нужно проверить права, обязательные поля и правила самого прикладного решения. Начните с тестовой среды и ограниченного набора операций, согласованного с ответственным за 1С.
Свяжите записи устойчивыми идентификаторами
Не используйте отображаемое название товара как единственный ключ: название может измениться, а у двух позиций оно может совпадать. Сохраните соответствие идентификаторов между системами. Для начальной загрузки отдельно обработайте дубли, отсутствующие позиции и разные единицы измерения.
Для заказа нужны идентификатор, версия и событие изменения. Повторное событие должно приводить к тому же результату, а не создавать второй документ. Если изменения поступили не по порядку, система должна распознать устаревшую версию и сохранить более актуальные данные.
Различайте остаток, резерв и доступность
Физический остаток показывает наличие, резерв — обязательства под заказы, доступное количество определяется вашими правилами. Для менеджера важно не только число, но и время его обновления. Показывайте, когда данные были получены и что делать, если обмен задержался.
Проверьте ситуацию, когда два сотрудника одновременно подтверждают заказ на последнюю единицу товара. Простой показ вчерашнего остатка не решает вопрос резервирования. Нужно согласовать, какая система подтверждает резерв и какой ответ разрешает обещать товар клиенту.
Предусмотрите сбои и сверку
Сохраните события обмена, попытки, ответ и причину ошибки. У временного сбоя должен быть безопасный повтор, у ошибки данных — понятное действие для ответственного. Если ответ потерян после создания документа, сначала проверьте наличие результата по идентификатору.
Помимо передачи сообщений нужна периодическая сверка: совпадают ли заказы, статусы и связанные документы. Она помогает обнаружить случаи, которые отдельный журнал успешной отправки не показывает. В первом этапе можно сверять ограниченный набор объектов и расширять его после проверки.
- Обычный заказ и изменение его состава.
- Повторная отправка одного события.
- Недоступность 1С и последующее восстановление.
- События, пришедшие в обратном порядке.
- Неизвестная позиция, дубль контрагента и отмена заказа.
- Сверка результата между CRM, складом и учётной системой.
Документация по теме
Конкретный способ подключения и доступные операции проверяются на вашей конфигурации.