Интеграция 1С: руководство и ТЗ v3

Редакция документа 3.0 · 28 сентября 2026 года

Самостоятельное руководство и ТЗ для разработчика обработки «1С:Бухгалтерии предприятия» (БП) и бухгалтера лагеря. БГУ в это ТЗ не входит. Здесь собраны действующий контракт API, правила обмена, переход со старой обработки и критерии приёмки. Все числовые примеры синтетические.

v3 — редакция документа, а не новая версия сетевого протокола. Базовый путь остаётся /api/v1/public, а /accounting/connection возвращает api_version=2. Маршрутов /v3 добавлять не нужно. Доработка обработки 1С по этому ТЗ выполняется отдельно; готовая обработка БП вместе с API не поставляется.

Изменения документа: что изменилось в v3.

1. Результат, который должна обеспечить обработка

Цель — автоматически переносить в 1С продажи, оплаты и документы, сохраняя отдельный учёт расчётов с платёжным сервисом. Оплата родителя через ЮKassa и последующее перечисление на расчётный счёт лагеря не должны создавать два поступления одних денег.

События и источники

Пример без возвратов и переходящих остатков: три оплаты по 10 000 ₽ — это 30 000 ₽ оплат родителей. Удержание 915 ₽ и подтверждённое выпиской перечисление 29 085 ₽ закрывают соответствующие расчёты с сервисом. Реализации и оплаты не уменьшаются на 915 ₽. Дополнительные поступления на счёт по каждой оплате с платформы не создаются.

Что уже предоставляет платформа

1. Изоляцию лагеря по API-ключу, списки и фиксированные пакеты путёвок, успешных оплат и индивидуальных договоров.
2. Полные суммы, стабильные ID и время изменений; подтверждённую сумму ЮKassa после удержаний и общую комиссию, включая дозаполнение старых оплат в фоне.
3. Скачивание PDF индивидуального договора и приём PDF актов/УПД лагеря с версиями, повторной отправкой и отзывом.
4. Отображение принятых актов/УПД в заказе в панели лагеря. В ЛК родителя они не отображаются и в скачиваемый комплект не входят.

Что должен реализовать разработчик 1С

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

Все HTTP-соединения с платформой инициирует 1С. Публиковать базу 1С в интернете не требуется. Банковский обмен и получение входящих УПД провайдера подключаются отдельно.

Два разных потока УПД

• Исходящий УПД лагеря по заказу: формируется в 1С и отправляется на платформу через /accounting/documents/upd/{external_id} как PDF.
• Входящий УПД ЮKassa лагерю за услуги: служит источником расходов и НДС по комиссии. Действующий API платформы его не получает и не разбирает. Нужны отдельный ЭДО, импорт или ввод бухгалтером.

Приём исходящих PDF в платформу не автоматизирует получение входящих УПД провайдера. Это разные документы, контрагенты и направления обмена.

2. Подключение и проверка

Базовый адрес production: https://api.ourcamps.ru/api/v1/public. Для тестов используйте адрес тестового окружения, полученный от поддержки. Наличие кода в ветке DEVEL не означает его публикацию на production.

Все запросы передают заголовок:

X-API-Key: YOUR_CAMP_API_KEY

Лагерь определяется по ключу. Передавать camp_id в accounting-маршрутах не требуется. Номер базы и идентификаторы документов не заменяют аутентификацию.

Попросите администратора включить для интеграционного ключа право Загрузка актов и УПД из 1С. Старые ключи продолжают читать данные, но не получают право записи автоматически. В системном администрировании это поле API-ключа allow_accounting_uploads.

Для автоматизированной настройки сотрудник с правом управления лагерем может создать ключ через существующий JWT API:

POST /api/panel/camps/{camp_id}/api-keys
Content-Type: application/json

{"name":"1С Бухгалтерия","allow_accounting_uploads":true}

Существующему ключу разрешение меняется через PATCH /api/panel/camps/{camp_id}/api-keys/{key_id} с {"allow_accounting_uploads":true}. Это служебная настройка с авторизацией сотрудника, а не запрос по ключу 1С. При перегенерации ключа документные связи сохраняются.

Проверка связи

GET /accounting/connection

Поля data:

Отдельного capabilities.fees нет, а api_version=2 сохраняется и у версий сервера до добавления комиссии. Проверяйте наличие income_status, income_amount, fee_total в ответе оплат. Если полей нет, сохраните полную оплату, покажите несовместимость версии backend и необходимость её обновления; отсутствие поля не означает нулевую комиссию или штатный pending.

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

Профиль учёта для каждого подключения

