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