Почему в заказе клиента 1С самопроизвольно меняется номенклатура и как это исправить?

← На главную

Ситуация, когда в проведенном заказе клиента после сохранения меняется номенклатура (например, с «саморез 35» на «саморез 40»), является одной из самых сложных для диагностики. Часто пользователи сталкиваются с тем, что стандартная История изменений показывает отсутствие правок, а печатные формы, созданные в момент оформления, противоречат текущему состоянию документа. Давайте разберем, как последовательно проанализировать эту проблему и найти виновника.

Шаг 1. Проверка наличия дублей номенклатуры

Самая распространенная причина — это существование в справочнике Номенклатура двух практически идентичных элементов. Если у вас есть две позиции с одинаковым наименованием, может произойти путаница при выборе товара или при автоматическом обновлении данных регламентными заданиями.

Откройте справочник Номенклатура.
Проверьте, нет ли нескольких элементов с одинаковым названием.
Попробуйте найти обе позиции по коду или артикулу. Часто одна позиция имеет правильные характеристики, а вторая — ошибочные.

Возможно, при подборе товара в заказ была выбрана одна позиция, а автоматизированный процесс (например, перепроведение или обмен) привязал заказ к ссылке на другую позицию, которую ошибочно посчитали «основной».

Шаг 2. Анализ механизмов, обходящих версионирование

Если История изменений пуста, это не значит, что изменений не было. Механизм версионирования срабатывает только при записи объекта через стандартные формы 1С. Рассмотрим варианты, когда записи в истории не появляются:

Прямое изменение в СУБД: Если кто-то имеет доступ к базе данных на уровне SQL, он может изменить ссылку на товар в таблице документа напрямую. В этом случае 1С ничего не узнает об изменении.
Групповая обработка данных: Использование обработок типа Групповое изменение реквизитов с установленным режимом «Разработчик» позволяет менять данные, обходя подписки на события.
Внешние воздействия: Если в компании работают интеграции с сайтами или внешними API, данные могут приходить извне и записываться программно, что также может игнорировать стандартные механизмы версионирования.

Шаг 3. Использование GUID для идентификации

Если вы подозреваете подмену, сравнивайте не наименование, а Уникальный идентификатор (УИД) объекта. Наименования могут быть одинаковыми, но ссылки в базе данных — разными.

Пример программного способа получения УИД для анализа:


// Пример получения УИД для проверки
СсылкаНаТовар = ДокументОбъект.Товары[0].Номенклатура;
УИД = Строка(СсылкаНаТовар.УникальныйИдентификатор());
Сообщить("УИД номенклатуры в заказе: " + УИД);

Шаг 4. Анализ журнала регистрации

Не ограничивайтесь поиском изменений только в объекте Документ.ЗаказКлиента. Расширьте область поиска:

Откройте Журнал регистрации.
Установите отбор по объекту Справочник.Номенклатура.
Включите отображение всех событий, включая «Удаление» и «Изменение».
Ищите записи, совершенные пользователями с правами администратора или «Системной учетной записью» (под которой работают регламентные задания).

Шаг 5. Восстановление из бэкапа для сравнения

Если проблема критична, используйте метод сравнения баз. Разверните резервную копию, сделанную до момента обнаружения ошибки.

Сравните текущий документ в «живой» базе и в бэкапе по УИД. Если в бэкапе в заказе стоит «саморез 35», а в текущей базе там же стоит «саморез 40», значит, была произведена именно манипуляция с данными внутри заказа. Если же и там, и там стоит «саморез 35», но в текущей базе объект номенклатуры переименован — ищите следы в Истории изменений номенклатуры.

Заключение: Чудес не бывает. Если данные изменились, значит, сработал программный код или внешний скрипт. В первую очередь проверяйте наличие дублей номенклатуры, так как это самая частая причина «самопроизвольных» подмен, которые пользователи принимают за мистику.