До разработки зафиксируйте с бухгалтером настройки:

Бухгалтерские счета и виды документов не зашиваются в общий API-клиент. Поведением обработки управляет профиль конкретной базы БП с учётом её версии, расширений и учётной политики.

Все маршруты интеграции

Пути дополняют базовый адрес /api/v1/public:

Отдельных маршрутов банковских перечислений, входящих УПД провайдера или реестра денежных возвратов в этом контракте нет. Примерные /payouts сторонних платёжных API нельзя считать методом перечислений выручки магазину на платформе.

3. Формат ответов, идентификаторы и ошибки

JSON-ответы используют общий формат:

{
  "success": true,
  "data": [],
  "meta": {
    "trace_id": "request-trace-id",
    "pagination": {
      "count": 120,
      "page": 1,
      "pages": 2,
      "page_size": 100,
      "next": "https://api.ourcamps.ru/api/v1/public/accounting/vouchers?page=2&page_size=100",
      "previous": null
    }
  }
}

data может быть объектом или массивом. pagination присутствует только для списков. Денежные значения читайте как десятичные числа без округления через двоичный float; суммы передаются строками с двумя десятичными знаками. null, пустое значение и "0.00" различаются. Ошибки возвращаются с success=false, массивом errors и meta.trace_id. Скачивание договора возвращает двоичный application/pdf, без JSON-обёртки. Успешное удаление пакета возвращает 204 без тела.

Лимит API: 100 запросов в минуту на ключ. Рекомендуемая частота обмена: раз в 5–15 минут; запускайте только один экземпляр задания на подключение.

В журнале 1С сохраняйте время, этап, HTTP-код, trace_id, ID объекта, версию и число созданных/обновлённых/повторных записей. Не записывайте ключи, PDF и паспортные данные в журнал. Ошибка не должна отображаться как успешный обмен с нулём записей.

Соответствия и защита от повторов

Все соответствия принадлежат конкретным окружению, лагерю и ресурсу: одинаковые числовые ID разных ресурсов или лагерей не объединяются. Храните внешний ID и ссылку на документ 1С устойчиво, вместе с результатом обработки. Для повторной записи обновляйте существующий объект. Номер заказа, ФИО, дата, сумма и номер документа не заменяют ID. Ограничение уникальности в регистре соответствий и запрет параллельного запуска должны исключать гонку двух заданий.

Для путёвок и оплат сохраняйте также последнее применённое updated_at источника. Более старый повторный снимок не должен откатывать уже обновлённые данные, а одинаковая версия обрабатывается без повторных движений. Например, старый пакет с pending после нового available не очищает подтверждённые суммы. null при неизвестной комиссии не является командой удалить ранее полученное значение. Договоры сопоставляются по id и version: поля contract.updated_at в ответе нет.

Для PUT документов повтор после сетевого сбоя сохраняет те же ID, редакцию, метаданные и файл. Для POST создания пакета отдельного ключа идемпотентности в контракте нет: повтор может создать ещё один пакет; списка для поиска потерянного пакета тоже нет. Не повторяйте создание неограниченно при потере ответа. Храните полученный ID и не создавайте новый на каждую страницу; соблюдайте лимит активных пакетов.

4. Путёвки и готовые названия

GET /accounting/vouchers?updated_since=2026-09-01T00:00:00Z&page_size=100

Параметры: updated_since (ISO datetime), status=active,refunded, issued_from и issued_to (даты), page, page_size (1–100; по умолчанию 20). Возвращаются выпущенные путёвки и их возвраты; неподтверждённые бронирования сюда не входят.

Поля путёвки

session содержит id, name, starts_at, ends_at, price, nomenclature_name. Например: Морские волки · 01.07.2026–14.07.2026.

parent содержит id, last_name, first_name, middle_name, phone, email, birth_date, passport_series, passport_number, passport_issued_by, passport_issued_date, passport_code, registration_address.

child содержит id, last_name, first_name, middle_name, birth_date, gender, document_type, document_series, document_number. Пол: male/female; документ: passport/birth_certificate либо незаполненное значение. Пол родителя не передаётся. Необязательные персональные поля могут быть пустыми или null.

Как использовать в 1С

