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