Как исправить ошибку уникальности номера платежных поручений при загрузке из клиент-банка в 1С:Управление торговлей 10.3?

← На главную

При работе в 1С:Управление торговлей 10.3 пользователи часто сталкиваются с неприятной ситуацией: при попытке загрузить выписку из клиент-банка система выдает ошибку о невозможности записи документа. Сообщение выглядит примерно так: "Документ Исходящее платежное поручение №... не создан! Произошли ошибки при записи!". Причина всегда одна — нарушение уникальности номера. Мы разберем, почему типовой механизм нумерации дает сбой, как найти «виновные» документы и какие правки нужно внести в код, чтобы забыть об этой проблеме навсегда.

Почему возникает конфликт нумерации?

Для начала проанализируем ситуацию. В 1С:Предприятии существует два способа создания документа: вручную и программно. Когда бухгалтер создает платежку вручную, платформа автоматически вызывает метод УстановитьНовыйНомер(), который берет последний номер в базе и прибавляет к нему единицу. Однако типовая обработка «Клиент-банк» ведет себя иначе.

Проблема заключается в том, что разработчики типового решения заложили в обработку алгоритм «интеллектуального» присвоения номера. Программа считывает номер платежного поручения из текстового файла, полученного от банка, и пытается «втиснуть» его в формат 1С, сохраняя префиксы. Если в вашей базе уже есть платежка с таким номером (например, созданная по другому расчетному счету или введенная вручную ранее), возникает конфликт.

Рассмотрим основные причины сбоя:

Пересечение номеров по разным счетам: В банке нумерация идет в разрезе расчетного счета, а в 1С — в разрезе организации и года. Если по счету №1 прошла платежка №50 и по счету №2 тоже прошла платежка №50, при загрузке возникнет ошибка.
Программная подмена номера: Типовая обработка принудительно перезаписывает номер, который предложила система, номером из файла.
«Сломанная» последовательность: Если кто-то из сотрудников ввел номер вручную, удалив лидирующие нули (например, вместо УТ000000123 написал просто 123), автонумератор 1С перестает корректно определять следующий номер.

Решение №1: Отключение принудительной подмены номера в обработке

Это самый быстрый и эффективный способ. Мы доверим системе 1С самой назначать номера документам, игнорируя те номера, которые прислал банк в файле выгрузки. Это гарантирует уникальность в базе данных. Для этого нам потребуется внести небольшие изменения в модуль обработки (или во внешнюю обработку загрузки выписки).

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


Процедура ЗаполнитьРеквизитПлатежногоПорученияИсходящего(ОбъектДокумента, ИсходныеДанные)
    // Устанавливаем организацию и дату
    УстановитьСвойство(ОбъектДокумента, "Организация", Организация);
    УстановитьСвойство(ОбъектДокумента, "Дата", ИсходныеДанные.ДатаДок);

    Если ЗначениеЗаполнено(ИсходныеДанные.Списано) Тогда
        УстановитьСвойство(ОбъектДокумента, "Оплачено", Истина);
        УстановитьСвойство(ОбъектДокумента, "ДатаОплаты", НачалоДня(ИсходныеДанные.Списано), Истина);
    КонецЕсли;

    // Вот здесь кроется проблема. Система устанавливает новый номер с префиксом:
    Если ОбъектДокумента.ЭтоНовый() Тогда
        ОбъектДокумента.УстановитьНовыйНомер(Организация.Префикс);
        
        // СЛЕДУЮЩИЙ БЛОК НУЖНО ЗАКОММЕНТИРОВАТЬ:
        // Если мы оставим этот код, 1С попытается заменить свой правильный номер 
        // на номер из клиент-банка, что приведет к дублям.
        
        // Если Не ОбщегоНазначения.ЕстьНеЦифры(ИсходныеДанные.Номер) Тогда
        //     ОкончаниеНомера = Формат(Число(СокрЛП(ИсходныеДанные.Номер)), "ЧН=; ЧГ=0");
        //     ДлинаОкончания = СтрДлина(ОкончаниеНомера);
        //     ДлинаНомера = СтрДлина(СокрЛП(ОбъектДокумента.Номер));
        //     Если ДлинаОкончания < 3 Тогда
        //         ДлинаОкончания = 3;
        //     КонецЕсли;
        //     ОбъектДокумента.Номер = Лев(ОбъектДокумента.Номер, ДлинаНомера - ДлинаОкончания) + Формат(Число(ОкончаниеНомера), "ЧЦ=" + ДлинаОкончания + "; ЧВН=; ЧГ=0");
        // КонецЕсли;
    КонецЕсли;