• Номенклатуру сопоставляйте по session.id, название берите из session.nomenclature_name.
• Текст строки печатной формы берите из service_description. Это готовое описание услуги; оно может быть сокращено до 128 символов, поэтому не извлекайте из текста отдельные реквизиты лагеря, смены или ребёнка.
• Не создавайте отдельную номенклатуру на каждого ребёнка.
• Изменение названия или дат смены обнаруживается через updated_since и обновляет существующее соответствие. Аналогично учитываются изменения ребёнка, родителя, заказа, лагеря и договора в поддерживаемых путях изменения данных.
• final_price уже содержит применённую скидку. Повторно вычитать её нельзя. В текущей модели итог может включать трансфер; не прибавляйте его второй раз. Комиссия ЮKassa не уменьшает final_price.
• Уже проведённые документы и ранее выданные PDF не перезаписываются автоматически самой платформой. Правило исправлений в 1С определяет бухгалтер лагеря.
• Номер документа реализации назначает 1С. Не заменяйте его order_number или ID платформы.

Даты выпуска путёвки и готовности акта имеют разный смысл. Условие формирования бухгалтерского документа и его дата задаются настройкой обработки 1С по правилам лагеря.

issued_at — выпуск путёвки, а не подтверждение окончания оказания услуги. session.ends_at — дата смены; она сама по себе не является отдельным событием бухгалтерской готовности. Разработчик может автоматизировать подготовку реализации, но условие и дату проведения утверждает бухгалтер.

Несколько позиций заказа и возвраты

Один заказ может содержать несколько путёвок. Каждая строка vouchers относится к одной позиции и несёт собственный order_item_id. Оплата относится ко всему заказу: API оплат не задаёт готовую разбивку по позициям. Обработка должна хранить связь с заказом и применять согласованное правило разнесения, не умножая полную сумму платежа или комиссии на число путёвок. Полного состава и количества ожидаемых позиций заказа этот поток не сообщает: другие путёвки могут появиться позже. Первая строка не означает, что заказ выгружен целиком. Для реализации, объединяющей позиции заказа, нужны устойчивые соответствия по order_item_id и согласованное дозаполнение; неоднозначные суммы направляются на сверку.

Для возврата в текущем контракте доступны status=refunded, refund_amount, refunded_at, refund_reason позиции. refund_amount может быть меньше final_price или равен нулю при удержании; refunded не означает возврат всей стоимости. Это зафиксированное состояние позиции, а не полный журнал последовательных денежных возвратов. Не подставляйте автоматически всю стоимость путёвки и не сторнируйте полную реализацию и комиссию без согласованного основания. Отдельного списка транзакций возвратов, отрицательных оплат и команды перечислить возврат через accounting API нет. Исходные amount, income_amount, fee_total оплаты не становятся суммами за вычетом возвратов. Возврат комиссии или её сторно из этих полей не выводится.

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

5. Оплаты

GET /accounting/payments?updated_since=2026-09-01T00:00:00Z&page_size=100

Параметры: updated_since, date_from, date_to, page, page_size.

Возвращаются успешные оплаты. Инкрементальный отбор выполняется по updated_at: платёж, созданный вчера и подтверждённый сегодня, попадает в сегодняшний обмен. Для дедупликации используйте id, а не дату или сумму.

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

Если путёвка ещё не выпущена, сохраните оплату и связь с order_id в очереди сопоставления. Появление путёвки позже должно дополнить связи, не создавать оплату повторно. Наличие оплаты не является основанием выдумывать отсутствующую реализацию или считать услугу оказанной.

Для cash, terminal, invoice статус not_applicable означает отсутствие сведений о комиссии ЮKassa, а не отсутствие любых банковских/эквайринговых комиссий. Сопоставляйте терминал и оплату по счёту с уже загруженными документами эквайринга/выписки; неоднозначные связи направляйте на сверку. Наличную оплату сопоставляйте с кассовым документом выбранной конфигурации и не создавайте его повторно, если он уже получен другим обменом. Правило «одна фактическая операция — одна запись» действует для всех способов оплаты.

Суммы после удержаний и комиссия ЮKassa

Новые поля добавлены в обычный список оплат и в записи пакетов resource=payments. Существующие amount оплаты и final_price путёвки сохраняют прежний смысл. Обработка 1С должна читать новые поля отдельно, чтобы учитывать комиссию. Для автоматического получения комиссии и дозаполнения старых оплат используйте POST /accounting/sync-batches с resource=payments и сохраняйте next_updated_since после обработки всех страниц; порядок описан в разделе 8.

Пример полей одной оплаты при удержании 305 ₽ с 10 000 ₽:

{
  "amount": "10000.00",
  "income_amount": "9695.00",
  "fee_total": "305.00",
  "income_status": "available"
}

