Как настроить универсальный обмен 1С:БП 3.0 для корректной передачи документов с увеличенной длиной номеров?

При работе с информационными системами 1С:Предприятие мы часто сталкиваемся с необходимостью обмена данными между различными конфигурациями, даже если они однотипные, например, между несколькими базами 1С:Бухгалтерии 3.0. Универсальный обмен данными на базе формата EnterpriseData предоставляет мощный механизм для такой синхронизации. Однако, любые отклонения от стандартных настроек типовых конфигураций могут приводить к непредвиденным проблемам.

Представим ситуацию: в одной из ваших информационных баз 1С:БП 3.0 была произведена доработка, которая затронула длину номеров некоторых документов. Изначально номера документов в типовой конфигурации 1С:Бухгалтерия 3.0 обычно имеют длину 11 символов. После доработки длина номера была увеличена, скажем, до 20 символов. Когда мы пытаемся настроить универсальный обмен между такой модифицированной базой и другой базой (даже типовой или с аналогичными изменениями), возникает проблема: система обмена сообщает об ошибке, связанной с нестандартной длиной номеров. Более того, документы, имеющие основание (например, счета-фактуры, созданные на основании документов поступления или реализации), не могут найти свои документы-основания в базе-приемнике. Это происходит потому, что при выгрузке номер документа-основания обрезается до стандартных 11 символов, и в приемнике такой "урезанный" номер, естественно, не соответствует фактическому длинному номеру.

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

Понимание механизма универсального обмена и XDTO-пакетов

Прежде чем перейти к решению, давайте разберем основные принципы работы универсального обмена 1С. Универсальный формат обмена EnterpriseData, разработанный фирмой "1С", предназначен для стандартизации синхронизации данных между различными конфигурациями 1С:Предприятие (такими как БП 3.0, ERP 2, УТ 11, КА 2, ЗУП 3). Он позволяет обмениваться бизнес-сущностями (документами, справочниками) в унифицированном XML-формате.

Ключевую роль в этом механизме играют XDTO-пакеты. Они представляют собой описания структур данных (схемы), на основе которых формируются и распознаются XML-файлы обмена. В конфигурации 1С эти пакеты можно найти в ветке "XDTO пакеты". Каждый XDTO-пакет определяет типы данных, их свойства, максимальную длину строк, точность чисел и другие параметры. Например, если в XDTO-пакете для поля "Номер документа" установлена максимальная длина 11 символов, то при выгрузке любой более длинный номер будет автоматически обрезан до этой длины, что и приводит к нашим ошибкам.

Формат EnterpriseData имеет версии, обозначаемые как Major.Minor.Patch (например, 1.8.6). Изменения Minor версии обычно не нарушают совместимость, тогда как изменения Major версии могут потребовать существенной доработки правил обмена.

Почему стандартные настройки не подходят?

Типовые конфигурации 1С по умолчанию используют 11-значную длину для номеров документов. Если в вашей базе номера были увеличены, например, до 20 символов, стандартные правила обмена, основанные на типовых XDTO-схемах, не будут "знать" об этом изменении. Они продолжат ожидать и обрабатывать номера длиной до 11 символов, что неизбежно приведет к их обрезке при выгрузке в файл обмена. Это и стало причиной того, что документы-основания, такие как ПоступлениеТоваровУслуг, при обмене теряют часть своего номера, а связанные с ними Счета-фактуры в приемнике не могут найти "свои" основания.

Неэффективный подход: попытка модификации кода на стороне правил обмена

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

Процедура ПКО_Документ_ПоступлениеТоваровУслуг_Отправка_ПриОтправкеДанных(ДанныеИБ, ДанныеXDTO, КомпонентыОбмена, СтекВыгрузки)
    Если СтекВыгрузки.Количество() > 1 Тогда
        Возврат;
    КонецЕсли;
    //-> КравА 30.06.2023 - Пример неверного подхода
    НомерДанныхXDTO = СокрЛП(ДанныеXDTO.КлючевыеСвойства.Номер);
    НомерДанныхXDTO = СтрЗаменить(НомерДанныхXDTO, " ", "");
    Если СтрДлина(НомерДанныхXDTO) > 11 Тогда
        Если СтрНайти(НомерДанныхXDTO, "00000000") Тогда
            НомерДанныхXDTO = СтрЗаменить(НомерДанныхXDTO, "00000000", "");    
            ДанныеXDTO.КлючевыеСвойства.Номер = НомерДанныхXDTO;
        Иначе
            ДанныеXDTO.КлючевыеСвойства.Номер = Прав(НомерДанныхXDTO, 11); // Здесь номер обрезается
        КонецЕсли;    
    КонецЕсли;
    //<- КравА 30.06.2023
    ДанныеXDTO.Вставить("Склад", СкладДляВыгрузки(ДанныеИБ.Склад, КомпонентыОбмена.ПараметрыКонвертации));

