1С:Розница для Казахстана: фискальную часть закрывает типовая, магазин останавливает другое

Вопрос “какая 1С нужна магазину в Казахстане” обычно упирается в список функций: чеки, ОФД, маркировка, Нацкаталог. Список важный, но короткий - и почти весь он закрыт типовой конфигурацией. А вот то, из-за чего розница на 1С реально останавливается, в списках функций не пишут. Разберём оба слоя.

Слой первый: фискальный. Его закрывает типовая

Актуальная линейка - “1С:Розница для Казахстана” редакции 2.3, релизы выходят регулярно (на момент статьи свежий - 2.3.10.4 от октября 2025). По описаниям релизов в типовой есть:

• работа с ККМ и ОФД - в свежих релизах поддержан протокол ОФД 2.0.3, и это живой пример, зачем обновляться: изменилось формирование чеков возврата, теперь в чеке возврата указываются сведения об исходном чеке продажи;
• маркировка - механизм учёта маркированной табачной продукции появился ещё в релизе 2.3.1.3, вывод из оборота при продаже идёт через чек ККМ на уровне типовой;
• Нацкаталог (НКТ) - товарный контур Казахстана 2026 года завязан на него; что именно и с какого релиза поддержано, сверять по релизным письмам.

Вывод из этого слоя тот же, что мы писали про Бухгалтерию для Казахстана: отдельный “модуль для чеков” покупать не нужно, но всё перечисленное работает ровно до тех пор, пока база обновляется. Отстали на год - и чеки возврата у вас формируются не так, как ждёт ОФД. Точные составы релизов - в релизных письмах вендора, туда и смотреть при спорных случаях.

Слой второй: эксплуатационный. Здесь магазины и встают

За несколько лет работы с казахстанской розницей мы ни разу не выезжали на “не печатается чек”. Выезжали на другое.

Кассы встают под нагрузкой. Классическая картина: утром всё летает, в пиковые часы кассы встают на 20-60 секунд на операции, к вечеру очереди. Виновата обычно не Розница и не кассы: в нашем разборе почему кассы вставали причина нашлась в настройках SQL Server - MAXDOP и cost threshold, - а не в конкуренции за данные, на которую грешили сначала. Типовая конфигурация про это не знает ничего: она работает поверх СУБД, которую кто-то должен обслуживать.

Обмены расходятся. Розница редко живёт одна: рядом бэк-офис на Бухгалтерии или управленческой базе, наверху - маркетплейсы. Каждый обмен - точка, где остатки и цены могут разойтись. Что это стоит на практике и как выглядит рабочая связка, мы разбирали на примере интеграции 1С с Kaspi: там ошибка в остатках - это отменённый заказ и штраф площадки, а не просто неудобство. Если остатки на витрине уже расходятся с кассой, обмен стоит ставить заново: в интеграции 1С с Kaspi цены и остатки уходят на площадку по расписанию, раз в несколько минут, и продажа в магазине снимает товар с витрины без участия человека.

База разрастается. Розничная база пишет много и быстро, через несколько лет это терабайты: ночной бэкап перестаёт влезать в ночь, обслуживание - в выходные. Причём виновник роста часто неожиданный: в нашем разборе обрезки розничной базы 3,85 ТБ из 4,2 занимали не документы и не история продаж, а служебный кэш, о существовании которого в компании не знал никто.

Граница между слоями простая. Первый слой - про соответствие закону, и его держит вендор релизами. Второй - про то, работает ли магазин, и его не держит никто, пока вы не назначили ответственного: ни релиз, ни франчайзи, продавший коробку, настройками СУБД и мониторингом обменов заниматься не будут.

Что проверить, если у вас Розница КЗ

1. Релиз и дата последнего обновления. Протокол ОФД и маркировка меняются релизами; база годичной давности соответствует закону годичной давности.
2. Скорость касс в пиковый час - утренний замер ничего не показывает. Если операции заметно замедляются к пику, это диагностируется и чинится, чаще всего на стороне СУБД.
3. Сверку остатков по обменам: возьмите десять ходовых позиций и сравните остатки в Рознице, бэк-офисе и на витрине маркетплейса. Разошлись - обмен уже болеет, просто пока тихо.
4. Размер базы и время бэкапа. Оба числа должны быть кому-то известны и куда-то записаны. Если их никто не знает - их узнают при первой аварии.

Мы закрываем второй слой как услугу: сопровождение типовых 1С для Казахстана - обновления с проверкой на копии, обмены, производительность. Первый слой при этом остаётся типовым, и это правильно: чем меньше доработок в фискальной части, тем дешевле каждое следующее обновление.

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