Стоимость реализации и оплата родителя в таком примере остаются 10 000 ₽. 305 ₽ передаются отдельно для учёта удержания ЮKassa; 9 695 ₽ — сумма после удержаний. Конкретные документы, счета и проводки определяет бухгалтер для своей конфигурации 1С. Эти данные не подтверждают дату фактического зачисления денег на расчётный счёт и не заменяют банковскую выписку. Удержанную комиссию не нужно повторно перечислять ЮKassa.

fee_total содержит совокупное удержание. API не разбивает его по видам услуг и НДС: сведения об информационно-технологических услугах, проведении расчётов и НДС берите из реестров и УПД ЮKassa. Нельзя начислять НДС на всё удержание по единой ставке или создавать повторный расход, если комиссия уже учтена другим обменом. Возвраты учитываются отдельно: эти поля не являются суммой платежа за вычетом возвратов.

Одно перечисление — несколько оплат родителей

Оплата родителя и фактическое перечисление на расчётный счёт лагеря — разные события. Если обработка создаёт поступление на счёт по каждой оплате с платформы, а выписка затем добавляет общий перевод платёжного сервиса, поступления задваиваются. Замена amount на income_amount эту ошибку не исправляет.

Пример без возвратов и переходящих остатков: три родителя оплатили по 10 000 ₽. Платформа передаёт три оплаты на общие 30 000 ₽ и три удержания по 305 ₽, всего 915 ₽. Если эти деньги перечислены одним переводом, выписка отражает одно поступление 29 085 ₽. Три дополнительных поступления по 10 000 ₽ или по 9 695 ₽ на счёт лагеря из данных платформы создавать не нужно.

Не формируйте документ фактического поступления суммированием income_amount за вчерашний paid_at: дата оплаты не определяет состав и дату перевода. Выходные, сроки перечислений, возвраты и остатки могут изменять сумму и дату поступления; их подтверждают выписка и сведения провайдера. См. правила перечислений ЮKassa. yookassa_payment_id идентифицирует оплату родителя у провайдера, а не общий перевод.

Контрагента и договор сопоставляйте по реквизитам плательщика в выписке и условиям подключения. Не подставляйте родителя или название «ЮKassa» автоматически: платёжный агрегатор и банк плательщика могут быть разными организациями. Название банка плательщика само по себе не определяет контрагента.

Если расход по комиссии и НДС уже отражаются по УПД ЮKassa, fee_total используется для удержания и сверки, а не для второго начисления того же расхода. Удержание не является новым перечислением лагеря поставщику: не создавайте фиктивное списание поверх фактической выписки.

Настройка документов и счетов в БП

Для карточных оплат в типовой коммерческой «1С:Бухгалтерии 8» применяется документ «Оплата платежной картой» и транзитный счёт 57.03; проводка по дебету 51 относится к фактическому банковскому зачислению. Это пример для конкретной конфигурации, описанный в материале 1С об эквайринге. Если бухгалтер настроил расчёты через 76.09, обработка поддерживает согласованную схему вместо параллельного отражения той же оплаты ещё и через 57.03.

Для СБП и других способов оплаты документ выбирается с учётом версии и настроек БП: method=yookassa само по себе не означает оплату картой. Разработчик и бухгалтер должны согласовать схему для используемой базы; API не задаёт бухгалтерские счета.

Переход с обработки, создававшей лишние поступления

Разработчик 1С должен отключить создание факта поступления на расчётный счёт из каждой оплаты ЮKassa и настроить отдельный учёт оплат через сервис. С бухгалтером проверьте уже созданные документы и их движения; исправляйте или сторнируйте ошибочные поступления по правилам базы и закрытых периодов, сохраняя связи с родителями, заказами и ID оплат. Не удаляйте всю загруженную историю автоматически. Реальное поступление из выписки должно остаться в учёте один раз.

Сохраняйте соответствие payment.id платформы документу оплаты 1С и выполняйте создание или обновление по этому ID. Для комиссии храните связь с той же оплатой; для фактического перечисления используйте идентификаторы самой выписки. Платформа передаёт данные и не исправляет документы или дубли в базе 1С самостоятельно.

Если раньше суммы после удержаний не было

Платформа сохраняет подтверждённую сумму ЮKassa. Если её нет, выгрузка возвращает pending и запускает фоновое получение данных по точному платежу. Фоновое задание также дозаполняет старые успешные оплаты; недоступные данные повторно запрашиваются с паузой. Платформа не подставляет предполагаемый процент, нулевую комиссию или полную сумму вместо неизвестной суммы после удержаний. При неоднозначной связи старой оплаты с платежом или недоступных настройках ЮKassa состояние остаётся pending до устранения причины.

