Почему при переносе из 1С 7.7 в 1С:Бухгалтерию 8.3 договоры получают вид Прочее и как это исправить?

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

Разберем детально, почему так происходит, как обойти системные блокировки и исправить виды договоров без распроведения документов прошлых периодов, а также как предотвратить проблему еще на этапе конвертации данных.

Выясним причину: почему типовой перенос ставит вид договора «Прочее»

Проанализируем архитектурные различия платформ и логику типовых правил обмена:

1. Отсутствие классификации в 1С 7.7: В платформе 7.7 реквизита «Вид договора» не существовало вовсе. Один и тот же элемент справочника «Договоры» мог свободно использоваться бухгалтером и для оформления покупок, и для отгрузок, и для расчетов по аренде или займам.
2. Порядок выгрузки объектов: В типовых правилах конвертации определение вида договора происходит программно при анализе остатков по счетам взаиморасчетов. Однако если в правилах выгрузки справочник «Договоры» стоит раньше, чем выгрузка остатков, система сначала переносит элементы справочника (запоминая их ссылки в таблице соответствий), присваивая им нейтральный вид по умолчанию — «Прочее». Когда очередь доходит до остатков по счетам 60 или 62, договоры уже выгружены и повторно алгоритмом не анализируются.
3. Особенности закрытых взаиморасчетов и счетов учета: Если на дату переноса сальдо расчетов по контрагенту равно нулю, алгоритм не находит подтверждений принадлежности договора к поставщикам или покупателям. Кроме того, расчеты по аренде и услугам в 7.7 нередко велись на счете 76.5, аналитика которого правилами обмена по умолчанию сопоставляется с видом «Прочее».

Способ 1. Программное изменение вида договора через режим загрузки данных

Рассмотрим ситуацию, когда данные уже перенесены в 1С:Бухгалтерию 3.0, по договорам созданы проведенные документы, а при попытке изменить вид договора в форме элемента поле заблокировано для редактирования. В 1С:Бухгалтерии срабатывает встроенная проверка: если в информационной базе на договор ссылается хотя бы один документ, смена вида запрещается во избежание нарушения бухгалтерских итогов.

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

Посмотрим на пример программного кода, который обходит системные проверки формы и модуля объекта, изменяя вид договора на «С покупателем»:

СпрОбъект = Ссылка.ДоговорКонтрагента.ПолучитьОбъект();
СпрОбъект.ВидДоговора = Перечисления.ВидыДоговоровКонтрагентов.СПокупателем;
СпрОбъект.ОбменДанными.Загрузка = Истина;
СпрОбъект.Записать();

Разберем по шагам, как применить этот алгоритм на практике:

1. Открываем обработку «Универсальные подбор и обработка объектов» для управляемого приложения.
2. В качестве объекта поиска выбираем документы Реализация (акты, накладные, УПД).
3. Настраиваем отбор: указываем организацию, необходимый период и условие Договор.Вид договора Равно "Прочее".
4. Нажимаем кнопку «Найти объекты».
5. Переходим на вкладку «Обработки», выбираем вариант «Произвольный алгоритм» и вставляем приведенный выше код.
6. Выполняем алгоритм. Флаг ОбменДанными.Загрузка = Истина отключает типовые проверки перед записью, позволяя обновить реквизит прямо в проведенных документах без снятия их с проведения.

Аналогичным образом корректируются договоры для поступлений товаров и услуг: в коде достаточно указать значение перечисления Перечисления.ВидыДоговоровКонтрагентов.СПоставщиком.

Важные нюансы перепроведения и счетов учета

Обратим внимание на критическую деталь: изменение реквизита через ОбменДанными.Загрузка меняет только значение в справочнике, но не перезаполняет счета учета в табличных частях уже проведенных документов. Если в 7.7 операции отражались по счету 76, а вид договора стал «С покупателем», при последующем штатном перепроведении документа может возникнуть конфликт с регистрами взаиморасчетов (счета 62.01 и 62.02 вместо 76).

Если контрагент одновременно выступал и поставщиком, и покупателем по единому договору в 7.7, простое переименование вида договора приведет к учетным ошибкам. В таких случаях правильнее создать два отдельных договора в 8.3 («С поставщиком» и «С покупателем») и распределить задолженность с помощью документа Корректировка долга (вид операции «Перенос задолженности»).

Способ 2. Исправление порядка выгрузки в правилах конвертации (до переноса)

Если повторный перенос данных возможен, разберем, как устранить корень проблемы в конфигурации «1С:Конвертация данных 2.1»:

1. Отключение предварительной выгрузки справочника: В правилах выгрузки данных (ПВД) отключаем отдельную выгрузку справочника «Договоры». В этом случае договоры будут выгружаться только по ссылке при формировании остатков или документов. К моменту выгрузки договора контекст счета (60, 62 или 76) уже будет известен системе, что позволит алгоритму правильно назначить реквизит.
2. Принудительное переопределение в правилах конвертации объектов (ПКО): Если переносится база специализированной организации (например, сдающей имущество исключительно в аренду), в ПКО для справочника «ДоговорыКонтрагентов» в обработчике события ПриВыгрузке можно жестко зафиксировать вид договора:

// Принудительная установка вида договора для монопрофильной базы
Значение = "СПокупателем";

Такой подход исключает появление договоров с видом «Прочее» еще на стадии формирования файла выгрузки и избавляет от необходимости последующей ручной или программной обработки базы-приемника.