В процессе эксплуатации систем на базе 1С:Предприятие 8, особенно при использовании классических конфигураций, таких как «Бухгалтерия предприятия 2.0» (БП 2.0) и «Управление торговлей 10.3» (УТ), технические специалисты часто сталкиваются с парадоксальной ситуацией. В базу-приемник загружаются документы с идентичными номерами, при этом оба документа успешно проводятся. Однако при попытке ручного перепроведения или редактирования система выдает ошибку нарушения уникальности номера.
Давайте подробно разберем, почему штатные механизмы контроля уникальности «засыпают» в момент обмена, и как предотвратить подобные инциденты в будущем.
Первоочередная причина, по которой платформа 1С позволяет записать документ с дублирующимся номером, кроется в использовании программного свойства ОбменДанными.Загрузка. Рассмотрим, как это работает на уровне кода и логики платформы.
Когда данные поступают через типовой механизм обмена, в модуле объекта при вызове обработчиков событий (таких как ПередЗаписью или ПриЗаписи) устанавливается специальный флаг. Проанализируем типовой фрагмент кода, который встречается почти в каждом документе:
Процедура ПередЗаписью(Отказ, РежимЗаписи, РежимПроведения)
Если ОбменДанными.Загрузка Тогда
Возврат;
КонецЕсли;
// Далее идет стандартная логика проверок, которая игнорируется при обмене
КонецЕсли;
В режиме ОбменДанными.Загрузка = Истина платформа намеренно отключает большинство прикладных проверок, включая контроль уникальности кодов и номеров. Это необходимо для того, чтобы процесс синхронизации больших массивов данных не прерывался из-за мелких логических нестыковок. Предполагается, что данные в источнике уже корректны. В результате, если в сообщении обмена пришли два объекта с одинаковыми номерами, они будут записаны «как есть».
Важно понимать, что для платформы 1С документом-дублем является не тот объект, у которого совпадает номер, а тот, у которого совпадает Уникальный Идентификатор (GUID). Рассмотрим ситуацию, которая часто приводит к появлению визуальных дублей:
Проанализируем ситуацию: для системы это два абсолютно разных объекта, которые просто имеют одинаковую строковую метку в поле Номер.
В конфигурации БП 2.0 критически важна правильная настройка префиксов. Если префиксы информационной базы в настройках параметров учета и в узлах обмена (планах обмена) настроены некорректно, механизмы автонумерации могут давать сбои. Рассмотрим основные моменты:
Номер. В УТ длина номера может составлять 11 символов, а в БП 2.0 — например, 9. При передаче номера происходит «тихая» обрезка строки. В итоге два разных номера из УТ (например, «УТ000000101» и «УТ000000102») при обрезке в БП могут превратиться в одинаковые значения, если значимые части номера выходят за пределы длины поля приемника.Разберем конкретный пример с документом Поступление на расчетный счет. В БП 2.0 этот документ является сложным объектом. В нем есть два важных поля:
Номер — внутренний номер документа в системе 1С.НомерВходящегоДокумента — номер платежного поручения из банковской выписки.При настройке обмена через правила конверсии данных (XML) иногда возникает путаница. Если в правилах прописано, что поиск объекта в БП должен идти по номеру, а в УТ этот номер хранится в другом формате или поле, поиск может не сработать. Система не найдет существующий документ и создаст новый (дубль), присвоив ему тот же номер, что пришел из источника.
Для исправления ситуации и предотвращения её повторения рекомендуем выполнить следующие шаги:
Если дубликаты уже созданы и проведены, их нельзя просто перепровести. Необходимо воспользоваться специализированной обработкой «Поиск и замена дублей». Проанализируем алгоритм действий:
Поступление на расчетный счет).Номер.Если требуется жестко запретить появление дублей даже во время обмена, можно внести изменения в подписку на событие ПередЗаписью. Однако действуйте осторожно: это может привести к полной остановке обмена при обнаружении первого же дубля. Пример проверки:
Если ОбменДанными.Загрузка Тогда
// Проверяем наличие документа с таким же номером, но другим GUID
Запрос = Новый Запрос;
Запрос.Текст = "ВЫБРАТЬ Ссылка ИЗ Документ.ПоступлениеНаРасчетныйСчет
ГДЕ Номер = &Номер И Ссылка <> &Ссылка";
Запрос.УстановитьПараметр("Номер", ЭтотОбъект.Номер);
Запрос.УстановитьПараметр("Ссылка", ЭтотОбъект.Ссылка);
Результат = Запрос.Выполнить();
Если НЕ Результат.Пустой() Тогда
// Здесь можно либо записать ошибку в лог, либо Отказ = Истина;
КонецЕсли;
КонецЕсли;
Выясним причину сбоя в нумерации, проверив настройки в обеих базах. Убедитесь, что префикс, установленный в Константы.ПрефиксИнформационнойБазы, соответствует префиксу в Узлах обмена. Это гарантирует, что номера, генерируемые в БП, не будут пересекаться с номерами, приходящими из УТ.
Подводя итог, можно сказать, что появление дублей номеров при обмене — это не «глюк» системы, а следствие работы механизма быстрой загрузки данных, который приоритизирует GUID объекта над его визуальным номером. Регулярный мониторинг состояния нумерации и использование корректных префиксов — залог чистоты вашей базы данных.