Работа с электронным документооборотом (ЭДО) в крупных конфигурациях, таких как 1С:ERP Управление предприятием или 1С:Комплексная автоматизация, значительно упрощает ввод первичных документов. Однако пользователи часто сталкиваются с досадной проблемой: после ручного сопоставления номенклатуры поставщика с объектами в нашей базе данные «слетают». При попытке создать документ Приобретение услуг и прочих активов или Приобретение товаров и услуг система снова выдает ошибку о несопоставленной номенклатуре, а записи в регистре оказываются пустыми.
В этой статье мы подробно разберем, почему так происходит, как устроена внутренняя логика Библиотеки электронного документооборота (БЭД) и какие шаги предпринять, чтобы сопоставление сохранялось раз и навсегда.
Для начала проанализируем, где именно 1С хранит информацию о том, что «Услуга по доставке» от Поставщика А — это наша номенклатура «Транспортные расходы». В современных редакциях ERP используется двухуровневая система хранения, что часто становится причиной путаницы:
НоменклатураКонтрагентов. Это основной объект-владелец. Каждая запись здесь привязана к конкретному контрагенту и содержит текстовое наименование и артикул, как они указаны в базе поставщика.НоменклатураКонтрагентов. Этот регистр служит своего рода «индексом» для быстрого поиска. Он должен синхронизироваться со справочником.Проблема «исчезновения» часто заключается в том, что при записи данных в форму сопоставления ЭДО система пытается создать связь, но из-за программных ошибок в БЭД или нарушения целостности данных транзакция записи в справочник завершается, а регистр остается пустым или очищается при следующей попытке поиска.
Рассмотрим основные факторы, которые заставляют систему «забывать» ваш выбор:
1. Конфликт Уникальных Идентификаторов (GUID)
Система ЭДО в первую очередь ищет сопоставление по внутреннему идентификатору, который передает поставщик в XML-файле. Если поставщик пересоздал карточку номенклатуры в своей базе, его GUID изменился. Ваша старая запись в справочнике НоменклатураКонтрагентов больше не актуальна для алгоритма поиска 1С, и система предлагает создать новую, затирая или игнорируя старую.
2. Особенности учета услуг и единиц измерения
Как заметили участники обсуждения, проблема часто возникает именно в УПД на услуги. Проанализируем ситуацию: в ЭДО часто передаются единицы измерения, которые не совпадают с вашими (например, «усл. ед» в файле и «шт» в базе). Если механизм сопоставления настроен жестко, несовпадение единицы измерения может привести к тому, что система сочтет сопоставление невалидным и очистит поле Номенклатура.
3. Проблемы с владельцем записи (Партнер vs Контрагент)
В ERP разделены понятия Партнер (управленческий учет) и Контрагент (юридическое лицо). Записи в справочнике НоменклатураКонтрагентов должны быть жестко привязаны к юридическому лицу. Если при создании сопоставления произошла привязка к «неправильному» владельцу, финансовый документ (например, Приобретение услуг и прочих активов), создаваемый в контексте организации и контрагента, просто не «увидит» эту запись.
Первым делом нам необходимо проверить справочник НоменклатураКонтрагентов. Если для одного и того же товара поставщика создано несколько записей (например, одна с артикулом, другая без), система при автоматическом поиске может выбирать пустую или некорректную запись.
Рекомендуется воспользоваться обработкой «Поиск и удаление дублей» и объединить карточки номенклатуры контрагентов, оставив только те, где заполнена ссылка на вашу внутреннюю номенклатуру.
Проанализируем технический нюанс: в некоторых релизах ERP 2.5.7 существовала ошибка, при которой документ приобретения не мог быть создан (и сопоставление сбрасывалось), если у выбранной вами номенклатуры не была заполнена Группа финансового учета или Подразделение. Система пытается выполнить предварительную запись документа для проверки заполнения реквизитов, терпит неудачу и откатывает изменения, включая запись о сопоставлении. Для предотвращения таких сбоев можно использовать расширение для настройки обязательности заполнения подразделения.
Убедитесь, что во всех сопоставленных карточках номенклатуры заполнены основные реквизиты для бухгалтерского и управленческого учета.
Если штатные методы не помогают, рассмотрим возможность использования расширения. Нам нужно вмешаться в работу модуля БЭД, который отвечает за сопоставление. В БЭД версии 1.7 и 1.8 поиск реализован достаточно громоздко. Посмотрим на логику, которую можно реализовать в расширении для принудительного поиска по наименованию, если поиск по GUID провалился:
// Пример логики в расширении (псевдокод)
&После("НайтиСопоставленнуюНоменклатуру")
Процедура Расш_НайтиСопоставленнуюНоменклатуру(ДанныеНоменклатуры, Результат)
Если Не ЗначениеЗаполнено(Результат.Номенклатура) Тогда
// Если штатный поиск по УИД не дал плодов,
// пробуем найти вручную созданную запись в справочнике
ЗаписьСопоставления = Справочники.НоменклатураКонтрагентов.НайтиПоНаименованию(ДанныеНоменклатуры.НаименованиеПоставщика);
Если ЗначениеЗаполнено(ЗаписьСопоставления) И ЗначениеЗаполнено(ЗаписьСопоставления.Номенклатура) Тогда
Результат.Номенклатура = ЗаписьСопоставления.Номенклатура;
Результат.СтатусСопоставления = Перечисления.СтатусыСопоставленияНоменклатурыЭДО.Сопоставлено;
КонецЕсли;
КонецЕсли;
КонецПроцедуры
Такой подход гарантирует, что если вы один раз вручную указали связь, система будет приоритезировать ее, даже если идентификаторы в XML-файле изменились.
Важно помнить, что в релизах ERP начиная с 2.5.12, многие ошибки библиотеки ЭДО были исправлены. В частности, был переработан механизм фонового создания документов, который в версии 2.5.7 часто «обрывал» связь с формой сопоставления при длительном ожидании ответа сервера. При обслуживании нескольких конфигураций для своевременного получения исправлений можно автоматизировать процесс обновления и тестирования баз 1С в фоновом режиме по расписанию.
Для предотвращения «исчезновения» данных в будущем, придерживайтесь следующих правил:
Мы проанализировали ситуацию, выяснили причины и рассмотрели варианты решения проблемы. В большинстве случаев достаточно очистки дублей в справочнике номенклатуры контрагентов и корректного заполнения ГФУ, но в сложных случаях может потребоваться небольшая доработка логики поиска через расширение.