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