updated_at — техническое время изменения данных, а не дата новой оплаты, банковского поступления или признания расхода по комиссии. Дозаполнение исторического платежа сегодня дополняет его прежнюю запись; оно не создаёт сегодняшнюю реализацию или денежное движение. Период расхода и НДС определяется первичными документами и правилами бухгалтера. Сумма fee_total за месяц по paid_at не обязана совпадать с УПД того же месяца: расхождение направляется на сверку, а не списывается автоматически.

После успешного получения данных обновляется updated_at записи оплаты. Она повторно попадает в инкрементальный обмен с тем же id. Обработка должна обновить существующую оплату и связанную комиссию, сохранив исходную сумму оплаты. Для операции комиссии используйте устойчивое соответствие с id оплаты на платформе; yookassa_payment_id позволяет сверять её с ЮKassa и другими загрузками. Повторная выдача записи не должна создавать вторую оплату или вторую комиссию.

Страницы уже созданного пакета неизменны: запись с pending внутри него не станет available. Сохраните результат пакета и его next_updated_since, затем создайте следующий пакет с этой границей. Полученные позже суммы придут как обновление оплаты. Не нужно удерживать весь обмен в ожидании комиссии. Если параллельно используется штатный модуль ЮKassa в 1С или загрузка банковской выписки, настройте сопоставление операций и исключите дубли.

vat_code и tax_system_code относятся к данным услуги/лагеря. Их маппинг и исторические значения должны поддерживаться обработкой; НДС с комиссии эквайера не берётся из vat_code путёвки.

6. PDF договоров в 1С

GET /accounting/contracts?updated_since=2026-09-01T00:00:00Z&page_size=100

Этот список возвращает созданные индивидуальные договоры лагеря независимо от режима оформления и наличия уже выпущенной путёвки. Параметры: updated_since, page, page_size. Готовая публичная оферта лагеря не является индивидуальным договором и этим маршрутом не выдаётся.

Поддерживаются оба сценария:

1. Договор подписан онлайн: выгружается подписанный PDF из сервиса подписи.
2. Включена дополнительная генерация договоров, в том числе при публичной оферте: выгружается созданный PDF. Для получения файла не требуется онлайн-подпись.

Метаданные договора

GET /accounting/contracts/{id}/file?version={version}
X-API-Key: YOUR_CAMP_API_KEY

Передавайте ключ и при скачивании PDF. Файл хранится в 1С как вложение к соответствующему договору/продаже. version не является SHA-256 содержимого PDF; сравнивайте её как непрозрачный идентификатор изменения.

Если версия изменилась между чтением списка и скачиванием, API вернёт 409. Получите актуальный список/метаданные и повторите запрос. Если сервис подписи недоступен, API вернёт 503; подписанный экземпляр не подменяется неподписанным.

Сформированный для очной подписи договор не считается подписанным только потому, что существует PDF. file_variant=generated может также относиться к подписи, зарегистрированной вручную: этот файл остаётся исходным созданным экземпляром, а не сканом подписанного документа.

Договоры синхронизируйте отдельным потоком. Так договор, созданный после загрузки продажи, не потеряется. Для вложений ведите соответствие contract.id + version; обновляйте вложение по правилам хранения редакций в вашей 1С.

7. Автоматическая отправка актов и УПД

Обработка 1С автоматически ставит документ в очередь отправки после проведения/готовности выбранной печатной формы. Отдельного подтверждения на платформе нет. Расписание обработки выбирает лагерь; рекомендуем 5–15 минут.

Точный критерий готовности задайте в 1С: печатная форма должна быть готова к просмотру сотрудниками лагеря. Черновики в этот поток не отправляются. Изменение печатной формы увеличивает revision; отмена проведения или удаление ранее опубликованной формы отправляет отзыв. Эти события должны сохраняться в очереди до подтверждения API.

Этот поток содержит акты и УПД лагеря по заказам, доступные сотрудникам в панели лагеря. Входящие УПД ЮKassa за комиссию не загружаются этим API и не должны привязываться к родительским заказам.

Адрес

PUT /accounting/documents/{kind}/{external_id}

• kind: act (акт оказания услуг) либо upd (УПД).
• external_id: GUID документа 1С, неизменный при повторах.
• source_id: постоянный GUID базы/подключения 1С, хранится в настройках. При замене API-ключа не меняется.

Акт и УПД одной реализации могут использовать одинаковый external_id: тип входит в ключ уникальности. Отправляйте только реально используемые печатные формы. API сохраняет документы и не создаёт повторную реализацию, оплату или чек. Он не проверяет бухгалтерскую правильность суммы PDF или её равенство стоимости позиций: эти проверки выполняет обработка 1С.