В этом примере мы видим попытку получить номер, удалить из него пробелы и, если он длиннее 11 символов, либо убрать последовательность "00000000", либо обрезать его справа до 11 символов. Такой подход является нежелательным по нескольким причинам:

1. Потеря информации: Обрезка номера до 11 символов гарантирует, что в приемнике документ не будет найден по полному номеру, создавая все те же проблемы со связанными документами.
2. Неуниверсальность: Придется писать аналогичный код для каждого документа, у которого была изменена длина номера.
3. Риск ошибок: Ручная обработка номеров может привести к непредсказуемым результатам, особенно если номера имеют сложную структуру.
4. Сложность поддержки: При обновлении правил обмена или конфигурации этот код может быть утерян или перестать работать.

Поэтому нам нужен более системный и корректный подход, который напрямую затрагивает структуру обмена.

Правильное решение: изменение максимальной длины номера в XDTO-пакете

Единственно верным и системным решением данной проблемы является изменение определения максимальной длины номера непосредственно в соответствующем XDTO-пакете. Это гарантирует, что система обмена будет выгружать и ожидать номера заданной длины.

Рассмотрим по шагам, как это можно сделать:

1. Откройте конфигурацию: Запустите 1С:Предприятие в режиме "Конфигуратор" и откройте конфигурацию базы данных, из которой производится обмен (или обе, если они одинаковые и изменения нужно внести симметрично).
2. Найдите ветку "XDTO-пакеты": В дереве конфигурации найдите ветку "XDTO-пакеты". Раскройте ее.
3. Определите нужный XDTO-пакет: Для универсального обмена, как правило, используется пакет EnterpriseData. В нашем случае это EnterpriseData_1_8_6 (версия может отличаться). Раскройте этот пакет.
4. Найдите ключевые свойства документов: Внутри пакета EnterpriseData_1_8_6 найдите определения типов данных для ключевых свойств документов, номера которых были увеличены. Автор темы упоминал документы ПоступлениеТоваровУслуг и РеализацияТоваровУслуг. Соответственно, нам нужно найти следующие типы:
   • КлючевыеСвойстваПоступлениеТоваровУслуг
   • КлючевыеСвойстваРеализацияТоваровУслуг
   • Если есть другие документы с измененной длиной номера (например, СчетФактураВыданный, СчетФактураПолученный и т.д.), необходимо будет найти их соответствующие ключевые свойства.
   Каждое из этих ключевых свойств представляет собой структуру, описывающую основные реквизиты документа, используемые для его идентификации при обмене.
5. Измените свойство "Номер": Для каждого найденного типа ключевых свойств (например, КлючевыеСвойстваПоступлениеТоваровУслуг) найдите в списке его свойств реквизит Номер. Выделите его.
6. Установите "Максимальное количество": В окне свойств для реквизита Номер найдите поле "Максимальное количество" (или "Максимальная длина", в зависимости от версии платформы и интерфейса). Измените его значение с 11 на 20 (или на ту длину, которая соответствует вашей доработанной конфигурации).

После внесения этих изменений в конфигурацию, сохраните ее и обновите базу данных. Теперь при следующем обмене система 1С будет выгружать полные 20-значные номера документов ПоступлениеТоваровУслуг и РеализацияТоваровУслуг, а также других документов, для которых вы изменили XDTO-определение. Это позволит счетам-фактурам и другим связанным документам корректно находить свои основания в базе-приемнике, так как номера будут полностью совпадать.

Особенности работы с номерами документов в 1С и сопоставление объектов

