Многие технические специалисты и администраторы систем на базе 1С:Управление торговлей 10.3 сталкиваются со странным поведением программы в розничных точках. Суть проблемы заключается в следующем: оператор в офисе устанавливает новые цены и проводит документ переоценки, однако кассиры на рабочих местах (РМК) продолжают видеть старые цены или получают ошибку "На данный товар не назначена цена". Самое загадочное, что после перезапуска 1С на кассе проблема исчезает, и цены становятся актуальными.
Давайте подробно разберем, почему так происходит, проанализируем внутренние механизмы 1С и найдем способы решения этой проблемы как программными, так и административными методами.
Для начала проанализируем, как 1С:УТ 10.3 работает с ценами в рознице. В отличие от оптовой торговли, где цена берется из регистра сведений ЦеныНоменклатуры, в автоматизированных торговых точках (АТТ) система ориентируется на регистр накопления ТоварыВРознице.
Когда вы проводите документ "Переоценка товаров в рознице", система делает записи в этот регистр, фиксируя остатки товара по новой стоимости. Проблема в том, что интерфейс кассира (РМК) работает с объектом Документ.ЧекККМ. Как только кассир пробил предыдущий чек, система автоматически создает новый пустой объект документа. В этот момент документу присваивается текущая дата и время.
Рассмотрим ситуацию:
В этот момент система пытается определить цену товара. Но запрос к базе данных уходит с параметром даты, равным дате документа, то есть 09:01:00. Естественно, на 9 утра новой цены еще не существовало, и 1С сообщает, что цена не назначена.
Давайте заглянем "под капот" конфигурации и посмотрим на типовой код. В модуле документа ЧекККМ или в обработке РМК получение цены часто завязано на функцию ПолучитьПродажнуюЦену. Проанализируем пример кода, который вызывает это поведение:
Цена = УправлениеРозничнойТорговлей.ПолучитьПродажнуюЦену(
ДокументОбъект.Дата,
СтрокаТабличнойЧасти.Номенклатура,
ХарактеристикаНоменклатуры,
СтрокаТабличнойЧасти.ЕдиницаИзмерения,
ТекСклад,
...
);
Как мы видим, первым параметром передается ДокументОбъект.Дата. А сама дата устанавливается при создании объекта:
Если НачалоДня(ЭтотОбъект.Дата) = НачалоДня(ТекущаяДата()) Тогда
ЭтотОбъект.Дата = ТекущаяДата();
КонецЕсли;
Этот код отрабатывает единожды при инициализации нового чека. Пока чек не будет пробит или закрыт, его дата не изменится. Именно поэтому перезапуск РМК помогает: объект пересоздается с новой актуальной датой, которая уже "видит" проведенную переоценку.
Чтобы кассирам не приходилось перезапускать программу, нам необходимо заставить систему обновлять дату документа непосредственно перед поиском цены при сканировании товара. Рассмотрим, как это реализовать.
Найдите в модуле формы документа ЧекККМ или в обработке РМК процедуру, отвечающую за добавление товара (обычно это обработка сканирования штрихкода или процедура ПриИзмененииНоменклатуры). Нам нужно добавить принудительное обновление даты для новых (еще не записанных) документов.
Добавьте следующий фрагмент кода перед вызовом функций ценообразования:
Если ЭтотОбъект.ЭтоНовый() Тогда
ЭтотОбъект.Дата = ТекущаяДата();
КонецЕсли;
Важный нюанс: Обновлять дату стоит только в том случае, если документ еще не был записан и в нем нет других товаров, чтобы не нарушить логику уже начатого процесса продажи. Однако для пустого чека это абсолютно безопасная и эффективная операция.
В клиент-серверном (SQL) варианте работы проблема может усугубляться разницей во времени между сервером приложений, сервером баз данных и рабочими станциями кассиров. Проанализируем ситуацию: если на кассе время спешит на 2 минуты относительно сервера, то документ переоценки, созданный "сейчас", для кассы может оказаться в "прошлом" или наоборот.
Выясним, как это исправить:
Если вы не можете вносить изменения в код конфигурации, можно обучить кассиров простым действиям, которые обновят объект документа без перезагрузки всей 1С:
Esc (отменить текущий пустой чек) и снова открыть окно регистрации продаж.Посмотрим на разницу между файловым и серверным вариантом. В файловой версии база данных и клиент работают в одном адресном пространстве и используют время одной локальной машины. В SQL-варианте транзакции и блокировки работают жестче. Если документ переоценки еще не зафиксирован в базе данных SQL из-за длительной транзакции, кассир его не увидит, даже если время совпадает. Однако основным фактором остается именно "залипание" даты в памяти клиента 1С.
Проанализировав ситуацию, мы выяснили, что "виновником" является механизм работы с объектом документа в памяти. Система 1С:УТ 10.3 проектировалась в расчете на быстрый оборот чеков, но в реальности кассовая форма может стоять открытой часами.
Итог: Самым надежным решением является небольшая доработка кода, которая обновляет дату документа ЧекККМ при добавлении первого товара в корзину. Это гарантирует, что запрос к регистру ТоварыВРознице всегда будет использовать максимально актуальную точку во времени.