В процессе работы с конфигурацией 1С:Розница версий 2.2 и 2.3 пользователи часто сталкиваются с критической ошибкой: во время оформления продаж через РМК (Рабочее место кассира) система внезапно меняет текущий магазин или склад. Это приводит к тому, что выручка и списания товаров отражаются на другой торговой точке, что вызывает хаос в складском учете и отчетах о розничных продажах. Особенно остро проблема проявляется в распределенных базах (РИБ) или при работе в облачных сервисах.
В рамках данной статьи мы подробно разберем, почему возникает эта ситуация, проанализируем технические причины сбоя и рассмотрим пошаговое решение, которое поможет навсегда исключить «прыгающие» склады без внесения изменений в типовой код программы.
Проанализируем ситуацию с технической точки зрения. В 1С:Розница текущие настройки кассира (магазин, склад, касса ККМ) хранятся в так называемых параметрах сеанса. Это временные значения, которые инициализируются при запуске программы или открытии РМК. Однако в коде типовой конфигурации существует особенность работы с механизмом возвратов.
Как показывает практика и наблюдения опытных пользователей, сбой часто происходит в тот момент, когда кассир открывает форму «Выбор чека для возврата». Если в этой форме продавец пытается найти чек, который был пробит ранее, или просто просматривает список доступных документов, система выполняет запрос к базе данных. В некоторых случаях (особенно если у пользователя есть права на просмотр нескольких магазинов) выбранный для поиска контекст «перетирает» текущие параметры сеанса. В итоге программа начинает считать «родным» магазином тот, который был последним в результатах поиска или выбора, и все последующие чеки бьются по нему до перезапуска сеанса.
Также стоит учитывать влияние настроек рабочего места. 1С определяет параметры РабочееМестоККМ по сетевому имени компьютера. Если для разных магазинов созданы рабочие места с одинаковыми именами или используются дублирующие записи в справочнике РабочиеМеста, система может подхватить некорректные настройки при открытии смены.
Самым надежным и проверенным способом решения проблемы без программирования является использование механизма RLS (Record Level Security). Это позволит физически запретить кассиру видеть и выбирать «чужие» магазины и склады, даже если в программном коде произойдет сбой переключения контекста.
Разберем этот процесс по шагам:
Магазины.Склады и Кассы ККМ, если они доступны в списке.После применения этих настроек, даже если кассир попытается найти чек другого магазина, система просто не выдаст ему эти данные, и параметры сеанса останутся неизменными. Это жестко блокирует возможность продажи с «чужого» склада.
Рассмотрим еще один аспект — привязку оборудования к рабочему месту. Если настройка RLS кажется вам избыточной или замедляет работу системы, необходимо убедиться в чистоте справочников.
Проанализируем следующие моменты:
РабочиеМеста (раздел Администрирование — Подключаемое оборудование). У каждого компьютера, с которого ведется торговля, должно быть уникальное имя. Недопустимо наличие двух записей с одинаковым идентификатором для разных магазинов.НастройкиРМК. Для каждого рабочего места должна быть создана индивидуальная настройка, где жестко указан ОсновнойСклад и Магазин. Убедитесь, что в поле «Рабочее место» выбрана правильная запись из справочника рабочих мест.ОсновнойМагазин и ОсновнойСклад должны соответствовать фактическому месту работы сотрудника.Если вы обладаете навыками разработки, можно применить «заплатку» в виде расширения конфигурации. Это позволит не включать тяжелый механизм RLS, а просто принудительно устанавливать нужные параметры перед проведением чека.
Посмотрим на пример логики, которую можно реализовать в процедуре ПередЗаписью документа ЧекККМ или в модуле менеджера при обработке формы РМК:
// В расширении для документа ЧекККМ
&После("ПередЗаписью")
Процедура ИТ_ПередЗаписью(Отказ, РежимЗаписи, РежимПроведения)
// Получаем правильный магазин из настроек текущего узла или рабочего места
ПравильныйМагазин = ПолучитьМагазинПоРабочемуМесту(ПараметрыСеанса.РабочееМестоКлиента);
Если ЗначениеЗаполнено(ПравильныйМагазин) И ЭтотОбъект.Магазин <> ПравильныйМагазин Тогда
// Записываем ошибку в журнал регистрации для анализа
ЗаписьЖурналаРегистрации("ИсправлениеСклада", УровеньЖурналаРегистрации.Предупреждение, , ,
"Попытка записи чека с чужим магазином! Исправлено с " + ЭтотОбъект.Магазин + " на " + ПравильныйМагазин);
ЭтотОбъект.Магазин = ПравильныйМагазин;
// Аналогично проверяем и устанавливаем склад
ЭтотОбъект.Склад = ПравильныйМагазин.СкладУправляющейСистемы;
КонецЕсли;
КонецПроцедуры
Данный код принудительно сверяет магазин в документе с тем, который должен быть привязан к конкретному рабочему месту, и исправляет его в случае расхождения. Это гарантирует, что даже при сбое интерфейса данные в базе останутся корректными.
Проанализируем еще несколько важных моментов, которые могут влиять на появление ошибки:
AppData и сбросит настройки форм.Подводя итог, можно сказать, что наиболее эффективным методом борьбы с «прыгающими» складами в 1С:Розница является комбинация настройки RLS (для физического ограничения доступа) и тщательной проверки справочников рабочих мест. Это позволит вам избежать пересортицы между магазинами и обеспечит чистоту управленческого учета.