При работе в многопользовательских базах конфигурации 1С:Розница 2.2 (особенно в ситуациях, когда в одной базе ведется учет по нескольким магазинам или складам) периодически возникает крайне неприятная проблема. Во время оформления продажи через режим Рабочего места кассира (РМК) чек ККМ пробивается по правильной, физически подключенной кассе, однако в самом документе автоматически подставляется склад или магазин другой торговой точки. Это приводит к пересортице, некорректному списанию остатков и путанице в аналитических отчетах.
Давайте детально разберем, почему возникает эта плавающая ошибка, проанализируем внутренние механизмы системы и пошагово устраним неполадки, используя как административные методы, так и инструменты разработки.
В конфигурации 1С:Розница 2.2 за автоматическое распределение номенклатурных позиций по складам, магазинам и организациям отвечает специализированный механизм. Он опирается на регистр сведений РаспределениеПродаж. Даже если вы не настраивали этот функционал намеренно, в регистре могут остаться старые или некорректно сформированные записи.
Выясним причину сбоя: если программа находит в этом регистре запись, указывающую, что определенная товарная группа или конкретная номенклатура должна продаваться со склада «Магазина Б», то при сканировании этой позиции в РМК «Магазина А» система автоматически подменит склад в чеке. При этом физическая касса останется прежней.
Рассмотрим по шагам процесс очистки и настройки регистра:
Распределение продаж (а также сопутствующий регистр Распределение продаж услуг по организациям).Параметры торгового оборудования, касс ККМ и настроек РМК в 1С жестко привязываются к справочнику РабочиеМеста. Каждому физическому компьютеру платформа присваивает уникальный идентификатор (GUID), который сохраняется в локальном файле настроек пользователя 1cv8u.pfl на системном диске.
Проанализируем ситуацию: если база работает в терминальном режиме (через RDP-сервер), на виртуальных машинах или если на компьютерах произошел дисковый сбой, имя хоста или сетевой профиль могут измениться. В результате 1С генерирует новое рабочее место в справочнике или, что еще хуже, путает сессии пользователей. Кассир магазина «А», заходя в систему, перехватывает настройки рабочего места магазина «Б».
Выполним следующие действия для устранения проблемы:
Еще один сценарий связан с человеческим фактором и особенностями синхронизации баз в распределенной информационной базе (РИБ). Если кассиры в разных магазинах имеют доступ к общей базе (или обмен происходит практически мгновенно), возникает лазейка для ошибки.
Рассмотрим механизм возникновения ошибки: кассир в Магазине «А» откладывает чек ККМ. Этот документ записывается в общую базу данных. В Магазине «Б» другой кассир нажимает кнопку «Продолжить чек» и по ошибке (или из-за невнимательности) выбирает чужой отложенный чек из списка. Программа открывает его на кассе Магазина «Б». Физический фискальный документ будет отпечатан на локальной кассе ККМ Магазина «Б», но в самом документе Чек ККМ реквизиты магазина и склада останутся от Магазина «А».
Для предотвращения подобных ситуаций выполним настройку прав:
Настройки торгового оборудования, складов по умолчанию и формы РМК активно кэшируются платформой 1С на локальном компьютере. Если на одной физической кассе посменно работают разные сотрудники под своими учетными записями, или если сеанс работы программы был завершен аварийно (например, при отключении электричества), кэш может повредиться.
В результате при запуске сессии программа берет устаревшие настройки по умолчанию из поврежденного кэша прошлой сессии другого магазина.
Решить эту проблему можно очисткой кэша:
/ClearCache в строку запуска информационной базы в окне запуска 1С:Предприятия.Если в настройках программы включена схема «Интеркампани» (передачи товаров между организациями), система ведет себя гибко при оформлении продаж. Если товара нет на остатках в текущем магазине «А», но он числится в магазине «Б», при проведении чека система может автоматически подменить склад-источник на магазин «Б», чтобы провести документ без возникновения отрицательных остатков.
Чтобы исключить влияние этого фактора, проверим настройки:
Поскольку эта проблема носит плавающий характер и проявляется периодически, лучшим способом поймать виновника является доработка кода в конфигураторе. Программисту рекомендуется установить точку останова в модуле документа ЧекККМ.
Разберем по шагам, как настроить логирование этого сбоя в Журнал регистрации:
ЧекККМ.ПередЗаписью.Пример программного кода для локализации ошибки:
Процедура ПередЗаписью(Отказ, РежимЗаписи, РежимПроведения)
// Проверяем, что это новый чек или чек в режиме проведения
Если Не Отказ И (РежимЗаписи = РежимЗаписиДокумента.Проведение Или ЭтотОбъект.Проведен) Тогда
// Сверяем магазин в шапке документа с магазином, закрепленным за кассой ККМ
Если ЗначениеЗаполнено(ЭтотОбъект.КассаККМ) И ЗначениеЗаполнено(ЭтотОбъект.Магазин) Тогда
Если ЭтотОбъект.Магазин <> ЭтотОбъект.КассаККМ.Магазин Тогда
// Формируем детальное описание для журнала регистрации
ТекстОшибки = "Внимание! Обнаружено расхождение магазина в чеке ККМ!" + Символы.ПС
+ "Чек №: " + ЭтотОбъект.Номер + " от " + Формат(ЭтотОбъект.Дата, "ДФ=dd.MM.yyyy") + Символы.ПС
+ "Выбранный магазин в чеке: " + СокрЛП(ЭтотОбъект.Магазин) + Символы.ПС
+ "Магазин кассы ККМ: " + СокрЛП(ЭтотОбъект.КассаККМ.Магазин) + Символы.ПС
+ "Пользователь: " + ИмяПользователя() + Символы.ПС
+ "Компьютер: " + ИмяКомпьютера();
ЗаписьЖурналаРегистрации(
"ПроверкаМагазинаВЧеке",
УровеньЖурналаРегистрации.Предупреждение,
ЭтотОбъект.Метаданные(),
ЭтотОбъект.Ссылка,
ТекстОшибки
);
КонецЕсли;
КонецЕсли;
КонецЕсли;
КонецПроцедуры
Благодаря этому несложному коду при первой же попытке записи «неправильного» чека в Журнале регистрации появится подробная запись. Вы сможете точно узнать имя пользователя, имя компьютера, время транзакции и список товаров, при сканировании которых произошел сбой. Это позволит вам моментально определить, какой из описанных выше факторов (кэш, GUID или отложенный чек) сработал в вашем конкретном случае.