При использовании технологии DirectBank (бесфайловый обмен с банком) пользователи конфигурации 1С:Управление торговлей 11.4 часто сталкиваются с неприятной ситуацией: в загруженных платежных поручениях поле Корсчет заполняется значением БИК банка. Это происходит не для всех операций, а выборочно (обычно в 20–30% случаев), что затрудняет поиск системной ошибки. Особенно часто эта проблема проявляется при работе с банком Авангард.
В рамках данной статьи мы проведем детальный технический анализ проблемы, разберем причины возникновения этой ошибки и определим шаги по ее устранению. Мы проанализируем структуру банковских данных и особенности реализации подсистемы электронного обмена в разных конфигурациях 1С.
Давайте проанализируем, почему система ведет себя именно так. Первое, на что стоит обратить внимание, — это структура входящего XML-пакета, который 1С получает от банковского сервера. Технология DirectBank подразумевает передачу данных в строго определенном формате. Однако реализация этого формата на стороне конкретного банка и его обработка в 1С могут иметь нюансы.
Рассмотрим специфику счетов, по которым возникает ошибка. Как показывает практика, проблема чаще всего проявляется в операциях, где используются счета, начинающиеся на 30302. Согласно банковскому плану счетов, это счет "Расчеты с филиалами, расположенными в Российской Федерации". Его назначение — учет сумм при осуществлении расчетных операций между филиалами внутри одной кредитной организации.
Выясним причину подмены данных. В операциях по счету 30302 фактически отсутствует понятие корреспондентского счета в том виде, в котором мы привыкли видеть его для межбанковских расчетов. В XML-ответе от банка тег, отвечающий за Корсчет, может быть пустым или вовсе отсутствовать. Программный код УТ 11.4 в некоторых релизах имеет недостаточно гибкий алгоритм парсинга: если ожидаемое значение в поле корсчета не найдено, система "подтягивает" данные из соседнего доступного тега, которым оказывается БИК.
Интересным фактом является то, что в конфигурации 1С:Бухгалтерия предприятия (БП) аналогичная выписка из того же банка через DirectBank может загружаться корректно. Это наводит на мысль, что корень проблемы кроется в различии общих модулей обработки данных.
Проанализируем ситуацию подробнее. В БП алгоритм сопоставления банковских реквизитов реализован с дополнительными проверками. Система проверяет длину значения (маска счета должна составлять 20 знаков) и сопоставляет его с классификатором. В УТ 11.4 на определенных этапах развития конфигурации подсистема ЭлектронноеВзаимодействие использовала более упрощенный механизм, который жестко привязывался к позиции данных в XML-структуре. При пропуске банком одного из необязательных тегов происходило смещение, и данные интерпретировались неверно.
Первым делом нам необходимо убедиться, что в нашей базе 1С актуальны сведения о банках и их филиалах. Если банк контрагента указан в системе как "дополнительный офис" или филиал, не имеющий собственного корсчета (что типично для внутрибанковских расчетов через 30302), это может сбивать алгоритмы автоматического заполнения.
Выполним следующие действия:
Банки и найдем запись банка «Авангард» (или иного банка, по которому идет ошибка).Иногда проблему удается решить через изменение способа сопоставления данных в настройках обмена. Если система не может однозначно определить банк или расчетный счет, она может применять стандартные (и иногда ошибочные) алгоритмы заполнения.
Разберем, как это настроить. В настройках обмена с банком попробуйте изменить приоритет идентификации. Если по умолчанию стоит идентификация по Расчетному счету, это заставляет систему брать реквизиты банка "как есть" из файла обмена. Если переключить логику на поиск по ИНН/КПП контрагента, система будет вынуждена пересчитать реквизиты банка на основании данных, уже имеющихся в справочниках 1С, что позволит избежать записи БИК в поле Корсчет.
Если обновление конфигурации до последнего релиза по каким-то причинам невозможно или не помогает, следует обратить внимание на технологические патчи (исправления). Фирма 1С выпускает специфические исправления для подсистемы БСП (Библиотека стандартных подсистем), которые корректируют "жадный" парсинг XML.
Проанализируем возможный программный обход проблемы. Если вы программист, вы можете внести изменения в модуль, отвечающий за разбор XML-ответа DirectBank. Логика проверки должна выглядеть примерно так:
// Пример логики проверки корректности корсчета
Если СтрДлина(ПолученноеЗначениеКорсчета) <> 20 Тогда
// Если длина не равна 20, вероятно, это БИК или мусорные данные
Корсчет = ""; // Оставляем пустым для последующего заполнения из справочника
Иначе
Корсчет = ПолученноеЗначениеКорсчета;
КонецЕсли;
Такой подход позволит системе проигнорировать ошибочный БИК и позже, при записи документа, подставить верный корреспондентский счет из классификатора банков или оставить поле пустым, если расчеты идут внутри филиальной сети (счет 30302).
Чтобы окончательно убедиться в источнике ошибки, рекомендуется выгрузить данные из банка не через DirectBank, а обычным текстовым файлом (формат 1C:Предприятие - Клиент-банк). Сравните данные в файле с теми, что приходят по каналу DirectBank. Если в текстовом файле поле Корсчет заполнено верно, значит, проблема стопроцентно локализована в модуле 1С ДиректБанк и его взаимодействии с XML-сервисом банка.
Рассмотрим структуру типичной записи в файле обмена, на которой спотыкается система:
В этом случае система видит отсутствие данных в Корсчет и ошибочно берет следующее значение из структуры — БИК. Решением здесь будет только обновление подсистемы ЭлектронноеВзаимодействие до версии, где этот "баг" исправлен, либо установка соответствующего расширения, корректирующего парсинг.
Мы выяснили, что проблема некорректного заполнения поля Корсчет значением БИК в УТ 11.4 при работе с банком Авангард через DirectBank носит технический характер и связана с обработкой внутрибанковских счетов 30302.
Подведем итог необходимых действий:
Корсчет и очищать его, если значение не соответствует 20-значному формату банковского счета.Совместный анализ структуры данных и механизмов 1С позволяет эффективно локализовать и устранить подобные ошибки в работе банковских подсистем.