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