При переходе с устаревших версий программ (например, 1С:УСН 7.7) на современную 1С:Бухгалтерию 3.0 пользователи часто сталкиваются с неприятной ситуацией: в карточке контрагента отображается предупреждение «Неверная длина ИНН». При этом визуальная проверка подтверждает, что ИНН содержит положенные 10 цифр для юридического лица или 12 для физического. Самое странное в этой ситуации то, что если вручную удалить ИНН, записать карточку, а потом вставить тот же самый номер обратно, ошибка исчезает и появляется радостное сообщение: «Контрагент есть в базе ФНС».
В этой статье мы подробно разберем, почему возникает этот программный «глюк», как устроена система проверки контрагентов в 1С 8.3 и как исправить проблему массово, не прибегая к ручному перевводу сотен записей.
Давайте проанализируем, почему типовые механизмы проверки 1С выдают ложное сообщение об ошибке. Рассмотрим основные факторы, которые влияют на валидацию реквизитов:
Бухгалтерия предприятия 3.0 информация о валидности контрагентов хранится не только в самой карточке (справочнике), но и в специальном регистре сведений СостоянияКонтрагентов. Если при переносе данных или при первой фоновой проверке система по какой-то причине зафиксировала ошибку, этот статус записывается в регистр. Форма элемента справочника при открытии в первую очередь обращается к этому регистру. Даже если вы исправите ИНН программно, «старое» ошибочное состояние может продолжать блокировать корректное отображение.СтрДлина может не всегда наглядно показать наличие таких символов, если проверка идет по визуальному представлению, но регулярные выражения валидатора 1С настроены жестко на цифровой ввод.Контрагенты существует служебный флаг ИННВведенКорректно. Если при программной загрузке этот флаг не был установлен в значение Истина, система может по умолчанию считать ввод незавершенным или ошибочным.Если контрагентов много, эффективнее всего написать небольшую обработку, которая принудительно очистит неверные состояния и заставит систему пересчитать статус проверки. Рассмотрим алгоритм, предложенный практикующими специалистами. Суть метода заключается в том, чтобы найти всех контрагентов со статусом НевернаяДлинаИНН, очистить их состояние и перезаписать объект, провоцируя новую проверку.
Проанализируем пример кода для такой обработки:
Процедура ИсправитьОшибкиИНННаСервере()
Запрос = Новый Запрос;
Запрос.Текст =
"ВЫБРАТЬ
| СостоянияКонтрагентов.Контрагент КАК Контрагент,
| СостоянияКонтрагентов.ИНН КАК ИНН
|ИЗ
| РегистрСведений.СостоянияКонтрагентов КАК СостоянияКонтрагентов
|ГДЕ
| СостоянияКонтрагентов.Состояние = ЗНАЧЕНИЕ(Перечисление.СостоянияСуществованияКонтрагента.НевернаяДлинаИНН)";
Выборка = Запрос.Выполнить().Выбрать();
Пока Выборка.Следующий() Цикл
// 1. Очищаем запись в регистре состояний для данного контрагента
НаборЗаписей = РегистрыСведений.СостоянияКонтрагентов.СоздатьНаборЗаписей();
НаборЗаписей.Отбор.Контрагент.Установить(Выборка.Контрагент);
НаборЗаписей.Записать(); // Записываем пустой набор, удаляя старое состояние
// 2. Перезаписываем объект справочника для инициации новой проверки
ОбъектКонтрагент = Выборка.Контрагент.ПолучитьОбъект();
Если ОбъектКонтрагент <> Неопределено Тогда
// Важно выполнить очистку и повторное присвоение, чтобы сработали обработчики событий
ТекущийИНН = ОбъектКонтрагент.ИНН;
ОбъектКонтрагент.ИНН = "";
ОбъектКонтрагент.Записать();
ОбъектКонтрагент.ИНН = СокрЛП(ТекущийИНН);
ОбъектКонтрагент.Записать();
КонецЕсли;
КонецЦикла;
КонецПроцедуры
Почему это работает? При записи объекта справочника Контрагенты в типовой конфигурации срабатывают подписки на события, которые ставят задачу на фоновую проверку ИНН/КПП. Удаление записи из регистра СостоянияКонтрагентов гарантирует, что форма не подтянет старую ошибку до того, как придет новый ответ от сервиса ФНС.
Если вы не хотите писать код, можно воспользоваться стандартным инструментом «Групповое изменение реквизитов» (раздел Администрирование — Обслуживание — Корректировка данных).
Разберем этот процесс по шагам:
Контрагенты.ИНН заполнен. Дополнительно можно добавить фильтр по реквизиту ЮридическоеФизическоеЛицо, если вы хотите обрабатывать их отдельно.ИННВведенКорректно и установите его в значение Да (Истина).Этот метод заставит систему пересчитать логику проверки для всех выбранных записей. В большинстве случаев после такой массовой «перезаписи» статус в форме элемента обновляется на корректный.
Рассмотрим еще несколько технических моментов, которые помогут избежать подобных проблем в будущем:
Реквизит «Расширенное представление ИНН»: В БП 3.0 данный реквизит используется преимущественно для иностранных организаций. Если при переносе данных из 7.7 это поле было заполнено произвольными данными, оно может конфликтовать с основным полем ИНН. Убедитесь, что для российских организаций это поле остается пустым.
Страна регистрации: Проверка длины ИНН (10 или 12 символов) жестко привязана к тому, какая страна указана в карточке контрагента. Если поле СтранаРегистрации не заполнено или заполнено неверно (не Россия), алгоритм проверки будет выдавать ошибку формата, так как будет ожидать структуру ИНН, принятую в другом государстве.
Очистка кэша: В редких случаях, даже после программного исправления регистра, пользователь может видеть старую ошибку из-за локального кэша сеанса. В такой ситуации помогает перезапуск 1С или очистка временных файлов пользователя.
Подводя итог, можно сказать, что проблема «Неверной длины ИНН» — это чаще всего проблема рассинхронизации данных между справочником контрагентов и регистром их состояний после массового импорта. Наилучшим решением является программный сброс записей в регистре СостоянияКонтрагентов с последующей перезаписью объектов справочника. Это «встряхивает» механизмы валидации 1С и приводит базу данных в актуальное состояние согласно требованиям ФНС.