Как автоматизировать магазин в Казахстане в 2026 году

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

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

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

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

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

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

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

Если этого не сделать, даже технически исправные интеграции постепенно начинают передавать дубли, устаревшие цены и некорректные остатки.

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

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

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

Например, поставщик привез товар. Сотрудник оформляет поступление, после чего товар появляется на остатке и для него устанавливается цена. Информация передается на рабочее место кассира, покупатель оплачивает товар, ККМ формирует чек, а продажа отражается в учете и уменьшает остаток.

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

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

Сеть требует уже другого подхода. Помимо работы отдельного магазина возникает центральное управление ассортиментом, ценами, остатками, перемещениями и продажами.

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

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

На практике именно здесь появляется большая часть вопросов, которые нужно решить до запуска:

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

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

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

Поэтому при тестировании кассового контура одного напечатанного чека недостаточно. Нужно проверить, что произошло со всей операцией после его формирования.

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

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

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

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

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

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

Расхождения между фактическим количеством товара и данными 1С обычно связаны с конкретными операциями. Часть таких ошибок возникает из-за пользователей, часть — из-за обменов или неправильно настроенной схемы учета.

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

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

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

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

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

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

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

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

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

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

В «1С:Рознице для Казахстана» функциональность маркировки развивается вместе с кассовыми механизмами. В релизах 2026 года, например, добавлялись сценарии выбытия через чеки ККМ для новых товарных групп.

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

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

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

Если компания одновременно работает с розницей и оптом, закупки, запасы и оптовые продажи могут вестись в 1С:Управлении торговлей, а непосредственно магазины — в розничном контуре. У более крупного бизнеса центральной системой может выступать 1С или 1С:Комплексная автоматизация.

Такая таблица дает только общее представление. Архитектуру нельзя выбирать исключительно по числу магазинов или касс.

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

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

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

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

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

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

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

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

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

SOWITA занимается автоматизацией розничной торговли в Казахстане: внедряет и развивает решения на базе 1С, настраивает кассовый и складской контур, интеграции с торговым оборудованием и внешними системами, работу с НКТ и маркировкой.

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

Мы проведем первчиный бесплатный аудит: https://sowita.kz/vnedrenie-1c-roznica-kazahstan