Публикация: multipart/form-data

Передайте поле metadata с JSON-строкой и поле file с двоичным PDF. Boundary устанавливается отправителем HTTP-запроса. В metadata:

{
  "source_id": "22222222-2222-4222-8222-222222222222",
  "revision": 1,
  "status": "published",
  "number": "ACT-000123",
  "date": "2026-09-15",
  "amount": "40000.00",
  "currency": "RUB",
  "order_item_ids": [42]
}

Все данные примера синтетические. order_item_ids берутся из выгрузки платформы; случайные номера использовать нельзя.

Ограничения PDF: до 20 МиБ, 1–500 страниц, без пароля, корректный PDF. Файл Base64 в JSON не поддерживается. Не отправляйте сводный документ разных заказов или родителей.

Ответ

{
  "success": true,
  "data": {
    "applied": true,
    "received_revision": 1,
    "document": {
      "id": "33333333-3333-4333-8333-333333333333",
      "source_id": "22222222-2222-4222-8222-222222222222",
      "external_id": "11111111-1111-4111-8111-111111111111",
      "kind": "act",
      "kind_display": "Акт оказания услуг",
      "order_id": 15,
      "order_item_ids": [42],
      "number": "ACT-000123",
      "date": "2026-09-15",
      "amount": "40000.00",
      "currency": "RUB",
      "revision": 1,
      "status": "published",
      "status_display": "Доступен",
      "sha256": "0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef",
      "created_at": "2026-09-15T12:00:00Z",
      "updated_at": "2026-09-15T12:00:00Z"
    }
  },
  "meta": {"trace_id":"request-trace-id"}
}

sha256 фактически содержит 64 шестнадцатеричных символа, вычисленных сервером по файлу. applied=false означает, что идентичная версия уже принята. Это успешный результат. Поле document показывает текущую версию: она может быть новее повторно отправленной.

Повтор, исправление и отзыв

• Ключ документа: лагерь + source_id + kind + external_id; смена API-ключа его не меняет.
• Повтор той же версии с теми же метаданными и PDF не создаёт дубликат.
• Та же версия с другим содержимым возвращает 409. Увеличьте revision.
• Новая версия сохраняется с историей предыдущих файлов.
• Повтор уже принятой старой версии подтверждается, но не откатывает текущий документ.
• Ранее не принятая редакция не выше текущей возвращает 409. Неизвестный документ нельзя отозвать.
• Перепривязка к другим позициям запрещена. Отзовите ошибочный документ и создайте новый external_id.

Отзыв: тот же PUT, JSON без файла. Передайте полные метаданные, увеличенную версию и status=revoked:

{
  "source_id": "22222222-2222-4222-8222-222222222222",
  "revision": 2,
  "status": "revoked",
  "number": "ACT-000123",
  "date": "2026-09-15",
  "amount": "40000.00",
  "currency": "RUB",
  "order_item_ids": [42]
}

В панели лагеря остаётся запись Отозван, открыть PDF нельзя. Ранее выданная краткоживущая ссылка может работать до истечения её срока (до 5 минут). Уже скачанные пользователем копии удалить невозможно. Повторная публикация после отзыва требует новой версии и PDF.

8. Надёжная постраничная синхронизация

Обычные списки сохранены для совместимости. Для нового регламентного обмена используйте отдельные пакеты каждого ресурса. Для автоматического обмена оплатами и комиссией используйте пакеты resource=payments: содержимое страниц фиксируется на момент создания пакета и не меняется при параллельном редактировании данных.

Обычный GET /accounting/payments использует страницы и сортировку по updated_at. Если между запросами изменяются оплаты, в том числе при переходе pending → available, записи могут переместиться между страницами и часть оплат может быть пропущена. Такой обход не гарантирует полноту при параллельных изменениях и не подходит для надёжного автоматического дозаполнения истории. Пакеты устраняют перемещение записей внутри конкретной выгрузки; обработка 1С всё равно должна выполнять создание или обновление по id, чтобы исключать дубли между запусками.

Создать пакет

POST /accounting/sync-batches
Content-Type: application/json

{"resource":"payments","updated_since":"2026-09-01T00:00:00Z"}

resource: vouchers, payments, contracts. При первом запуске updated_since опускается. Создавайте отдельный пакет и храните отдельную границу для каждого ресурса.

Ответ 201 содержит метаданные, а не первую страницу записей. Поля data: id, resource, count, started_at, next_updated_since, expires_at, page_url. Чтение по page_url использует общий формат data и meta.pagination; page_size по умолчанию 20, максимум 100.

