Почему в 1С:Розница 3.0 и УНФ 3.0 слетают вручную установленные цены в документе «Установка цен» и как это исправить?

Многие пользователи и администраторы систем на базе 1С:Розница 3.0 и 1С:УНФ 3.0 столкнулись с крайне неприятным поведением документа УстановкаЦен. Суть проблемы заключается в том, что при попытке отредактировать уже проведенный документ или даже просто при просмотре его формы, внесенные вручную значения цен бесследно исчезают, заменяясь расчетами по формулам. Рассмотрим подробнее, почему это происходит, как устроена внутренняя логика программы и какие шаги необходимо предпринять, чтобы сохранить данные в целостности.

Разберем суть проблемы: поведение формы документа

Проанализируем стандартный сценарий работы пользователя. Предположим, у нас есть вид цены «Розничная», который рассчитывается по формуле Закупочная * 1.2. При создании документа система предлагает цену 120 рублей. Однако бизнес-логика требует установить цену 125 рублей вручную. Пользователь вносит изменения, проводит документ, и в базе данных (в регистре сведений ЦеныНоменклатуры) фиксируется верное значение — 125 рублей.

Проблемы начинаются при повторном открытии этого же документа. Рассмотрим, что видит пользователь:

1. При открытии формы документа в колонке «Цена» снова отображается 120 рублей (результат формулы), хотя в объекте сохранено 125.
2. При переключении между вкладками «Состав цен» и «Список товаров» происходит мгновенный пересчет, и «Старая цена» приравнивается к текущей (или наоборот), что полностью дезориентирует сотрудника.
3. Если документ был создан на основании «Приходной накладной», пересчет может инициироваться автоматически сразу при открытии, игнорируя записанные ранее данные.

Выясним причину такого «невменяемого», на первый взгляд, поведения. Оно кроется в механизме динамического пересчета цен, который был значительно переработан в линейке 3.0.

Анализируем механизм динамических цен

В редакциях 3.0 разработчики стремились сделать форму максимально «живой». Система постоянно отслеживает зависимости. Если вид цены помечен как рассчитываемый по формуле, форма документа считает своим долгом актуализировать это значение при любом удобном случае. Проблема в том, что в ранних релизах (3.0.11, 3.0.12) алгоритм проверки «ручного ввода» работал некорректно.

В коде формы заложены обработчики событий, такие как ПриЧтенииНаСервере и ПриОткрытии. Проанализируем ситуацию: когда форма считывает данные из базы, она видит сохраненное число. Но затем срабатывает процедура визуализации, которая проверяет правила заполнения. Если система видит активную формулу, она инициирует фоновый пересчет, полагая, что данные в табличной части устарели относительно базовых цен.

Магическое число 50: оптимизация или ловушка?

Интересной особенностью конфигураций УНФ и Розница является порог в 50 строк. Посмотрим на логику работы серверных вызовов:

• До 50 строк в документе: Форма выполняет все расчеты «на лету» на стороне клиента. Это приводит к тому, что любое движение курсора или переключение вкладки вызывает немедленный триггер обновления цен.
• Свыше 50 строк: Система оптимизирует нагрузку и переходит к серверным вызовам или отложенному обновлению. В этом случае пользователь может не заметить мгновенного «слета» цен, но проблема проявится позже, при попытке записи или пересчета итогов.

Это объясняет, почему на маленьких тестовых примерах ошибка воспроизводится всегда, а на больших реальных документах поведение кажется непредсказуемым.

Как исправить проблему: пошаговые рекомендации

Решение 1: Обновление конфигурации

Первым делом проанализируем версию вашей программы. Разработчики признали наличие проблемы в механизме фиксации ручных изменений. Начиная с релизов 3.0.13.х и выше, в логику работы формы были внесены исправления:

1. Добавлен более устойчивый «флаг модифицированности» для каждой строки. Если цена была изменена вручную, система выставляет невидимый маркер ЦенаИзмененаВручную = Истина.
2. Процедуры переключения вкладок были оптимизированы, чтобы кешировать текущие значения формы и не запрашивать пересчет по формулам для строк с установленным маркером.

Решение 2: Использование расширений

Если обновление по каким-то причинам невозможно, проанализируем программный способ решения. Можно создать расширение, которое будет блокировать автоматическое заполнение для уже проведенных документов. Рассмотрим пример логики, которую следует внедрить в модуль формы документа УстановкаЦен:

&НаСервере
Процедура ПослеЗаписиНаСервере(ТекущийОбъект, ПараметрыЗаписи)
    // Блокируем обновление цен, если документ уже проведен
    Если ТекущийОбъект.Проведен Тогда
        ЭтаФорма.ТолькоПросмотр = Истина;
    КонецЕсли;
КонецПроцедуры

Хотя полная блокировка формы (ТолькоПросмотр) — это радикальная мера, она гарантирует, что пользователь не испортит данные случайным переключением вкладок.

Решение 3: Изменение методики работы (Workflow)

Посмотрим на рекомендации опытных пользователей, которые выработали безопасный алгоритм работы в условиях нестабильного поведения формы:

1. Отказ от редактирования: Вместо изменения старого документа «Установка цен», всегда создавайте новый. Это исключает конфликты между старыми и новыми формульными значениями.
2. Статический режим: Если вы планируете массово вносить цены вручную, временно измените в настройках вида цены способ расчета с «Рассчитывать по формуле» на «Заполнять вручную». После проведения документа настройки можно вернуть назад — проведенный документ уже не должен измениться, если его не открывать для редактирования в старых релизах.
3. Использование будущих дат: Подготавливайте документы заранее, устанавливая дату проведения в будущем. Это позволит системе «устояться», и вы сможете проверить финальные цены до того, как они вступят в действие на кассах.

Выясним причину связи с базовым документом

Ситуация осложняется, если документ создан на основании. В этом случае в структуре документа сохраняется ссылка на документ-основание (например, поступление). При открытии формы процедура ЗаполнитьПоОснованию может вызываться неявно для обновления данных о закупке. Если в «Приходной накладной» цена изменилась хотя бы на копейку, форма «Установки цен» решит, что всю таблицу нужно пересчитать заново. Постарайтесь избегать повторного перезаполнения по основанию, если вы уже внесли значительный объем ручных правок.

Резюмируем: Основная проблема заключается в конфликте между «умной» формой, стремящейся к актуальности, и потребностью пользователя в жесткой фиксации цен. Наилучшим выходом является переход на актуальные релизы (3.0.13+), где работа с флагами ручного изменения цен была доведена до рабочего состояния.