Интеграция CRM и АТОЛ

Интеграция CRM с АТОЛ нужна, чтобы кассовый чек уходил покупателю автоматически при оплате заказа, а не пробивался руками бухгалтером или менеджером. Технически это связка либо с облачной кассой по API, либо с локальной кассой через веб-сервер драйвера. Ключевая деталь, которую почти всегда пропускают на старте: регистрация чека происходит асинхронно — сервис принимает запрос и возвращает идентификатор документа, а результат надо запрашивать отдельно. Поэтому рабочая интеграция это не кнопка в карточке, а очередь с повторными попытками и контролем, иначе часть чеков теряется молча.

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

Зачем связывать кассу с CRM

Причина не в удобстве, а в законе и в объеме. По 54-ФЗ при безналичных расчетах, когда покупатель не стоит перед кассиром, чек нужно сформировать не позднее рабочего дня, следующего за днем расчета, и передать его в электронном виде на телефон или почту — но не позднее момента передачи товара. То есть у чека есть срок, и просрочка это не косметическая проблема.

На пяти заказах в день это закрывается вручную. На пятидесяти уже нет: кто-то забыл, кто-то уехал, в выходные никого нет, а оплаты идут. Интеграция снимает вопрос целиком — чек формируется по событию в CRM, а не по памяти сотрудника.

Второй эффект приземленнее. Чеки и их статусы видны в карточке заказа, поэтому на вопрос клиента «а где мой чек» менеджер отвечает сам, не привлекая бухгалтерию. Возвраты тоже перестают быть отдельным квестом.

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

Какой чек нужен на каждом этапе

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

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

Облачная касса или своя: что это меняет для интеграции

Если продажи идут через интернет и покупатель физически не стоит перед кассиром, логичнее облачная касса. Своего аппарата нет, ККТ арендуется в дата-центре, интеграция работает через API. Для интернет-магазина, услуг с оплатой по ссылке и курьерской доставки с предоплатой это самый простой путь.

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

Гибридные схемы встречаются чаще всего. Интернет-заказы фискализируются в облаке, розница — на своей кассе, а в CRM оба потока сходятся в один список чеков по заказу. Проектировать это надо сразу, а не достраивать вторую половину через полгода.

Как устроен обмен по API

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

Здесь первая типичная ошибка разработчиков. Токен запрашивают перед каждым чеком, хотя рекомендация обратная — использовать один токен и обновлять его только тогда, когда сервис вернет ошибку об истечении срока. Лишние запросы авторизации ничего не улучшают, а нагрузку и точки отказа добавляют.

Дальше чек отправляется POST-запросом, и в ответ приходит уникальный идентификатор документа со статусом. Если документ вообще не удалось принять, идентификатор не присваивается — это отдельный случай, который надо обрабатывать иначе, чем «принят, но еще не обработан». Результат обработки запрашивается отдельным запросом по этому идентификатору.

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

Почему это очередь, а не кнопка

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

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

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

Маркировка: где ломается чаще всего

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

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

Отдельная типовая беда — код уже выбыл из оборота. Пересорт на складе, повторная отгрузка одной и той же единицы, ошибка при приемке. Технически интеграция тут ни при чем, но разбираться будут с ней, поэтому понятное сообщение об ошибке в карточке заказа стоит своих денег.

amoCRM, Битрикс24 и RetailCRM: чем отличается связка

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

Битрикс24 берут, когда фискализация — часть более широкого процесса с согласованиями, задачами и несколькими каналами продаж. Состав чека при этом чаще подтягивается из МойСклад или 1С, где живут номенклатура, остатки и коды маркировки.

amoCRM — про воронку, а не про товарный учет. Если в чеке одна услуга и фиксированная сумма, все решается несложно. Если позиций много, разумнее фискализировать на стороне учетной системы, а в amoCRM показывать статус и ссылку на чек.

Порядок работ

1. Собираем требования вместе с бухгалтерией. Признаки расчета для каждого сценария, система налогообложения, ставки, что делать при частичной оплате. Без этого разговора настраивать нечего.
2. Определяем источник данных для чека. Где живут позиции, цены и коды маркировки, откуда интеграция их берет и в какой момент.
3. Выбираем схему касс. Облако, локальная касса или комбинация, сколько групп и юрлиц.
4. Настраиваем доступы. Учетные данные, код группы, работа с токеном без лишних перезапросов.
5. Строим очередь и обработку ошибок. Повторы, лимит попыток, разделение временных и постоянных ошибок, статусы в карточке.
6. Настраиваем сценарии по событиям. Какой чек на каком статусе заказа, что происходит при возврате и частичном возврате.
7. Тестируем на реальных случаях. Предоплата с последующей отгрузкой, полный расчет, возврат, заказ с маркированным товаром, недоступная касса.
8. Включаем мониторинг. Отчет по заказам без чека и уведомление ответственному при постоянной ошибке. Это тот случай, когда алерт дешевле штрафа.

Ошибки, которые мы разбираем чаще всего

Чек считают одним событием. Пробили при оплате и успокоились, а чек на передачу товара с зачетом аванса никто не формирует. Всплывает при проверке.

Нет очереди и повторов. Первая же недоступность кассы приводит к пропущенным чекам, о которых никто не узнает до сверки.

Токен запрашивают на каждый чек. Мелочь, но на потоке это лишняя нагрузка и лишняя точка отказа.

Чек пытаются отправить до сборки заказа. Кодов маркировки еще нет, касса отказывает, менеджер видит непонятную ошибку и звонит нам.

Возврат не автоматизирован. Приход настроили, а возврат остался ручным. В сезон возвратов это отдельная головная боль, хотя логика там та же самая.

Сроки и стоимость

Базовая фискализация одного сценария с облачной кассой — обычно от 12 часов работы: доступы, очередь, обработка ошибок, статусы в карточке, тестирование. Полный контур с предоплатами и зачетами, возвратами, несколькими юрлицами и маркировкой — от 30 часов. Связка с локальными кассами в рознице считается отдельно, потому что там добавляется работа с оборудованием.

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

Частые вопросы

Нужна ли своя касса, если продажи только в интернете?

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

Почему чек не появляется в карточке сразу?

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

Сколько чеков нужно при работе по предоплате?

Как правило, два: первый при поступлении денег с признаком предоплаты, второй при передаче товара с зачетом ранее внесенной суммы. Конкретные признаки расчета согласовывает бухгалтер.

Что будет, если касса недоступна в момент оплаты?

При грамотной интеграции задача останется в очереди и повторится, а ответственный получит уведомление. Закон дает запас по времени, поэтому короткая недоступность не критична — критично отсутствие контроля.

Можно ли отправлять чеки по маркированным товарам?

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

Автоматизируется ли чек коррекции?

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

Коротко о главном

Интеграция CRM и АТОЛ решает задачу, у которой есть юридический срок: чек должен уйти покупателю вовремя, независимо от того, кто сегодня на смене. Поэтому главное в таком проекте не кнопка в карточке, а надежность — очередь, повторы, понятные статусы и уведомления, когда что-то встало.

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

Если хотите разобрать, какие чеки нужны в вашем процессе и во сколько обойдется автоматизация, — оставьте заявку, посмотрим воронку, схему оплат и текущую работу с кассой.