← На главную

Рассмотрим распространенную ситуацию, возникающую при интеграции различных конфигураций 1С. Предположим, вы настроили обмен между 1С:Комплексная автоматизация (КА2) и 1С:Бухгалтерия предприятия (БП 3.0). В базе-источнике создается документ поступления безналичных денежных средств с видом операции «Поступление по платежным картам». После обмена в БП 3.0 документ успешно загружается и корректно заполняется, устанавливается счет учета 57.03.

Однако, если позднее в базе-источнике изменить вид операции на «Инкассация» и произвести повторный обмен, мы увидим проблему: в базе-приемнике вид операции поменяется, но счет учета останется прежним (57.03), хотя для инкассации должен применяться счет 57.01 (или 57.1). Проанализируем причины такого поведения системы и разберем по шагам доступные способы решения.

Основные причины проблемы со счетами при повторном обмене

Выясним причину, по которой типовой механизм не перезаполняет счета. Проблема кроется в нескольких архитектурных особенностях обмена и логике самой программы-приемника:

1. Ограничения формата EnterpriseData: Синхронизация между КА2 и БП 3.0 осуществляется через универсальный формат EnterpriseData. При загрузке изменений в уже существующий документ БП обновляет его реквизиты, но намеренно блокирует автоматическое перезаполнение счетов учета. Это сделано для защиты данных: система предполагает, что бухгалтер мог вручную скорректировать счета, и затирать эти изменения при фоновом обмене небезопасно.
2. Специфика смены вида операции: Изменение вида операции часто влечет за собой глобальную смену логики документа. Типовой механизм обмена обновляет атрибут, но не вызывает внутренние процедуры формы документа БП (которые при ручном выборе операции перестраивают реквизиты и очищают неактуальные счета).
3. Влияние статей ДДС: В БП 3.0 счет учета может определяться привязкой к статье движения денежных средств. При изменении вида операции в базе-источнике статья ДДС могла остаться прежней, либо сопоставиться со старыми значениями, из-за чего система сохраняет старый счет 57.03.

Базовые проверки перед началом исправления

Прежде чем приступать к глубоким доработкам, проанализируем базовые вещи, на которые указывают специалисты:

1. Проверка Журнала регистрации: Заполнение счетов учета обычно происходит после УСПЕШНОГО завершения обмена. Если при загрузке любого объекта в пакете происходит ошибка, фоновые обработчики могут прерваться, и счета не заполнятся. Обязательно проверьте Журнал регистрации на наличие ошибок синхронизации.
2. Повторная регистрация: Попробуйте принудительно заново включить этот проблемный документ в состав пакета обмена в узле синхронизации и выполнить выгрузку еще раз.

Проверенные способы решения проблемы

Рассмотрим подробнее варианты решения, если базовые проверки не помогли. Вы можете выбрать наиболее подходящий метод в зависимости от ваших компетенций и прав доступа.

Способ 1. Очистка счетов и перепроведение в БП 3.0

Если проблема носит массовый характер, но вы не хотите менять код, воспользуйтесь типовой обработкой. С помощью стандартной обработки «Групповое изменение реквизитов» выберите проблемные документы в БП 3.0. Принудительно очистите в них поля счетов учета и запустите перепроведение. Если счет не указан в документе, программа при проведении автоматически определит и подставит правильный счет согласно текущему виду операции «Инкассация».

Способ 2. Удаление документа в базе-приемнике

Это самый надежный путь обхода проблемы без доработок. Необходимо полностью удалить (а не просто пометить на удаление) сбойный документ в БП 3.0. После этого зарегистрируйте его к обмену в КА2 повторно. Документ загрузится «с нуля» как новый, и алгоритмы первоначального заполнения счетов отработают абсолютно корректно.

Способ 3. Программная доработка (расширение)

Для программистов лучшим решением станет доработка через расширение конфигурации на стороне БП 3.0. Можно подписаться на события загрузки и переопределить поведение модуля менеджера обмена. Логика должна проверять: если у существующего документа меняется вид операции, система должна принудительно вызывать типовой экспортный метод ЗаполнитьСчетаУчета(). Таким образом, счета будут актуализироваться автоматически.

Альтернативные подходы и настройки

Посмотрим на дополнительные настройки, которые могут предотвратить появление таких ситуаций в будущем:

1. Отключение автоматического проведения: В настройках узла синхронизации на стороне БП 3.0 можно снять флаг автоматического проведения документов при загрузке. Документы будут поступать просто записанными. При последующем ручном перепроведении или при закрытии месяца система заново оценит вид операции и скорректирует счета.
2. Настройка ГФУ (Групп финансового учета): В КА2 проверьте правила отражения в регламентированном учете. Убедитесь, что для хозяйственной операции «Инкассация» корректно прописана ГФУ со счетом 57.01. При строгой настройке КА2 сможет передавать этот счет в XML-пакете обмена в явном виде.
3. Локальное ручное исправление: Если смена операций с платежных карт на инкассацию — это исключительный и редкий кейс, целесообразнее договориться с бухгалтерией о ручном исправлении вида операции и счета непосредственно в БП после синхронизации. Это избавит от необходимости усложнять правила обмена и писать лишний код.

Используя предложенные методы, вы сможете настроить корректное отражение операций и избежать путаницы со счетами бухгалтерского учета при постоянном обмене данными между системами.