Как исправить ошибку ФЛК 512 при формировании чека коррекции возврата прихода через JSON API в 1С?

Коллеги, сталкиваясь с интеграцией 1С и онлайн-касс через JSON API, мы часто можем встретить специфические ошибки форматно-логического контроля (ФЛК), особенно при работе со сложными типами чеков, такими как чеки коррекции возврата прихода. Рассмотрим подробнее ситуацию, когда при отправке такого чека в СБИС ОФД (Оператор Фискальных Данных) возникает ошибка ФЛК 512 с формулировкой: "неправильно указана сумма кредита (тег 1216 'Сумма по чеку (БСО) постоплата (в кредит)')". Эта проблема характерна для доработанных конфигураций, таких как 1С:УПП, использующих кастомные обработки для взаимодействия с кассой через JSON. В качестве альтернативы самописной интеграции можно применить готовую обработку для работы с ККТ АТОЛ через веб-сервер с поддержкой ФФД 1.2.

Анализируем исходный запрос JSON

Для начала, давайте внимательно проанализируем структуру JSON-запроса, который привел к ошибке. Предположим, мы отправляем следующий запрос:

{
"uuid": "d4f68c1c-d67a-4f81-867a-7417056f9159",
"request": [
    {
   "type": "sellReturnCorrection",
    "validateMarkingCodes": false,
    "electronically": false,
   "useVAT18": false,
"correctionType": "self",
"correctionBaseDate": "2022.12.07",
"taxationType": "osn",
"clientInfo": {
    "emailOrPhone": ""
              },
   "operator": {
       "name": "ИМЯ_ФАМИЛИЯ ",
       "vatin": ""
                 },
    "items":  
              [
       {
           "type": "position",
           "name": "КОЛБАСА",
           "price": 204.8,
           "quantity": 20,
           "measurementUnit": "piece",
           "amount": 4096,
           "department": 1,
           "paymentMethod": "credit",
           "paymentObject": "commodity",
           "tax": {
               "type": "vat10"
                    }
      
       }
       ,{
           "type": "additionalAttribute",
           "value": "3915...НОМЕР_ФПД",
           "print": true
            }
      
              ],
   "payments": [
                    {
                    "type": "credit",
                    "sum": 4096
                    }
                 ]
          }
]
}

В этом запросе мы видим, что:

1. Мы формируем чек типа "sellReturnCorrection" (коррекция возврата прихода), что соответствует ФФД 1.2.
2. Указываем общую систему налогообложения "taxationType": "osn" и тип коррекции "correctionType": "self" (самостоятельная).
3. В позициях товаров ("items") для "КОЛБАСА" указан "paymentMethod": "credit".
4. В блоке "payments" также указан тип оплаты "credit" с суммой 4096.
5. Присутствует "additionalAttribute" для номера ФПД, что правильно для связки с исходным чеком.

Несмотря на то, что сумма кредита присутствует в блоке payments, ОФД СБИС выдает ошибку по тегу 1216. Разберем, почему это происходит и как это исправить.

Причина ошибки ФЛК 512: Отсутствие или некорректное указание тега 1216 (`creditSum`)

Ошибка "неправильно указана сумма кредита (тег 1216)" возникает потому, что оператор фискальных данных (ОФД), в данном случае СБИС, ожидает явного указания общей суммы оплаты в кредит для всего чека коррекции. Даже если детализация платежей присутствует в массиве "payments", многие ОФД и требования ФФД 1.2 предусматривают отдельные агрегированные поля для сумм по различным типам оплаты на верхнем уровне JSON-объекта чека.

Согласно документации СБИС API для чеков коррекции (и общим принципам ФФД 1.2), для корректной фискализации чека коррекции необходимо передавать поле "creditSum" (что соответствует тегу 1216) на том же уровне, что и другие агрегированные суммы (например, totalSum, cashSum, electronSum, prepaySum).

Шаги по исправлению:

1. Добавьте поле "creditSum": В основной JSON-объект чека, рядом с такими полями как "taxationType", "correctionType" и т.д., добавьте поле "creditSum", значение которого должно быть равно общей сумме оплаты в кредит по чеку.
2. Укажите общую сумму чека: Для чеков коррекции, как правило, также необходимо указывать общую сумму чека в поле "totalSum". Эта сумма должна быть равна сумме всех позиций в чеке.

Пример модифицированного JSON-запроса:

{
"uuid": "d4f68c1c-d67a-4f81-867a-7417056f9159",
"request": [
    {
   "type": "sellReturnCorrection",
    "validateMarkingCodes": false,
    "electronically": false,
   "useVAT18": false,
"correctionType": "self",
"correctionBaseDate": "2022.12.07",
"taxationType": "osn",
"totalSum": 4096,   // <--- Добавлено: Общая сумма чека
"creditSum": 4096,  // <--- Добавлено: Общая сумма по кредиту (Тег 1216)
"clientInfo": {
    "emailOrPhone": ""
              },
   "operator": {
       "name": "ИМЯ_ФАМИЛИЯ ",
       "vatin": ""
                 },
    "items":  
              [
       {
           "type": "position",
           "name": "КОЛБАСА",
           "price": 204.8,
           "quantity": 20,
           "amount": 4096,
           "department": 1,
           "paymentMethod": "credit",
           "paymentObject": "commodity",
           "tax": {
               "type": "vat10"
                    }
      
       }
       ,{
           "type": "additionalAttribute",
           "value": "3915...НОМЕР_ФПД",
           "print": true
            }
      
              ],
   "payments": [
                    {
                    "type": "credit",
                    "sum": 4096
                    }
                 ]
          }
]
}

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

Взаимосвязь тегов 1214 и 1216: Суммы аванса и кредита

В дополнительной информации мы видим упоминание о взаимосвязи тегов 1214 (Сумма по чеку (БСО) предварительная оплата (аванс)) и 1216 (Сумма по чеку (БСО) постоплата (в кредит)). Действительно, ФНС и ОФД могут устанавливать правила, по которым эти теги взаимодействуют. Например, если тег 1214 отсутствует или равен нулю, то тег 1216 также должен быть либо пустым, либо равным нулю, если речь идет о чеке, в котором аванс или кредит не участвуют как агрегированный тип оплаты. Однако, в нашем случае, мы имеем дело с коррекцией возврата прихода, который был ранее в кредит. Поэтому, если общая сумма чека коррекции связана с кредитной оплатой (возвращается "кредитный" приход), то указание creditSum (тег 1216) вполне оправдано и необходимо. Отсутствие prepaySum (тег 1214) в этом контексте логично, так как операция не связана с авансом.

Формат сумм: рубли или копейки?

Одна из наиболее распространенных причин ошибок ФЛК, которую часто упускают из виду, — это неправильный формат денежных сумм. Многие API ОФД, включая СБИС, и протоколы ККТ ожидают, что денежные суммы (цены, общие суммы, налоги) будут переданы в копейках и исключительно целыми числами. В нашем исходном запросе мы видим:

• "price": 204.8
• "amount": 4096
• "sum": 4096 (в блоке "payments")

Если СБИС или АТОЛ ожидают суммы в копейках, то эти значения должны быть преобразованы. Например:

• "price": 204.8 должно стать 20480 (204 рубля 80 копеек)
• "amount": 4096 должно стать 409600 (4096 рублей 00 копеек)
• "sum": 4096 (в "payments") также должно стать 409600
• Аналогично, "totalSum": 4096 и "creditSum": 4096 должны быть 409600

Мы настоятельно рекомендуем проверить документацию используемого API (СБИС/АТОЛ) относительно ожидаемого формата денежных сумм. Это критически важный момент, который может быть скрытой причиной множества ошибок.

Пример JSON с суммами в копейках:

{
"uuid": "d4f68c1c-d67a-4f81-867a-7417056f9159",
"request": [
    {
   "type": "sellReturnCorrection",
    "validateMarkingCodes": false,
    "electronically": false,
   "useVAT18": false,
"correctionType": "self",
"correctionBaseDate": "2022.12.07",
"taxationType": "osn",
"totalSum": 409600,   // <--- Общая сумма чека в копейках
"creditSum": 409600,  // <--- Общая сумма по кредиту в копейках
"clientInfo": {
    "emailOrPhone": ""
              },
   "operator": {
       "name": "ИМЯ_ФАМИЛИЯ ",
       "vatin": ""
                 },
    "items":  
              [
       {
           "type": "position",
           "name": "КОЛБАСА",
           "price": 20480,       // <--- Цена в копейках
           "quantity": 20,
           "amount": 409600,     // <--- Сумма позиции в копейках
           "department": 1,
           "paymentMethod": "credit",
           "paymentObject": "commodity",
           "tax": {
               "type": "vat10"
                    }
      
       }
       ,{
           "type": "additionalAttribute",
           "value": "3915...НОМЕР_ФПД",
           "print": true
            }
      
              ],
   "payments": [
                    {
                    "type": "credit",
                    "sum": 409600 // <--- Сумма оплаты в копейках
                    }
                 ]
          }
]
}

Способ оплаты "Встречное предоставление" для чеков коррекции (тег 1217)

Для чеков коррекции существует еще один важный нюанс, касающийся способа оплаты. Если по сути исправления не происходит фактического движения денежных средств (то есть, деньги клиенту не возвращаются или не принимаются заново, а лишь корректируется ранее ошибочно проведенный расчет), то Федеральная налоговая служба (ФНС) рекомендует указывать способ оплаты "встречное предоставление" (тег 1217). Это особенно актуально, когда происходит исправление ошибки в учете, но не физический возврат денег.