1. Получить page_url с ключом, при желании добавить page_size=100.
2. Обработать все страницы по meta.pagination.next.
3. Завершить загрузку необходимых PDF; при ошибке сохранить её в устойчивой очереди повтора либо не завершать пакет.
4. Только после устойчивого сохранения всех результатов записать next_updated_since как новую границу этого ресурса.
5. Удалить пакет: DELETE /accounting/sync-batches/{id}.

Не подставляйте время окончания обработки с часов компьютера 1С. next_updated_since содержит время начала серверного запуска с перекрытием 5 минут. Повторяющиеся записи в этом интервале нормальны: они обрабатываются по ID/версии.

Пакет доступен 24 часа. После истечения создайте новый с прежней успешно сохранённой границей. Максимум: 10 неистёкших пакетов на лагерь суммарно по всем ключам и ресурсам, 10 000 записей в одном пакете. Превышение лимита возвращает 400, а не усечённую успешную выдачу. POST принимает resource и updated_since; разбиения через date_from/date_to в JSON пакета нет. Повторное удаление уже отсутствующего пакета возвращает 204. Просроченные пакеты удаляются фоновым заданием и при следующем создании пакета этого лагеря.

Если первичная загрузка превышает 10 000 записей, согласуйте с поддержкой порядок получения полной истории до запуска автоматического обмена; обычный список страниц при параллельных изменениях не обеспечивает её полноту. Для контроля делайте периодическую полную сверку ID, количества и сумм: пакет фиксирует страницы, но не заменяет сверку и не гарантирует учёт произвольных изменений БД вне штатных путей приложения.

Не запускайте создание нескольких пакетов одного ресурса параллельно. В ссылках переходов проверяйте ожидаемый API-origin перед передачей ключа.

9. Что увидят сотрудники лагеря

В карточке заказа появляется блок Акты и УПД. Он содержит тип, номер, дату и редакцию документа. Для опубликованных документов доступно Открыть; документ можно распечатать отдельно или включить в комплект заказа или отряда. Отозванные видны с соответствующей отметкой.

Документ привязан к заказу и его позициям. Сотрудник видит акты и УПД только в заказах доступного ему лагеря. В ЛК родителя они недоступны, в том числе в комплекте документов. Общие документы нескольких разных заказов не принимаются.

После доработки обработки новые редакции поступают автоматически из 1С. Для просмотра обновлённого состояния откройте заказ заново или обновите страницу. Изменять бухгалтерский PDF следует в 1С, затем отправлять новую редакцию; наша платформа его не перегенерирует.

10. Техническое задание разработчику 1С

Этап 1. Согласовать настройки и обследовать старую обработку

1. Зафиксировать профиль подключения из раздела 2 для базы БП. Бухгалтер утверждает виды документов, счета/аналитику, условия реализации, авансы, комиссию, НДС и автоматическое проведение.
2. Найти все источники загрузки оплат: прежняя обработка для платформы, модуль ЮKassa, банковский обмен, ручной ввод. Определить единственный источник каждой операции и правила сопоставления.
3. Описать действующие соответствия внешних ID и проверить, не создаются ли из каждой оплаты родителя отдельные поступления на счёт лагеря.

Готовность этапа: согласованы профиль базы БП, владельцы потоков, правила проведения и исправления истории.

Этап 2. Реализовать устойчивый обмен и документы

4. Реализовать проверку /accounting/connection, отдельные границы для vouchers, payments, contracts, пакеты и восстановление по правилам раздела 8. Рекомендуемое расписание — раз в 5–15 минут, один запуск на подключение.
5. Создать устойчивые регистры соответствий из раздела 3. Повтор пакета, страницы или записи должен обновлять существующее соответствие. Границу продвигать только после устойчивого сохранения результатов всех страниц или их собственной очереди обработки.
6. Подготавливать данные реализации из путёвок по полной final_price, без повторного вычитания скидки и без уменьшения на комиссию. Проведение и дата — по утверждённому профилю; существующие проведённые документы исправлять только разрешённым способом.
7. Загружать каждую оплату на полную amount по payment.id, связывать с заказом и родителем. Для ЮKassa отражать расчёты с сервисом без создания фактического поступления на расчётный счёт. Для остальных способов применять профиль из раздела 5: сопоставлять наличные с кассовыми документами, терминал/счёт — с соответствующим эквайринговым или банковским учётом. Неразнесённую оплату сохранять в очереди сопоставления.
8. При available сохранять income_amount и fee_total, дополнять связанную оплату и сведения для удержания/сверки. При pending хранить неизвестные суммы и продолжать обмен; ждать обновления по тому же ID. При not_applicable не формировать комиссию ЮKassa. Реальный ноль обрабатывать как ноль.
9. Загружать версии PDF договоров с авторизацией, сохранять вложения и проверять конфликт версии. Хранить устойчивую очередь исходящих актов/УПД с постоянными ID и редакциями, включая исправления и отзыв; повторять сетевые ошибки без изменения содержимого той же редакции.
10. Реализовать журнал и список исключений: неразнесённые оплаты, отсутствующие суммы комиссии, конфликты версий, закрытые периоды, неподтверждённые возвраты и ошибки доступа. Ошибки одного объекта не должны тихо исчезать вместе с продвижением границы.