КонецПроцедуры

После этой правки 1С будет присваивать документам свои внутренние номера (например, УТ000000001, УТ000000002), и конфликтов с «банковскими» номерами больше не возникнет.

Решение №2: Проверка существования номера перед записью

Если для бухгалтерии принципиально важно, чтобы номер в 1С совпадал с номером в банковской выписке, мы можем пойти по более сложному пути. Мы добавим проверку: если номер из банка уже занят в нашей базе, то мы оставим тот номер, который сгенерировала 1С. Если же номер свободен — используем банковский.

Проанализируем пример кода с использованием запроса для проверки уникальности:


// Вычисляем предполагаемый новый номер на основе данных банка
НовыйНомерИзБанка = Лев(ОбъектДокумента.Номер, ДлинаНомера - ДлинаОкончания) + Формат(Число(ОкончаниеНомера), "ЧЦ=" + ДлинаОкончания + "; ЧВН=; ЧГ=0");

// Проверяем, нет ли уже документа с таким номером в текущем году
Запрос = Новый Запрос;
Запрос.Текст = 
    "ВЫБРАТЬ
    |   ПлатежноеПоручениеИсходящее.Ссылка
    |ИЗ
    |   Документ.ПлатежноеПоручениеИсходящее КАК ПлатежноеПоручениеИсходящее
    |ГДЕ
    |   ПлатежноеПоручениеИсходящее.Номер = &Номер
    |   И ПлатежноеПоручениеИсходящее.Дата >= &ДатаНачалаГода";

Запрос.УстановитьПараметр("ДатаНачалаГода", НачалоГода(ОбъектДокумента.Дата));
Запрос.УстановитьПараметр("Номер", НовыйНомерИзБанка);

РезультатЗапроса = Запрос.Выполнить();

Если РезультатЗапроса.Пустой() Тогда
    // Если номер свободен, присваиваем его документу
    ОбъектДокумента.Номер = НовыйНомерИзБанка;
Иначе
    // Если номер занят, оставляем тот, что выдал метод УстановитьНовыйНомер() ранее
    Сообщить("Внимание: Номер " + НовыйНомерИзБанка + " уже существует. Присвоен системный номер.");
КонецЕсли;

Как навести порядок в текущей нумерации?

Если правка кода не помогла мгновенно, значит, в вашей базе уже накоплены документы с «кривыми» номерами, которые сбивают автонумератор. Разберем по шагам, как восстановить порядок:

Поиск документов-нарушителей: Откройте журнал платежных поручений и отсортируйте их по номеру. Ищите номера, в которых нет префикса (например, просто 0015 вместо УТ0000015) или есть лишние символы (дроби, пробелы).
Исправление лидирующих нулей: Убедитесь, что все номера имеют одинаковую длину. Если стандартная длина номера в вашей конфигурации — 11 символов, то номер УТ-5 должен выглядеть как УТ000000005.
Использование стандартных обработок: В конфигурации «Управление торговлей» в меню «Сервис» часто доступны обработки по перенумерации объектов. Выполните перенумерацию платежных поручений с начала текущего года. Это «сбросит» кэш номеров и заставит систему считать заново.
Проверка префиксов организации: Зайдите в справочник «Организации» и проверьте поле Префикс. Убедитесь, что там нет случайных пробелов в начале или конце. Пробел для 1С — это значимый символ, который создает отдельную очередь нумерации.

Совет по методологии учета

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

Для отражения банковских операций, не являющихся прямыми оплатами поставщикам (например, комиссии банка, переводы между счетами), лучше использовать документ Платежный ордер: списание денежных средств. У ордеров своя нумерация, они не пересекаются с Платежными поручениями и гораздо «терпимее» к ручному вводу. Это позволит оставить нумерацию платежек «чистой» — только для тех документов, которые реально уходят в банк.

Подведем итог: проблема с нумерацией в УТ 10.3 при загрузке из клиент-банка — это следствие попытки программы совместить два несовместимых ряда чисел. Либо исправьте код обработки, запретив ей менять номер (предпочтительный вариант для программиста), либо тщательно следите за чистотой номеров, исправляя каждый «кривой» ввод вручную.