Почему «Чек ККМ» не уменьшает остатки товаров в УТ 10.3?

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

Разбираемся в архитектуре списания товаров

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

Когда кассир пробивает Чек ККМ, система выполняет следующие действия:

1. Фиксирует факт продажи в интерфейсе.
2. Применяет автоматические и ручные скидки.
3. Печатает фискальный чек на оборудовании.
4. Формирует движения по регистру Скидки (предоставленные), если они были применены.

Важно понимать, что документ Чек ККМ в типовой конфигурации не предназначен для выполнения движений по складским регистрам накопления, таким как ТоварыВРознице. Это сделано намеренно для обеспечения высокой производительности кассового места. Если бы каждый чек приводил к пересчету складских остатков в реальном времени, при высокой интенсивности продаж мы бы получили блокировки базы данных и «тормоза» на кассе.

Роль документа «Отчет о розничных продажах»

Основным документом, отвечающим за списание товаров на розничном складе, является Отчет о розничных продажах (ОРП). Процесс выглядит следующим образом:

• В течение смены кассир пробивает чеки. Они накапливаются в системе в статусе «пробитых».
• При закрытии смены кассир (или администратор) выполняет процедуру закрытия кассовой смены.
• Система автоматически формирует документ Отчет о розничных продажах, который собирает все пробитые чеки за период.
• При проведении Отчета о розничных продажах происходит массовое списание товаров с регистра ТоварыВРознице.

Таким образом, именно в момент закрытия смены и проведения Отчета о розничных продажах данные об остатках в учете приходят в соответствие с фактическими продажами.

Анализируем программный код

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

Если Склад.ВидСклада = Перечисления.ВидыСкладов.Оптовый Тогда
    НаборДвижений = Движения.ТоварыНаСкладах;
Иначе
    НаборДвижений = Движения.ТоварыВРознице;
КонецЕсли;

Однако, несмотря на наличие ссылки на ТоварыВРознице, важно помнить, что для Чека ККМ эти движения не заполняются при проведении в штатном режиме розничной торговли. Процедура списания инкапсулирована в Отчет о розничных продажах.

Почему не стоит дорабатывать списание «на лету»

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

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

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