При автоматизации розничной и оптовой торговли часто возникает необходимость принимать оплату от клиентов поэтапно. В конфигурации 1С:Управление торговлей 11 (УТ 11) этот механизм реализован через планирование этапов оплаты в документе Заказ клиента. На основании заказа создаются платежные документы — Приходный кассовый ордер (ПКО) или Эквайринговая операция, из которых пробиваются чеки на фактически полученную сумму. Однако при использовании портативных касс семейства «Меркурий» (в частности, Меркурий 185Ф) в режиме фискального регистратора пользователи часто сталкиваются со следующей проблемой: касса вместо суммы фактического платежа печатает в чеке полную стоимость заказа, тем самым задваивая выручку по отчетам ККТ.
В этой статье мы подробно разберем, почему возникает этот технический конфликт между учетной системой 1С и кассовым аппаратом, проанализируем структуру XML-пакета обмена и рассмотрим все возможные варианты решения данной проблемы.
Для начала проанализируем, как строится взаимодействие между программой 1С и кассовым аппаратом Меркурий 185Ф. Данное устройство изначально разрабатывалось как автономная кнопочная касса. Функция работы в режиме фискального регистратора (ФР) была добавлена разработчиками («Инкотекс») программным путем через службу-драйвер INECRMAN.
Когда мы нажимаем кнопку «Пробить чек» в документе Приходный кассовый ордер, система 1С формирует XML-пакет по стандарту требований ФНС (ФФД 1.05 или 1.2) и отправляет его драйверу ККТ. Драйвер должен перевести этот XML в низкоуровневые команды процессора кассы.
Давайте рассмотрим структуру реального XML-пакета, который 1С отправляет на кассу при попытке пробить первый этап предоплаты (например, клиент вносит 4 рубля за товар стоимостью 10 рублей):
<?xml version="1.0" encoding="UTF-8"?>
<CheckPackage>
<Parameters PaymentType="1"
TaxVariant="3"
CashierName="Администратор"
CashierVATIN=""
CustomerEmail=""
CustomerPhone=""
AddressSettle="...">
<AgentData/>
<PurveyorData/>
</Parameters>
<Positions>
<FiscalString Name="DIN-рейка (10см) оцинкованная"
Quantity="1"
PriceWithDiscount="10"
SumWithDiscount="10"
DiscountSum=""
Department="1"
Tax="none"
SignMethodCalculation="2"
SignCalculationObject="10">
<AgentData/>
<PurveyorData/>
</FiscalString>
</Positions>
<Payments Cash="4"
ElectronicPayment="0"
Credit="6"
AdvancePayment="0"
CashProvision="0"/>
</CheckPackage>
Проанализируем этот XML-пакет:
Positions (позиции чека) указан товар стоимостью 10 рублей: PriceWithDiscount="10" и SumWithDiscount="10".SignMethodCalculation="2" указывает на признак способа расчета «Частичная предоплата» (согласно ФФД).Payments (оплаты) платеж четко разделен: наличными получено 4 рубля (Cash="4"), а оставшиеся 6 рублей уходят в постоплату/кредит (Credit="6").С точки зрения платформы 1С и требований законодательства XML сформирован абсолютно корректно. Однако процессор ККТ «Меркурий» со старой версией прошивки или некорректным драйвером INECRMAN не умеет правильно обрабатывать тег Credit в секции оплат. Вместо того чтобы закрыть чек на фактически полученные 4 рубля наличных и зафиксировать 6 рублей долга, касса игнорирует кредитную часть и закрывает весь чек на полную сумму позиций (10 рублей) по первому доступному типу оплаты (наличные). В результате покупатель получает чек, где написано, что он оплатил 10 рублей наличными, а в фискальном накопителе фиксируется неверная сумма выручки.
Самый правильный с точки зрения закона путь — заставить оборудование корректно понимать команды 1С. Для этого необходимо выполнить комплексное обновление программного обеспечения кассы:
Рабочем месте кассира (РМК).Если обновить прошивку кассы не получается или это не привело к желаемому результату из-за аппаратных ограничений процессора ККТ, мы можем изменить саму схему формирования чека в 1С. Этот способ позволяет избежать передачи сложных тегов кредита в кассу.
Посмотрим, как работает этот метод по шагам:
Cash="4". Кредитная часть чека будет равна нулю (Credit="0"). Касса Меркурий без проблем распечатает такой чек, так как ей не придется делить сумму.Реализация товаров и услуг. Из него пробивается финальный чек. В этом чеке будут перечислены все реальные товары на общую сумму 10 рублей, но в качестве оплаты будет указано: AdvancePayment="4" (зачет предоплаты) и Cash="6" (доплата наличными, если клиент вносит остаток). Финальный чек закроется корректно, так как зачет авансов поддерживается большинством прошивок ККТ «Меркурий» гораздо стабильнее, чем операции с кредитом.Многие интеграторы, устав от нестабильной работы стандартной службы INECRMAN, переводят портативные кассы на работу через альтернативный софт. Одним из наиболее популярных решений является утилита KKMServer.
Рассмотрим, как это работает:
Этот способ позволяет добиться стабильной работы РМК и корректных сумм в чеке без необходимости влезать в программный код конфигурации 1С:УТ 11.
Проанализировав опыт многих внедрений, необходимо признать: портативные кассы (такие как Меркурий 185Ф, 115Ф) создавались для автономной работы курьеров или в небольших торговых точках, где кассир вручную набивает сумму на кнопках. Использование их в качестве полноценных фискальных регистраторов в связке с тяжелыми учетными системами уровня 1С:УТ 11 всегда сопряжено с компромиссами и рисками регулярных сбоев.
Если ваш бизнес предполагает регулярные сложные расчеты (частичная предоплата, кредиты, зачеты авансов, подарочные сертификаты), мы настоятельно рекомендуем рассмотреть возможность замены кассового аппарата на полноценный фискальный регистратор, разработанный специально для работы под управлением ПК (например, линейки Атол-30Ф, Атол-27Ф или устройства марки Штрих-М).
Такое оборудование: