При работе в розничных конфигурациях 1С (таких как 1С:Розница, УНФ или Управление торговлей) пользователи часто сталкиваются с неприятной ситуацией: при нажатии кнопки «Рассчитать скидки» в рабочем месте кассира (РМК) отображается одна сумма, но как только дело доходит до выбора способа оплаты и пробития чека, итоговая сумма внезапно меняется на несколько копеек. Разберем детально, почему это происходит и как это исправить.
Основная причина расхождений кроется в правилах распределения скидки, предоставленной на весь чек (фиксированной суммой), по конкретным товарным позициям. Проанализируем ситуацию: если мы предоставляем скидку в 10 рублей на 3 единицы товара, программа должна распределить эти 10 рублей пропорционально стоимости каждой строки. Математически получается 3,333... рубля на позицию. Однако учет ведется в копейках, поэтому 1С вынуждена округлять значения до двух знаков после запятой.
В результате в чеке могут появиться строки со скидками 3,33 руб., 3,33 руб. и 3,34 руб. Здесь вступает в силу правило: сумма округлений не всегда равна округлению суммы. Если алгоритм предварительного расчета просто показывает общую скидку, а алгоритм подготовки данных для фискального регистратора начинает пересчитывать каждую строку заново, возникает разница в 1-2 копейки.
Выясним причину технического характера. В типовых конфигурациях 1С процесс расчета происходит в два этапа, которые, к сожалению, могут использовать разные программные механизмы:
СкидкиНаценкиСервер. Он подготавливает данные для визуального отображения кассиру.Если в конфигурацию вносились изменения или используются специфические настройки округления, эти два алгоритма могут дать разный результат на одних и тех же данных.
Проанализируем взаимодействие программы с кассовым аппаратом. Фискальный регистратор — это самостоятельное устройство со своей логикой. Когда 1С передает данные на кассу, она отправляет цену, количество и итоговую сумму строки. Кассовый аппарат проверяет корректность данных по формуле: Цена * Количество = Сумма. Если из-за скидки цена за единицу стала дробной (например, 10,8666...), 1С передает округленное значение 10,87. Касса умножает 10,87 на количество и получает сумму, отличную от той, что насчитала 1С. Чтобы избежать ошибки «Сумма чека не совпадает с суммой позиций», программа пытается «подогнать» копейки в последнюю секунду, что пользователь и видит как скачок суммы в окне оплаты.
Для минимизации таких ошибок рассмотрим правильную настройку маркетинговых акций. Чтобы суммы «бились» по вертикали и горизонтали, рекомендуется настраивать округление не для всего чека в целом, а для каждой строки отдельно.
Посмотрим на шаги настройки:
Если настройки не помогают, программисту необходимо воспользоваться отладчиком. Разберем, на какие модули стоит обратить внимание.
Проанализируем ситуацию в момент нажатия кнопки оплаты. Нам нужно сравнить данные в табличной части «Товары» перед вызовом формы оплаты и данные, которые передаются в процедуру печати чека. Рассмотрим пример поиска места распределения скидки:
// В модуле формы РМК найдем процедуру, отвечающую за переход к оплате
Процедура ПодготовитьДанныеКПробитию()
// Здесь часто происходит повторный вызов распределения
СкидкиНаценкиСервер.РассчитатьСкидкиНаценки(Объект);
// Проверьте, не сбрасывается ли флаг СкидкиРассчитаны
КонецПроцедуры
Особое внимание уделим функции РаспределитьСуммуСкидкиПоСтрокам(). В ней часто встречается алгоритм, который «сбрасывает» лишнюю копейку на первую строку чека. Если количество товара в первой строке больше единицы (например, 10 штук), то изменение цены на 1 копейку даст общую разницу в 10 копеек. Правильнее распределять копейки на ту строку, где количество товара равно 1.
Эта ошибка — прямое следствие неправильного округления. Когда 1С после всех расчетов получает сумму, например, 100.001, а касса ожидает 100.00, система может посчитать, что клиент внес недостаточно средств. Чтобы этого избежать, убедитесь, что:
Окр(Значение, 2)).Резюме: для исправления «плавающих» копеек необходимо синхронизировать алгоритмы расчета в модуле скидок и модуле печати чека, настроить округление строк чека в правилах маркетинга и убедиться, что драйвер кассы не применяет собственное округление, конфликтующее с логикой 1С.