В вашем случае, "type": "sellReturnCorrection" и использование "credit" в items и payments предполагает, что мы корректируем возврат прихода, который был связан с кредитной операцией. Если это действительно означает, что мы "отменяем" кредитный приход (т.е. уменьшаем задолженность клиента, если он не оплатил, или корректируем данные о полученных средствах, если они были получены в кредит), то "credit" может быть правильным. Однако, если сама операция "коррекции" не влечет за собой движение денег, а просто исправляет фискальные данные, то стоит рассмотреть изменение "paymentMethod" и "type" на "reciprocalProvision" (встречное предоставление), а соответствующая сумма будет указана в "reciprocalProvisionSum" вместо "creditSum". Это более тонкий момент, требующий точного понимания бизнес-логики корректируемой операции.

Пример использования "Встречного предоставления":

// Фрагмент чека
...
"items": [
    {
       "type": "position",
       "name": "КОЛБАСА",
       "price": 20480,
       "quantity": 20,
       "amount": 409600,
       "department": 1,
       "paymentMethod": "reciprocalProvision", // <--- Изменено на встречное предоставление
       "paymentObject": "commodity",
       "tax": {
           "type": "vat10"
       }
    }
],
"payments": [
    {
       "type": "reciprocalProvision", // <--- Изменено на встречное предоставление
       "sum": 409600
    }
],
"totalSum": 409600,
"reciprocalProvisionSum": 409600 // <--- Новое поле для встречного предоставления
...

Мы рекомендуем использовать "reciprocalProvision", если по факту нет движения денег, а только коррекция данных. Если же вы буквально корректируете возврат по ранее оформленному кредиту, то "credit" с указанием "creditSum" может быть корректным. Всегда сверяйтесь с разъяснениями ФНС и ОФД по вашей конкретной ситуации.

Дополнительные важные аспекты ФФД 1.2 для чеков коррекции

Помимо вышеперечисленного, рассмотрим другие аспекты, которые влияют на успешность фискализации чеков коррекции по ФФД 1.2:

1. Фискальный признак документа (ФПД) исходного чека (тег 1192): Для чеков коррекции ФФД 1.2 критически важно указывать фискальный признак (ФПД или ФП) ошибочного чека, который корректируется. В вашем запросе вы уже используете "type": "additionalAttribute" с полем "value": "3915...НОМЕР_ФПД". Это правильный подход для передачи тега 1192 в дополнительных реквизитах чека коррекции и связки его с исходным документом.
2. Признак расчета для чеков коррекции: Важно, чтобы "type": "sellReturnCorrection" соответствовал сути операции. В ФФД 1.2, если исправляется ошибка в "приходе" (продаже), то чек коррекции должен быть "возврат прихода". Если первоначальный расчет был "возврат прихода", то чек коррекции должен быть "приход". Ваш выбор "sellReturnCorrection" соответствует логике возврата прихода.
3. Актуальность программного обеспечения: Устаревшее программное обеспечение 1С (особенно доработанные обработки) или прошивка кассового аппарата могут содержать ошибки или не поддерживать все нюансы ФФД 1.2 и API ОФД. Мы настоятельно рекомендуем убедиться, что все компоненты системы (1С, драйвер ККТ, прошивка ККТ) обновлены до актуальных версий, рекомендованных производителями.

Рекомендации по устранению ошибки

Итак, чтобы устранить ошибку ФЛК 512, мы рекомендуем выполнить следующие шаги:

1. Шаг 1: Добавьте агрегированные суммы. В основной объект JSON-запроса чека коррекции добавьте поля "totalSum" и "creditSum" (тег 1216), указывая в них общую сумму чека и общую сумму по постоплате (в кредит) соответственно.
2. Шаг 2: Проверьте формат сумм. Убедитесь, что все денежные суммы в JSON-запросе (price, amount, sum в payments, totalSum, creditSum) передаются в копейках и являются целыми числами. Это частая причина ошибок, не всегда очевидная на первый взгляд.
3. Шаг 3: Проверьте способ оплаты. Перепроверьте, действительно ли для вашей бизнес-логики подходит "credit" в качестве способа оплаты для коррекции. Если фактически денежные средства не возвращаются, а лишь исправляется ошибка в учете, рассмотрите использование "reciprocalProvision" (встречное предоставление) с соответствующим полем "reciprocalProvisionSum" (тег 1217).
4. Шаг 4: Обновите ПО. Убедитесь, что все компоненты интеграции (модуль 1С, драйвер кассы, прошивка кассы) актуальны.

После внесения этих изменений в вашу обработку 1С, формирующую JSON-запрос, и повторной отправки чека, проблема с ошибкой ФЛК 512 должна быть устранена. Мы советуем внимательно изучить актуальную документацию СБИС API и спецификацию ФФД 1.2, так как требования могут обновляться. Для отладки формирования чеков без реальной фискализации можно использовать эмулятор ККТ с поддержкой ФФД 1.2 для обычных форм.