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