Как в 1С:Бухгалтерии 3.0 настроить загрузку выписки и идентификацию физлиц при поступлении средств через банк?

Программист 1С v8.3 (Управляемые формы) 1C:Бухгалтерия Бухгалтерский учет Финансы и профессиональные услуги
← На главную

При загрузке банковских выписок в конфигурацию 1С:Бухгалтерия предприятия 3.0 бухгалтеры часто сталкиваются с ситуацией, когда входящие платежи от физических лиц определяются как поступления от самого банка. В результате вместо реального покупателя в создаваемом документе Поступление на расчетный счет подставляется контрагент-банк с видом операции Прочее поступление. Разберем, почему так происходит, какие технические нюансы необходимо учесть при доработке алгоритма и как правильно сопоставлять данные.

Причина штатного поведения программы

Формат передачи данных вида ПАО СБЕРБАНК//ИВАНОВ ИВАН ИВАНОВИЧ//770123456789//ГОРОД МОСКВА...// регламентирован Положением Банка России № 762-П. Данный стандарт определяет правила заполнения реквизита 16 («Плательщик») при переводах физических лиц без открытия расчетного счета.

Типовой механизм загрузки выписки 1С выполняет сопоставление контрагентов по строгому порядку:

  1. По комбинации реквизитов ПлательщикИНН и ПлательщикКПП;
  2. По реквизиту ПлательщикРасчСчет;
  3. По полному совпадению наименования.

Поскольку в платежном поручении в полях ИНН и расчетного счета передаются реквизиты банка и его транзитный счет (например, 40911, 30232), система сопоставляет контрагента именно с банковской организацией. Это не только искажает расчеты по счету 62, но и создает налоговые риски: по требованиям 54-ФЗ расчеты с физическими лицами требуют формирования фискального чека, а расчеты B2B между юрлицами — нет.

Особенности парсинга строки плательщика

Рассмотрим структуру поля плательщика. Строка разбивается специальными разделителями //:

ПАО СБЕРБАНК//ПРИМЕРНАЯ НАДЕЖДА ПАВЛОВНА//444055501401//РОССИЯ 119361 МОСКВА...//

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

  1. Непостоянство структуры и отсутствие ИНН: Третье поле (ИНН физлица) заполняется банком только при наличии информации. Если ИНН отсутствует, передается 0, пробел либо разделители идут подряд: ////.
  2. Паспортные данные вместо ИНН: Ряд банков при отсутствии ИНН подставляет в блок серию и номер паспорта (например, ПАСПОРТ 1234 567890), что требует строгой проверки регулярным выражением на 12 цифр.
  3. Символы внутри адреса: Поле адреса может содержать дефисы, дроби и косые черты (например, д. 12/1), поэтому разбиение строки необходимо выполнять строго по двойному слэшу //, а не по одиночному.
  4. Полные тезки: Если ИНН физического лица не передан, сопоставление исключительно по ФИО может приводить к дублированию или неверному сопоставлению при наличии однофамильцев.

Архитектурный нюанс: работа с табличной частью и временным хранилищем

Проанализируем ключевую особенность подсистемы обмена с банком в 1С:Бухгалтерии 3.0. Простое изменение контрагента в табличной части на форме обработки КлиентБанк не приведет к тому, что в созданный документ запишется нужный контрагент.

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

Пример программного разбора строки и сопоставления

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


Функция ОпределитьКонтрагентаФизЛицо(Знач СтрокаПлательщика)
    Разделитель = "//";
    МассивЧастей = СтрРазделить(СтрокаПлательщика, Разделитель, Ложь);
    
    // Проверяем формат: Банк // ФИО // ИНН // Адрес //
    Если МассивЧастей.Количество() < 2 Тогда
        Возврат Справочники.Контрагенты.ПустаяСсылка();
    КонецЕсли;
    
    ФИО = СокрЛП(МассивЧастей[1]);
    ИНН = "";
    Если МассивЧастей.Количество() >= 3 Тогда
        ИНН = СокрЛП(МассивЧастей[2]);
        Если СтрДлина(ИНН) <> 12 Или СтрНайти(ИНН, " ") > 0 Тогда
            ИНН = ""; // Некорректный или отсутствующий ИНН физлица
        КонецЕсли;
    КонецЕсли;
    
    НайденныйКонтрагент = Справочники.Контрагенты.ПустаяСсылка();
    
    // Поиск по ИНН среди физлиц
    Если ЗначениеЗаполнено(ИНН) Тогда
        НайденныйКонтрагент = Справочники.Контрагенты.НайтиПоРеквизиту("ИНН", ИНН);
    КонецЕсли;
    
    // Поиск по наименованию, если по ИНН не найден
    Если Не ЗначениеЗаполнено(НайденныйКонтрагент) И ЗначениеЗаполнено(ФИО) Тогда
        НайденныйКонтрагент = Справочники.Контрагенты.НайтиПоНаименованию(ФИО, Истина);
    КонецЕсли;
    
    // Создание нового контрагента при необходимости
    Если Не ЗначениеЗаполнено(НайденныйКонтрагент) И ЗначениеЗаполнено(ФИО) Тогда
        НовыйОбъект = Справочники.Контрагенты.СоздатьЭлемент();
        НовыйОбъект.Наименование = ФИО;
        НовыйОбъект.НаименованиеПолное = ФИО;
        НовыйОбъект.ЮрФизЛицо = Перечисления.ЮрФизЛицо.ФизЛицо;
        НовыйОбъект.ИНН = ИНН;
        НовыйОбъект.Записать();
        
        // Создание основного договора с покупателем
        Договор = Справочники.ДоговорыКонтрагентов.СоздатьЭлемент();
        Договор.Владелец = НовыйОбъект.Ссылка;
        Договор.ВидДоговора = Перечисления.ВидыДоговоровКонтрагентов.СПокупателем;
        Договор.Наименование = "Основной договор";
        Договор.Записать();
        
        НайденныйКонтрагент = НовыйОбъект.Ссылка;
    КонецЕсли;
    
    Возврат НайденныйКонтрагент;
КонецФункции

Альтернативные способы организации учета

Если платежей от физлиц поступает много, разбор текстовой строки не всегда обеспечивает 100% точность из-за опечаток операционистов банка. В таких случаях на практике применяют следующие решения:

  1. Штрихкодирование и лицевые счета: Формирование квитанций с QR-кодом, содержащим уникальный лицевой счет клиента. При оплате лицевой счет автоматически попадает в назначение платежа, откуда сопоставляется постобработкой.
  2. Загрузка через реестры платежей: Заключение договора с банком на прием платежей физлиц, при котором банк передает отдельный файл реестра (в формате XML, CSV или TXT). Типовая 1С:Бухгалтерия 3.0 поддерживает штатную загрузку таких реестров с автоматическим созданием расчетов по каждому покупателю.
  3. Интеграция с СБП: Применение Системы быстрых платежей, где идентификация поступившей оплаты происходит по уникальному идентификатору операции.
← На главную