Чтобы глубже понять контекст проблемы и решения, рассмотрим некоторые аспекты работы с номерами документов и механизмы сопоставления объектов в 1С.

• Автоматическая нумерация и префиксы: В 1С номер документа является обязательным реквизитом. Система автоматически присваивает его при записи, обеспечивая уникальность. Для предотвращения дублирования номеров, особенно при работе с несколькими организациями или распределенными информационными базами (РИБ), используются префиксы организации (например, ОРГ-000001) и префиксы информационной базы (например, Б01-000001). Последние особенно важны при синхронизации, так как позволяют различать документы, созданные в разных базах.
• Изменение свойств нумерации: На уровне объектов конфигурации можно настроить параметры нумерации: длину номера, контроль уникальности, автонумерацию, периодичность (например, в пределах года) и тип номера (строка или число). Однако эти настройки относятся к внутреннему хранению данных, а не к формату обмена, который регулируется XDTO.
• Сопоставление объектов по GUID: Внутренние уникальные идентификаторы объектов (GUID - Global Unique Identifier) являются основным механизмом для установления соответствия между объектами в разных базах данных. При обмене система 1С в первую очередь пытается найти объект по его GUID. Если GUID совпадают (что происходит, когда объект был выгружен из одной базы и загружен в другую), сопоставление проходит успешно, независимо от номера документа. Проблема возникает, когда номер документа используется как поле поиска для связанных объектов или когда GUID по какой-то причине не совпадает.
• Поля поиска: В случаях, когда GUID объектов могут отличаться (например, если идентичные по смыслу объекты были созданы параллельно в разных базах), для сопоставления используются так называемые "поля поиска". Это могут быть комбинации реквизитов, которые вместе образуют уникальный идентификатор объекта (например, "Дата + Номер + Организация"). Именно здесь обрезанный номер может стать критической проблемой, если он входит в поля поиска.
• Регистр сведений "Публичные идентификаторы синхронизируемых объектов": 1С использует этот регистр для хранения информации о соответствии объектов с разными GUID. Он помогает системе "запомнить", что объект X в базе A соответствует объекту Y в базе B, даже если их GUID изначально отличались.

Рекомендации и возможные проблемы

1. Используйте расширения конфигурации: Начиная с версии 8.3.22 платформы 1С, появилась возможность изменять параметры номеров и кодов объектов (включая увеличение длины номера) с помощью расширений конфигурации. Это предпочтительный метод доработки, так как он позволяет сохранить конфигурацию на полной поддержке и значительно упрощает процесс обновления. Если ваша платформа позволяет, рассмотрите возможность переноса изменения длины номера документа в расширение.

2. Тестирование обмена: После любых изменений в правилах обмена или XDTO-пакетах обязательно проводите тщательное тестирование на копиях баз данных. Начните с небольшого объема данных, включающего проблемные документы и их основания, чтобы убедиться в корректности выгрузки и загрузки.

3. Конфликты версий и дублирование: При обмене могут возникать и другие проблемы, например, конфликты версий (когда один и тот же объект изменялся в обеих базах) или дублирование номеров, если не используются префиксы или нарушается уникальность. Внимательно следите за журналом регистрации и сообщениями об ошибках.

4. Проверьте связанные XDTO-пакеты: Если после изменения длины номера для основного документа (например, ПоступлениеТоваровУслуг) все еще возникают ошибки со связанными документами (например, СчетФактураПолученный), проверьте соответствующие XDTO-определения для этих связанных документов. Возможно, их поле "НомерДокументаОснования" или аналогичное также имеет ограничение длины, которое необходимо скорректировать.

В нашем случае, когда автор темы столкнулся с новой ошибкой при получении счета-фактуры после корректировки XDTO для поступления, это может указывать на то, что необходимо было также изменить XDTO-пакет для самого счета-фактуры или его поля, связанного с номером основания.

Таким образом, системное решение проблемы обрезки длинных номеров документов при универсальном обмене 1С заключается в прямой модификации XDTO-пакетов, определяющих формат обмена. Это обеспечивает соответствие структуры выгружаемых данных фактическим данным в информационной базе и позволяет избежать ошибок при сопоставлении связанных документов.