Как правильно отразить смену наименования контрагента в 1С?

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

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

Правовой анализ: изменилось лицо или только название?

Проанализируем правовые основы ситуации. С юридической точки зрения изменение названия компании без изменения основных регистрационных реквизитов (ОГРН и ИНН) не означает создание нового субъекта права. Юридическое лицо продолжает существовать, сохраняя все ранее возникшие права, обязанности и задолженности. Замена наименования вступает в законную силу не в момент издания внутреннего протокола компании или отправки уведомительного письма, а строго с даты внесения соответствующей записи в ЕГРЮЛ. Сверим выписку из ЕГРЮЛ на сайте ФНС, чтобы убедиться, что ИНН остался неизменным.

Вариант 1. Использование встроенного механизма истории реквизитов (рекомендуемый для современных конфигураций)

В современных типовых решениях, таких как 1C:Бухгалтерия (редакция 3.0), реализован механизм хранения периодических реквизитов. Разберем по шагам, как зафиксировать новое наименование:

  1. Откроем карточку требуемого контрагента в справочнике Контрагенты.
  2. Найдем гиперссылку История рядом с полем наименования.
  3. Добавим новую запись, указав точную дату внесения изменений в ЕГРЮЛ согласно официальному свидетельству или листу записи ЕГРЮЛ.
  4. Введем новое рабочее и полное сокращенное/полное наименование организации и сохраним изменения.

Рассмотрим, как данная архитектура ведет себя на практике. Механизм истории периодических реквизитов ориентирован на печатные формы и регламентированные отчеты: при формировании документов (например, дубликата накладной или акта за прошлые периоды) система обращается к срезу последних данных на дату документа и выводит в печатную форму прежнее наименование. Документы, сформированные после даты изменения, автоматически содержат новое название.

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

Вариант 2. Создание нового элемента справочника и перенос задолженности (устаревший подход)

В ранних конфигурациях (например, «Бухгалтерия предприятия» ред. 1.6 или 2.0 на обычных формах), где версионирование наименований контрагентов отсутствовало, пользователи часто прибегали к созданию дублирующей карточки с новым названием. Проанализируем, как осуществляется этот процесс и с какими трудностями придется столкнуться.

Если в силу регламентов принято решение завести вторую карточку, алгоритм действий выглядит следующим образом:

  1. Заводим новый элемент в справочнике Контрагенты с новым наименованием и прежним ИНН.
  2. Оформляем документ КорректировкаДолга на дату официального уведомления/внесения записи в ЕГРЮЛ.
  3. Выбираем вид операции Перенос задолженности (переносим дебиторскую или кредиторскую задолженность с контрагента со старым названием на контрагента с новым названием).
  4. Заполняем счета расчетов (счета учета взаиморасчетов 60, 62 или 76) и нажимаем кнопку Заполнить для автоматического подбора остатков. В комментарии документа фиксируем основание: реквизиты уведомления и выписки ЕГРЮЛ.

Разберем скрытые риски и проблемы создания второй карточки контрагента:

  1. Разрыв регистров по НДС с авансов: при переносе авансов (счета 60.02, 62.02, 76.АВ, 76.ВА) с помощью документа корректировки долга часто теряется связь с исходным расчетным документом. Это приводит к ошибкам при автоматическом формировании книги покупок и книги продаж при последующем закрытии периода, требуя ручных корректировок специализированных регистров подсистемы НДС.
  2. Сбои при импорте банковских выписок: обработка загрузки данных из системы «Клиент-банк» идентифицирует контрагента по ИНН и КПП. Наличие двух карточек с идентичным ИНН приведет либо к постоянным предупреждениям о дублях, либо к непредсказуемой автоматической привязке входящих и исходящих платежей не к тому элементу справочника, вызывая пересортицу на счетах учета.
  3. Проблемы со сверкой взаиморасчетов: если контрагент или налоговый орган запросит единый акт сверки за весь финансовый год, программа не сможет сформировать сквозной документ по одной карточке. Бухгалтеру придется формировать два отдельных акта или сводить данные вручную.

Вариант 3. Особенности учета в конфигурациях с разделением партнеров и контрагентов

В прикладных решениях с расширенным контуром управленческого учета (например, 1С:Комплексная автоматизация или 1С:ERP Управление предприятием) архитектура разделяет сущности управленческого и юридического учета: используются справочник Партнеры и подчиненный ему справочник Контрагенты.

Разберем оптимальную схему для таких баз данных: если внутренние регламенты требуют разделения юридических лиц, мы можем создать новую карточку в справочнике Контрагенты, но связать ее с тем же самым элементом справочника Партнеры. Это позволит сохранить непрерывную управленческую аналитику, историю продаж, заказов и работу в контуре CRM, разделив при этом исключительно юридические документы.

Рекомендации по электронному документообороту (1С-ЭДО)

Обратим внимание на работу через электронный документооборот. При смене названия юридического лица партнер получает новый сертификат квалифицированной электронной подписи (КЭП). Сам идентификатор участника ЭДО (ID ЭДО) при этом сохраняется, если контрагент не менял оператора. Чтобы обмен документами не прерывался, после подтверждения переименования в системе оператора обновим настройки отправки и получения электронных документов в базе 1С для актуализации профиля контрагента.

← На главную