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