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

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

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

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

Оставляю исключения в отдельной очереди с причиной и вопросом. Пустая ячейка иногда честнее отлично отформатированной догадки.