При обмене данными между конфигурациями 1С, особенно между 1С:Управление торговлей (УТ 11) и 1С:Бухгалтерия предприятия (БП 3.0) через универсальный формат, пользователи иногда сталкиваются с неприятной проблемой: задвоением, затроением и даже многократным повторением некоторых строк документов. Эта ошибка, как правило, проявляется уже на этапе формирования файла выгрузки, что указывает на некорректность данных еще до их загрузки в целевую базу. В данной статье мы подробно рассмотрим один из наиболее частых сценариев возникновения этой проблемы, а именно задвоение строк в документе "Приобретение товаров и услуг", и предложим конкретное решение.
Рассмотрим ситуацию, описанную пользователями, когда при выгрузке документа "Приобретение товаров и услуг" строки табличной части задваиваются. Важно отметить, что такая проблема может проявляться хаотично: где-то строки повторяются дважды, где-то трижды, а иногда и до десяти раз. При этом, если мы глубоко анализируем данные в исходной базе 1С:УТ с помощью Универсального отчета, все реквизиты, включая скрытые, кажутся идентичными для оригинальных и "проблемных" строк. Более того, если вручную скопировать "косячную" строку в документе УТ, ее копия уже выгружается нормально, хотя она также полностью идентична оригиналу с точки зрения данных в УТ. Это может указывать на то, что проблема лежит глубже, чем просто некорректно заполненные реквизиты.
Прежде чем перейти к основному решению, давайте разберем шаги, которые мы можем предпринять для первичной диагностики и проверки:
Проверка типовых правил обмена: В первую очередь, всегда необходимо убедиться, что правила обмена данными не подвергались никаким изменениям и являются типовыми. Если правила были изменены, то проблема может быть связана именно с этими модификациями. В нашем случае, автор сообщения подтвердил, что правила типовые.
Изучение файла выгрузки XML: Критически важно проверить содержимое самого файла выгрузки в формате XML. Если задвоение строк присутствует уже в этом файле, это однозначно указывает на проблему в логике формирования данных на стороне базы-источника (УТ), а не в процессе загрузки в базу-приемник (БП). Это подтверждает, что нам нужно искать причину именно в коде выгрузки УТ.
Различие между задвоением и разбиением: Важно четко понимать, действительно ли происходит задвоение количества или же система разбивает одну логическую строку на несколько по какому-либо признаку (например, по сериям, характеристикам, видам запасов). Автор подтвердил, что это именно задвоение, то есть повторяется то же количество по той же номенклатуре.
Перепроведение документов: В некоторых случаях снять с проведения и заново провести проблемный документ (именно снять, а не просто перепровести) может помочь. Это обновляет регистры, с которыми работает документ, и сбрасывает возможные кэшированные состояния, что иногда устраняет мелкие несоответствия.
Использование Универсального отчета: Для детального анализа данных в 1С:УТ мы можем использовать Универсальный отчет. Он позволяет просмотреть данные любых объектов конфигурации, включая табличные части документов, регистры и справочники, с возможностью вывода всех реквизитов, в том числе и скрытых. Это помогает убедиться, что проблема не связана с явными отличиями в данных.
Когда все поверхностные проверки проведены и не дают результата, мы начинаем углубляться в код обмена данными. В данном случае, корневая причина задвоения строк при выгрузке документов "Приобретение товаров и услуг" была обнаружена в типовом коде конфигурации 1С, особенно если в системе активно используются серии номенклатуры.
Давайте подробно рассмотрим, где именно кроется недоработка. Проблема локализована в общем модуле МенеджерОбменаЧерезУниверсальныйФормат, а конкретнее – в процедуре ПТиУ_РасширенныеДанныеИБ. Эта процедура отвечает за сбор и подготовку расширенных данных документа "Приобретение товаров и услуг" для последующей выгрузки в универсальном формате.
Внутри этой процедуры данные по товарам, которые подлежат выгрузке, формируются с помощью выполнения пакета запросов. Один из ключевых запросов (часто это третий подзапрос в пакете) создает временную таблицу с именем ТоварыДокумента. Эта временная таблица собирает информацию из нескольких табличных частей документа, включая табличную часть Товары и табличную часть Серии (если серии используются).
Основная причина задвоения заключается в следующем:
При связывании табличной части Товары с табличной частью Серии в запросе отсутствует корректное условие привязки серий к конкретному документу. Рассмотрим подробнее:
Для табличной части Товары в запросе присутствует условие Товары.Ссылка = &Ссылка. Это условие правильно фильтрует товары, выбирая только те, которые относятся к обрабатываемому документу.
Однако, для табличной части Серии, при формировании запроса, аналогичное условие Серии.Ссылка = &Ссылка отсутствует. Это является критической недоработкой.
Что происходит из-за этого?
Из-за отсутствия условия по ссылке для табличной части Серии, система начинает связывать каждую строку товаров из текущего документа не только с сериями, относящимися именно к этому документу, а практически со всеми сериями, которые есть в базе данных и совпадают по номенклатуре, характеристикам или другим общим признакам, независимо от того, к какому документу они относятся. Это приводит к так называемому "декартову произведению" или многократному дублированию строк в результирующей выборке данных, которая затем выгружается в XML-файл. Каждая строка товара из документа может быть связана со множеством "чужих" серий, что и вызывает задвоение.
Для исправления этой ошибки мы внесем небольшое, но критически важное изменение в текст запроса, который формируется в процедуре ПТиУ_РасширенныеДанныеИБ. Мы рекомендуем делать это с использованием механизма расширений конфигурации. Этот подход является предпочтительным, так как он позволяет сохранить конфигурацию на типовой поддержке и при этом внести необходимые доработки, не затрагивая основной код.
Разберем по шагам, как мы можем применить это исправление:
Откройте конфигуратор: Запустите 1С:Предприятие в режиме конфигуратора для вашей базы 1С:УТ 11.
Создайте новое расширение конфигурации: В меню "Конфигурация" выберите "Расширения конфигурации" -> "Добавить расширение". Присвойте ему осмысленное имя, например, "ИсправлениеОбменаПТиУ".
Добавьте общий модуль в расширение: Найдите в дереве конфигурации "Общие" -> "Общие модули" -> МенеджерОбменаЧерезУниверсальныйФормат. Правой кнопкой мыши выберите "Добавить в расширение". Это позволит нам модифицировать процедуры этого модуля в рамках расширения.
Измените процедуру ПТиУ_РасширенныеДанныеИБ: Откройте модуль МенеджерОбменаЧерезУниверсальныйФормат в расширении. Найдите в нем процедуру ПТиУ_РасширенныеДанныеИБ. Правой кнопкой мыши по названию процедуры и выберите "Изменить с помощью расширения".
Найдите блок формирования и выполнения запроса: Внутри процедуры ПТиУ_РасширенныеДанныеИБ мы увидим код, который формирует текст запроса и затем его выполняет. Обычно это выглядит следующим образом:
Запрос.Текст = ТекстЗапроса;
РезультатыЗапроса = Запрос.ВыполнитьПакет();
Переменная ТекстЗапроса содержит полный текст SQL-запроса, который был сформирован системой. Мы должны модифицировать этот текст перед его выполнением.
Вставьте строку модификации запроса: Между двумя вышеуказанными строками кода необходимо вставить одну строку, которая будет добавлять недостающее условие в текст запроса. Мы используем стандартную функцию СтрЗаменить() для поиска и замены части текста запроса:
Запрос.Текст = ТекстЗапроса;
Запрос.Текст = СтрЗаменить(Запрос.Текст, "И Товары.Номенклатура.ТипНоменклатуры В", "И Серии.Ссылка = &Ссылка И Товары.Номенклатура.ТипНоменклатуры В");
РезультатыЗапроса = Запрос.ВыполнитьПакет();
Давайте подробно разберем эту строку. Мы берем текущий текст запроса (Запрос.Текст) и используем функцию СтрЗаменить(). В этой функции мы ищем конкретную подстроку "И Товары.Номенклатура.ТипНоменклатуры В". Эта подстрока является частью запроса, которая, как правило, стабильна и присутствует в месте, где нам нужно вставить наше дополнительное условие. Затем мы заменяем найденную подстроку на ту же самую подстроку, но с добавлением нашего условия: "И Серии.Ссылка = &Ссылка И Товары.Номенклатура.ТипНоменклатуры В". Ключевым здесь является добавление "И Серии.Ссылка = &Ссылка". Это условие гарантирует, что при связывании табличных частей Товары и Серии в запросе будут учитываться только те серии, которые непосредственно относятся к текущему документу, указанному в параметре &Ссылка.
Сохраните изменения и обновите конфигурацию: После внесения изменений сохраните модуль в расширении и обновите конфигурацию базы данных. Это применит ваше расширение к рабочей базе.
Проверьте результат: Теперь мы можем провести тестовую выгрузку ранее проблемного документа "Приобретение товаров и услуг". Внимательно проверьте сформированный XML-файл на отсутствие задвоенных строк. Затем загрузите его в 1С:БП 3.0 и убедитесь, что документ загрузился корректно, без дублирования.
Хотя проблема с некорректной связью серий номенклатуры является одной из наиболее частых причин задвоения строк при выгрузке "Приобретения товаров и услуг" из УТ 11 в БП 3.0, существуют и другие факторы, которые могут влиять на корректность обмена данными. Мы рассмотрим их, чтобы дать более полную картину возможных проблем и их решений.
Справочник ЕдиницыИзмерения: Несоответствия в справочнике ЕдиницыИзмерения между базами-источником и базой-приемником могут вызывать ошибки или некорректное сопоставление данных. Мы рекомендуем тщательно проверить, как заполнены и сопоставлены единицы измерения для всех номенклатурных позиций. В частности, обратите внимание на основные единицы измерения и коэффициенты пересчета.
Проблемы идентификации строк в бухгалтерии: В некоторых сценариях задвоение строк может происходить не из-за ошибок на этапе выгрузки из УТ, а на этапе загрузки и обработки в БП. Иногда это связано с тем, что идентификатор строки (уникальный ключ) передается только один раз или формируется таким образом, что система в бухгалтерии не может корректно "схлопнуть" или сопоставить повторяющиеся строки. Это было замечено, например, при обмене документом Корректировка поступления из УТ в БП, где задвоение могло происходить по всей номенклатуре независимо от поставщика или специфики корректировки. Если строки не имеют уникального идентификатора для сопоставления, БП может воспринимать каждую строку как новую, даже если по сути она дублирует уже имеющуюся.
Настройки синхронизации: Мы должны регулярно проверять и актуализировать настройки синхронизации данных. Это включает в себя корректное сопоставление счетов учета номенклатуры, статей затрат, налоговых ставок и других параметров. Неправильно настроенные правила могут приводить к ошибкам в выгрузке или некорректной интерпретации данных в целевой базе. Также убедитесь, что у пользователей, от имени которых выполняется обмен, есть все необходимые права доступа.
Использование внешних обработок для обмена: В случаях, когда типовой обмен данными не удовлетворяет специфическим требованиям или постоянно вызывает проблемы, мы можем рассмотреть возможность использования внешних обработок для обмена. Существуют сторонние или специально разработанные решения, которые позволяют более гибко настраивать фильтрацию документов, выборочно выгружать нормативно-справочную информацию и обеспечивать односторонний или двусторонний перенос данных с более тонкой настройкой правил. Такие обработки могут быть полезны для обхода специфических ошибок типового обмена, если исправление кода напрямую не представляется возможным или слишком рискованно.
Таким образом, мы видим, что проблема задвоения строк при обмене данными между УТ 11 и БП 3.0, хотя и может быть вызвана различными факторами, часто имеет конкретное техническое решение. Внимательный анализ кода и применение точечных исправлений через расширения конфигурации позволяют не только устранить ошибку, но и поддерживать типовую конфигурацию на поддержке, что крайне важно для стабильной работы системы.