Почему пропадают позиции из документа Заказ покупателя в 1С:УТ 10.3 и как это исправить

← На главную

Ситуация, когда в программе «самопроизвольно» меняются данные в проведенных документах, является одной из самых стрессовых для администратора системы или программиста. Рассмотрим детально случай из практики работы с конфигурацией «Управление торговлей 10.3» на платформе 8.2 (файловый вариант), когда после создания документа РеализацияТоваровУслуг из исходного документа ЗаказПокупателя пропадает часть номенклатурных позиций. Проанализируем причины этого явления, методы диагностики и способы предотвращения подобных инцидентов.

Поиск «улик» в журнале регистрации

Первым делом, когда возникает подозрение на программный сбой или несанкционированное изменение данных, мы должны обратиться к Журналу регистрации. Это главный инструмент аудита в 1С. Разберем, на что именно стоит обратить внимание.

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

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

Программная диагностика: поиск скрытых алгоритмов

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

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

Пример кода, который может быть внедрен в систему и вызывать удаление строк (использовать с осторожностью только для анализа):


Процедура ПередЗаписью(Отказ, РежимЗаписи, РежимПроведения)
    // Пример вредоносного или ошибочного кода
    Если ЭтотОбъект.Проведен Тогда
        Индекс = Товары.Количество() - 1;
        Пока Индекс >= 0 Цикл
            СтрокаТЧ = Товары[Индекс];
            // Например, кто-то решил удалять строки, по которым нет остатка
            Если СтрокаТЧ.Количество == 0 Тогда 
                Товары.Удалить(СтрокаТЧ);
            КонецЕсли;
            Индекс = Индекс - 1;
        КонецЦикла;
    КонецЕсли;
КонецПроцедуры

Особенности файлового режима и платформы 8.2

Проанализируем технический аспект. В файловом режиме (.1CD) при одновременной работе пользователей могут возникать конфликты блокировок. Хотя платформа 8.2 достаточно стабильна, существует вероятность возникновения «состояния гонки» (race condition). Если два сеанса под одним пользователем одновременно пытаются записать один и тот же объект, данные могут быть перезаписаны устаревшей версией из кэша одного из сеансов.

Также стоит учитывать кеширование данных. В редких случаях после динамического обновления конфигурации кэш на клиентских машинах может работать некорректно, «подсовывая» старые алгоритмы обработки табличных частей. Рекомендуется периодически очищать локальный кэш пользователей (папки %AppData%\1C\1Cv82).

Почему менеджеры удаляют строки: бизнес-логика и резервы

Выясним мотивацию сотрудников. В 1С:УТ 10.3 ключевым механизмом является резервирование товаров. Заказ покупателя может делать записи в регистр накопления ТоварыВРезервеНаСкладах. Если в компании острый дефицит товара, менеджеры могут идти на хитрость:

Видя, что товар зарезервирован под чужой заказ, менеджер заходит в этот заказ (если права позволяют) и удаляет строку или уменьшает количество.
Товар высвобождается из резерва.
Менеджер тут же перебивает его в свой заказ.

В результате у первого менеджера в Реализации (которая уже была сформирована или печаталась) товар есть, а в Заказе после «тихого» редактирования вторым менеджером — строк уже меньше. Это создает расхождения в аналитических отчетах, таких как «Анализ заказов покупателей».

Внедрение системы версионирования

Чтобы навсегда прекратить споры «кто удалил строку», рассмотрим внедрение версионирования объектов. В типовой УТ 10.3 встроенного механизма версионирования в том виде, как в БСП (Библиотеке стандартных подсистем) для 8.3, может не быть. Однако его можно добавить с помощью сторонних разработок или подписок на события.

Разберем принцип работы простейшего логирования изменений табличной части Товары:


Процедура ПриЗаписи(Отказ)
    // Записываем старое и новое состояние документа в специальный регистр
    // Это позволит увидеть, кто именно, когда и какие строки удалил
    Для Каждого СтрокаТЧ Из Товары Цикл
        // Логика сравнения версий...
    КонецЦикла;
КонецПроцедуры

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

Последствия для учета

Проанализируем, к чему ведут такие изменения в Заказе покупателя при наличии проведенной Реализации:

План-фактный анализ: В отчетах будет отражаться, что потребность клиента была меньше, чем фактическая отгрузка. Это лишает руководство возможности видеть реальный спрос.
Взаиморасчеты: Если в договоре указано ведение взаиморасчетов «По заказам», то изменение суммы заказа приведет к тому, что документ не будет закрыт в ноль в регистре ЗаказыПокупателей. Виртуальный «долг» по заказу будет висеть в базе вечно.
Автоматические скидки: Если сумма заказа уменьшилась, а реализация осталась на большую сумму, при попытке пересчитать налоги или скидки в заказе возникнет конфликт сумм.

Итоговые рекомендации

Для решения проблемы «пропадающих строк» выполним следующие действия:

Разделение учетных записей: Категорически запретим использование одного логина несколькими сотрудниками. Каждый вход должен быть персонифицирован.
Настройка прав доступа: Ограничим право на редактирование документов ЗаказПокупателя в закрытых периодах или при наличии связанных документов отгрузки.
Ревизия кода: Проверим все обработчики ПриЗаписи на предмет программного удаления пустых строк или строк с нулевой ценой, что часто зашивается в систему как «автоматическая чистка».
Аудит рабочих мест: Сопоставим время изменения документов в журнале регистрации с физическим присутствием сотрудников за конкретными компьютерами.

Таким образом, мы выяснили, что в 99% случаев проблема не в «глюке» программы, а в человеческом факторе или некорректно настроенных бизнес-процессах внутри системы. Использование журнала регистрации в сочетании с пониманием механизмов резервирования позволяет быстро найти виновного и восстановить целостность учета.