В процессе эксплуатации систем на базе 1С, особенно при настройке обмена между «1С:Управление торговлей» (УТ) и «1С:Бухгалтерия предприятия» (БП), специалисты часто сталкиваются с ошибками уникальности номеров. Возникает соблазн просто отключить этот контроль в конфигураторе, чтобы «данные просто залетели». Однако такое решение является деструктивным. В этой статье мы подробно разберем, почему уникальность номеров критически важна, к каким техническим и юридическим последствиям приведет ее отключение, и как правильно решить проблему дублирования номеров при обмене данными.
Рассмотрим, что происходит «под капотом» платформы 1С. Контроль уникальности — это не просто логическая проверка при записи, это механизм, глубоко интегрированный в работу базы данных. Если мы снимем галочку «Контроль уникальности» в метаданных документа, мы столкнемся со следующими проблемами:
ТипДокумента + Дата + Номер является уникальным идентификатором документа для пользователя. Дублирование этих данных превращает анализ базы в хаос.Проанализируем ситуацию, описанную в теме: при выгрузке из УТ в БП номера платежных поручений повторяются, и обмен прерывается. Посмотрим, почему попытка «протолкнуть» дубли через отключение контроля — это путь к потере данных:
Коллизии и перезатирание. Большинство механизмов обмена (как старая «Конвертация данных 2.0», так и современная EnterpriseData) используют поиск объекта. Если поиск настроен по номеру и дате, то при загрузке документа с уже существующим номером система не создаст новый документ, а перезапишет старый данными нового. В итоге в бухгалтерии просто пропадет часть первичных документов, что приведет к расхождениям в остатках по счетам.
Для корректной работы обмена мы должны использовать префиксы информационных баз. Разберем принцип их работы: в каждой базе (УТ и БП) в настройках синхронизации должен быть задан уникальный префикс (например, «УТ» для торговли и «БП» для бухгалтерии). Тогда номера документов будут выглядеть так: УТ-00001 и БП-00001. Это исключает любые пересечения номеров, даже если порядковая часть совпадает.
С точки зрения методологии бухгалтерского учета, уникальность номеров — это обязательное требование законодательства. Выясним основные причины, по которым бухгалтер будет категорически против дублей:
Часто программисты допускают ошибку, пытаясь записать номер из банковской выписки (который часто бывает коротким, например «15») непосредственно в поле Номер документа в 1С. Посмотрим, как это реализовано в типовых конфигурациях правильно:
В документах «Поступление на расчетный счет» или «Списание с расчетного счета» всегда есть два поля:
Номер — это внутренний уникальный номер 1С с префиксами, который ведет сама программа.НомерВходящегоДокумента — это строковое поле, куда записывается тот самый номер, который прислал банк.Рекомендация: Никогда не подменяйте внутренний номер 1С банковским номером. Оставляйте автонумерацию включенной, а номер из выписки фиксируйте только в специализированном реквизите «Входящий номер».
Если вы уже столкнулись с тем, что номера «сбились» или дублируются, проанализируем шаги по восстановлению порядка:
Убедимся, что в базе УТ и в базе БП заданы разные префиксы в настройках синхронизации данных. Если документы уже созданы без префиксов, можно воспользоваться стандартной обработкой «Групповое изменение реквизитов».
Если в базе возникла «каша» из номеров, воспользуемся механизмом обновления нумерации. Рассмотрим программный способ сброса кэша нумерации, который помогает, если система выдает ошибку «Номер не является уникальным» при попытке создать новый документ:
// Пример кода для сброса кэша нумерации для конкретного типа документа
Процедура СброситьКэшНумерации()
ОбновитьПовторноИспользуемыеЗначения();
Менеджер = Документы.ПоступлениеНаРасчетныйСчет;
Менеджер.УстановитьНовыйНомер("БП"); // Указываем префикс базы
КонецПроцедуры
Проанализируем правила обмена. Если загрузка идет через самописную обработку, необходимо убедиться, что при записи документа вызывается метод УстановитьНовыйНомер(), а не ручное присвоение значения полю Номер.
Если используется типовая синхронизация, проверьте соответствие префиксов организаций. Часто дубли возникают, когда одна и та же организация заведена в разных базах с разными кодами или префиксами, что сбивает алгоритм поиска существующих объектов.
Отключать контроль уникальности в «1С:Бухгалтерии» категорически нельзя. Это приведет к технической деградации базы данных, потере информации при обменах и серьезным проблемам с контролирующими органами. Вместо этого следует: