Экспорт данных из 1С в JSON для внешней системы

Обмен между 1С и внешними сервисами часто строится вокруг формата JSON. Он подходит для REST API, микросервисов, интернет-магазинов, банковских шлюзов и корпоративных приложений: данные передаются в понятной структуре, а принимающая сторона может обработать их практически на любом языке программирования.

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

Задача	Подход в 1С	Важные нюансы
Подготовка данных	Структура, соответствие или массив	Не передавать внутренние объекты без преобразования
Формирование JSON	`ЗаписатьJSON()` или JSON-сериализатор	Контролировать типы, даты и пустые значения
Отправка	HTTP-соединение и HTTP-запрос	Указать `Content-Type: application/json`
Защита	Токен, Basic Auth, сертификат	Не хранить секреты в открытом коде
Контроль результата	Код HTTP и тело ответа	Фиксировать ошибки и идентификатор операции

Подготовка структуры обмена

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

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

Поля, которые стоит предусмотреть

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

Формирование JSON в 1С

Для создания JSON можно использовать объект ЗаписьJSON и глобальную функцию ЗаписатьJSON(). Пример простой функции выглядит так:

Функция ПолучитьJSONДокумента(ДокументОбъект) Экспорт

    Данные = Новый Структура;
    Данные.Вставить("id", Строка(ДокументОбъект.Ссылка.УникальныйИдентификатор()));
    Данные.Вставить("number", ДокументОбъект.Номер);
    Данные.Вставить("date", Формат(ДокументОбъект.Дата, "ДФ=yyyy-MM-ddTHH:mm:ss"));
    Данные.Вставить("amount", ДокументОбъект.СуммаДокумента);

    Строки = Новый Массив;
    Для Каждого СтрокаТовара Из ДокументОбъект.Товары Цикл
        Позиция = Новый Структура;
        Позиция.Вставить("item", Строка(СтрокаТовара.Номенклатура.УникальныйИдентификатор()));
        Позиция.Вставить("quantity", СтрокаТовара.Количество);
        Позиция.Вставить("price", СтрокаТовара.Цена);
        Строки.Добавить(Позиция);
    КонецЦикла;

    Данные.Вставить("items", Строки);

    Запись = Новый ЗаписьJSON;
    Запись.УстановитьСтроку();
    ЗаписатьJSON(Запись, Данные);
    Возврат Запись.Закрыть();

КонецФункции

Конкретный формат даты нужно согласовать с документацией API. JSON не имеет отдельного универсального типа даты, поэтому одна система ожидает ISO 8601, другая — строку в локальном формате или отметку времени Unix. Числа также не следует превращать в текст без необходимости: принимающая сторона может использовать типизацию при разборе сообщения.

Отправка через HTTP-сервис

Для передачи сформированной строки применяется HTTPСоединение, HTTPЗапрос или соответствующие объекты встроенного языка. В запросе указывают адрес метода, HTTP-метод POST или PUT, тело сообщения и заголовок Content-Type.

Соединение = Новый HTTPСоединение("api.example.ru", 443, , , , 30, Новый ЗащищенноеСоединениеOpenSSL);

Запрос = Новый HTTPЗапрос("/v1/orders");
Запрос.Заголовки.Вставить("Content-Type", "application/json");
Запрос.Заголовки.Вставить("Accept", "application/json");
Запрос.Заголовки.Вставить("Authorization", "Bearer " + Токен);
Запрос.УстановитьТелоИзСтроки(JSONСтрока, КодировкаТекста.UTF8);

Ответ = Соединение.ВызватьHTTPМетод("POST", Запрос);

Названия методов могут отличаться в зависимости от версии платформы и используемого шаблона кода. Для больших объемов данных предпочтительнее пакетная отправка: например, передавать по 100–500 объектов с отдельным идентификатором пакета. Это уменьшает количество сетевых соединений и упрощает повторную обработку.

Авторизация и защита канала

Внешний сервис может использовать токен доступа, Basic Authentication, OAuth 2.0, клиентский сертификат или подпись запроса. Секретные параметры лучше хранить в защищенном хранилище, константах с ограниченными правами или отдельном регистре сведений с контролем доступа. Пароли и ключи не должны попадать в тексты ошибок и технологический журнал.

Передачу следует выполнять по HTTPS с проверкой сертификата сервера. Если интеграция запускается регламентным заданием, учетную запись фонового задания ограничивают необходимыми правами. Для входящих вебхуков дополнительно проверяют подпись, IP-адрес отправителя или уникальность события.

Ошибки, повторы и журналирование

Ответ внешней системы нужно анализировать по HTTP-коду и содержимому тела. Коды 200 и 201 обычно означают успешную обработку, 400 указывает на ошибку данных, 401 или 403 — на проблему с авторизацией, а 429 и 5xx часто требуют повторной попытки через заданный интервал.

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

корректно ли формируется JSON на пустых и заполненных данных;
совпадают ли типы и имена полей со спецификацией API;
правильно ли обрабатываются специальные символы и кириллица;
сохраняется ли идентификатор отправленного объекта;
что происходит при недоступности сервера;
можно ли безопасно повторить неуспешный запрос.

В журнале обмена полезно хранить дату попытки, объект 1С, размер сообщения, HTTP-код, текст ответа и статус обработки. Для повторов применяют очередь: запись получает состояние «Ожидает отправки», после успешного ответа переходит в «Передано», а после нескольких неудач — в «Ошибка». Важно предусмотреть идемпотентность, чтобы повторный запрос не создавал дубликат документа.

Когда выбрать готовый механизм интеграции

Если внешний сервис предоставляет полноценный REST API, обмен можно реализовать напрямую в расширении или общем модуле конфигурации. Расширение снижает количество изменений в типовом решении и упрощает обновление. Логику формирования данных при этом лучше отделять от транспорта: один модуль создает структуру, другой сериализует ее, третий выполняет HTTP-вызов.

Для сложных сценариев применяют универсальные шины обмена, брокеры сообщений или промежуточные сервисы. Такой вариант оправдан, когда требуется маршрутизация, преобразование форматов XML и JSON, контроль очередей, мониторинг нескольких систем и гарантированная доставка. Для простого обмена заказами или остатками достаточно аккуратного HTTP-клиента в 1С.

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