Готовность этапа: повторный полный и инкрементальный обмен не создаёт дублей; сбой между сохранением документа и подтверждением запроса восстанавливается по ID.

Этап 3. Подключить внешние финансовые потоки

11. Настроить отдельную загрузку банковской выписки доступным модулем 1С. Согласовать входящие остатки расчётов с сервисом и источники движений, которых нет в API оплат, в том числе собственных пополнений лагеря для возвратов. Полный остаток и закрытие периода нельзя вывести только из оплат и комиссии. Поступление отражать один раз по фактическому переводу, с суммой, датой и реквизитами из выписки. Не группировать платежи за вчерашний paid_at в выдуманное перечисление.
12. Для автоматической сверки перевода с группой оплат согласовать отдельный источник реестров и алгоритм сопоставления. Действующий accounting API не выдаёт состав перечисления; одних income_amount для полной сверки недостаточно. Загрузка реестров/SFTP платформой в этом ТЗ не считается реализованной.
13. Подключить входящие УПД ЮKassa через существующий ЭДО, импорт или рабочий процесс бухгалтера. Виды услуг и НДС брать из этих документов/реестров. Исключить повторный расход между учётом удержания и обработкой УПД.
14. Настроить исключения возвратов. Сверять фактические денежные движения отдельно; не создавать возврат по банковскому счёту, сторно комиссии или НДС только из прежней суммы платежа либо статуса путёвки.

Готовность этапа: для одного перевода, нескольких оплат и входящего УПД объясним остаток расчётов с сервисом; каждая фактическая денежная операция и расход отражены один раз. Если внешние источники не подключены, эти действия остаются отдельной работой бухгалтера и не обозначаются автоматизированными.

Этап 4. Исправить историю и включить рабочий обмен

15. На копии базы составить перечень ошибочных поступлений, их проводок/движений и связей с реальными выписками. С бухгалтером согласовать способ исправления по периодам; не удалять массово оплаты, реализации и реальные банковские документы.
16. Перенести или сохранить соответствия payment.id, voucher.id, order_id, order_item_id, идентификаторы документов 1С и связи вложений. Отдельно сохранить постоянный source_id публикаций.
17. Исправить лишние поступления разрешёнными документами/сторно с контролем закрытых периодов. После перехода оставить фактическую выписку в учёте один раз, а оплату родителя — в расчётах с сервисом.
18. Выполнить первичную загрузку пакетами, затем догрузку изменений по серверным границам. Проверить старые оплаты с неизвестной комиссией: после фонового дозаполнения они должны обновить те же объекты.
19. Сверить ID, количество и суммы по согласованному периоду, пройти раздел 12, включить расписание. Передать бухгалтеру список оставшихся исключений и инструкцию их исправления.

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

11. Что будет работать автоматически, а что остаётся бухгалтеру

Это автоматизация конкретных потоков, а не полная бухгалтерия без участия бухгалтера. Возможности обработки из ТЗ начинают работать только после её разработки, настройки и приёмки в конкретной базе.

Бухгалтеру не нужно вручную перепечатывать каждую штатную оплату, если обмен настроен и принят. Он утверждает учётную схему, контролирует исключения и сверку, работает с первичными документами провайдера, закрытием месяца и отчётностью. Отдельные возможности 1С/ЭДО могут автоматизировать часть этой работы, но они не входят автоматически в данную интеграцию.

12. Приёмочные сценарии

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

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

В действующий контракт не входят выставление счетов из 1С, подтверждение банковских оплат из 1С и команды фактического возврата денег. Акты и УПД передаются как PDF; обмен титулами ЭДО/XML и подписание документов на платформе этим протоколом не выполняются. Полученные PDF не меняют оплату, кассовые чеки и сумму заказа.