Сложность задачи нами классифицирована как высокая, так как явных ошибок в журнале регистрации в ходе обновления не зафиксировано, а первичный анализ нетипового кода — не выявил некорректного влияния доработок на механизмы проведения.
Как найти причину отрицательных остатков
Первоначальная гипотеза заключалась в неверном переносе доработок в части механизмов проведения документов. Однако анализ кода и проверка алгоритмов трехстороннего слияния результатов не дали.
Для локализации проблемы был выбран метод сравнительного анализа движений по конкретной номенклатурной позиции, имеющей максимальное отклонение в отчете «Остатки и доступность товаров»:
Результаты отчета «Остатки и доступность товаров», после обновления с отрицательными остатками и в базе до обновления с корректными остатками
Следующий этап — сверка данных регистра накопления «Запасы и потребности» и регистра сведений «Распределение запасов» в обновленной базе с регистром сведений «Распределение запасов» и регистром накопления «Распределение запасов движения» в базе до обновления.
В базе до обновления видим, что на поступление 875 шт.
После обновления 875 шт. стоят на резерве, и появился заказ клиента
Сравниваем движения по заказу клиента, в базе до обновления
Движения в заказе клиента после обновления
Идентификация расхождений: в базе «1C:ERP 2.5.7» до обновления документ «Заказ клиента» имел признак «проведен = истина», но имел пустой набор записей в регистрах. В обновленной базе «1C:ERP 2.5.22» после обработчиков обновления по этим же документам возникли движения.
Адаптация к алгоритмам обновления проведенных документов «Заказ клиента» без движений
Алгоритмы обновления интерпретируют проведенные «Заказы клиентов» без движений как ошибочное состояние данных и принудительно перезаполняют регистры. В условиях, когда товар по этим заказам уже был списан другими корректировками или чеками — возникло двойное списание остатка.
С помощью консоли запросов был выявлен полный перечень документов, сформировавших некорректные записи в обновленной базе, а затем создана обработка, с которой в базе до обновления выполнили массовую отмену признака проведения «пустых» заказов. Это устранило проблему на уровне источника данных.
Запрос = Новый Запрос;
Запрос.Текст =
"ВЫБРАТЬ
| ЗаказКлиента.Ссылка КАК Ссылка
| ИЗ
| Документ.ЗаказКлиента КАК ЗаказКлиента
| ЛЕВОЕ СОЕДИНЕНИЕ РегистрНакопления.РаспределениеЗапасовДвижения КАК Движения
| ПО ЗаказКлиента.Ссылка = Движения.Регистратор
| ГДЕ
| ЗаказКлиента.Проведен = ИСТИНА
| И Движения.Регистратор ЕСТЬ NULL";
РезультатЗапроса = Запрос.Выполнить();
ВыборкаДетальныеЗаписи = РезультатЗапроса.Выбрать();
Пока ВыборкаДетальныеЗаписи.Следующий() Цикл
ОбъектДок = ВыборкаДетальныеЗаписи.Ссылка.ПолучитьОбъект();
ОбъектДок.Проведен = Ложь; // Снимаем признак без запуска процедур отмены проведения
ОбъектДок.ОбменДанными.Загрузка = Истина;
ОбъектДок.Записать(РежимЗаписиДокумента.Запись);
КонецЦикла;
После исправления исходных данных, было запущено повторное обновление тестовой базы.
Выводы и рекомендации
- Превентивный аудит: перед обновлением конфигурации необходимо выполнять проверку базы на наличие документов с флагом «проведен», не имеющих записей в основных регистрах накопления.
- Анализ обработчиков: обработчики обновления обладают высокой степенью автономности и могут «реанимировать» исторические данные, которые считались неактивными.
- Тестирование на копии: при большом количестве релизов требуется обязательная сверка остатков и доступности товаров в разрезе всех регистров обеспечения (ЗапасыИПотребности, РаспределениеЗапасов).
Вступайте в нашу телеграмм-группу Инфостарт