← На главную

При переходе с конфигураций 1С предыдущих поколений, таких как Управление торговлей 10.3 (УТ 10), Комплексная автоматизация 1.1 (КА 1.1) или Управление производственным предприятием (УПП), на более современные версии, например, Управление торговлей 11 (УТ 11), Комплексная автоматизация 2 (КА 2) или ERP Управление предприятием, мы часто сталкиваемся с проблемой потери детализации взаиморасчетов. Особенно остро это проявляется, когда в старой системе велся учет по расчетным документам (реализациям) или заказам, а после типового переноса все остатки агрегируются на уровне договоров.

Рассмотрим подробнее эту ситуацию: в УТ 10 или аналогичных конфигурациях мы привыкли, что заказы покупателя являются основанием для реализации товаров, и в договоре указан тип расчетов "По договору" с флагом "По расчетным документам". При поступлении оплаты клиент мог прикрепить расчетный документ — конкретную реализацию, и в отчетах мы видели расчеты именно по реализациям. Однако после перехода на УТ 11 типовой перенос часто сворачивает эти остатки взаиморасчетов на договоры. В результате, мы теряем:

1. Незакрытые заказы покупателя: Если в правилах выгрузки не предусмотрен специальный запрос, выбирающий остатки именно по заказам, информация о них может быть утеряна.
2. Детализация расчетов: В новой системе взаиморасчеты ведутся "по договору в целом", что лишает возможности распределять поступающие платежи по конкретным реализациям или заказам.

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

Причины потери детализации взаиморасчетов

Прежде чем перейти к решениям, выясним причину потери детализации. Основная причина кроется в фундаментальных различиях механизмов учета взаиморасчетов между старыми и новыми конфигурациями 1С.

1. Принципы учета в УТ 10 (и аналогичных): В этих системах детализация часто была привязана напрямую к расчетным документам (реализациям, приходным кассовым ордерам). Регистры накопления взаиморасчетов могли содержать измерения, прямо указывающие на документ-основание, по которому возникла задолженность.
2. Принципы учета в УТ 11 (КА 2, ERP): В новых конфигурациях 1С взаиморасчеты строятся на основе понятий "объектов расчетов" (такими объектами могут быть договоры, заказы клиентов, реализации, накладные) и, что критично, "ключей аналитики учета по партнерам" (справочник КлючиАналитикиУчетаПоПартнерам). Документы движений (реализации, оплаты) формируют записи в регистрах взаиморасчетов, привязываясь к этим ключам. Если типовые правила переноса не создают корректные ключи аналитики для каждого незакрытого расчетного документа или заказа, детализация теряется, и остатки агрегируются до уровня договоров.

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

Решения и подходы к сохранению детализации

Рассмотрим различные подходы, которые помогут нам сохранить или восстановить необходимую детализацию взаиморасчетов при переходе на новые конфигурации.

1. Понимание механизмов УТ 11: Ключи аналитики учета по партнерам и объекты расчетов

Для эффективного решения проблемы крайне важно глубоко понять, как устроены взаиморасчеты в УТ 11 и аналогичных системах. Сообщение 9 и 10 форума акцентируют внимание на справочнике КлючиАналитикиУчетаПоПартнерам. Именно этот справочник является ключевым для детализации взаиморасчетов в новой системе.

Мы видим, что в УТ 11 этот механизм реализован через КлючиАналитикиУчетаПоПартнерам. На эти ключи "вешаются" Регистраторы расчетов. Остатки в регистрах автоматически корректируются этими регистраторами, поскольку это регистры накопления, и без регистраторов корректная работа невозможна.

Когда мы выполняем действия согласно типовым процедурам, система считывает текущие остатки по взаиморасчетам по ключу аналитики. Из ключа берутся все необходимые параметры, а из остатков — данные. Последующие движения "закрывают" задолженность именно по этим данным. Это означает, что каждая новая запись всегда формируется по "объекту расчетов", но с привязкой к соответствующему ключу аналитики.

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

Для сохранения детализации мы должны обеспечить, чтобы при переносе каждый незакрытый расчетный документ или заказ в УТ 11 получил свой уникальный КлючАналитикиУчетаПоПартнерам, который будет ссылаться на соответствующий "объект расчетов" (реализацию или заказ).

2. Групповой взаимозачет для агрегированного долга

Если остатки уже были перенесены и свернуты на уровне договоров, одним из вариантов, предложенных в сообщении 3, является использование механизма взаимозачета, но не точечно, а оптом:

Мы можем предположить, что общие долги свернуты по договорам заказов (или договорам, к которым привязаны реализации). Идея заключается в том, чтобы списать с договоров в целом с помощью взаимозачета оптом, вместо того чтобы делать это в розницу по каждой отдельной реализации. Однако, как справедливо отметил автор в сообщении 4, "загруженный заказ, даже проведенный - не делает задолженность". Долг формируется по реализациям. Следовательно, для работы этого подхода нам потребуется:

1. Определить детализацию в исторической системе: Нам необходимо точно знать, какой остаток по договору в УТ 10 соответствует каким незакрытым реализациям. Эта информация должна быть получена из исходной базы.
2. Перенести незакрытые реализации: Возможно, потребуется перенести сами незакрытые документы реализации из УТ 10 в УТ 11. Эти документы могут быть перенесены как "исторические" или "фиктивные" для целей взаиморасчетов, если они не должны влиять на оперативный учет.
3. Выполнить групповой взаимозачет: В УТ 11 мы сможем создать документ "Корректировка долга" или аналогичный документ взаимозачета. С его помощью мы "перенесем" агрегированную задолженность с договора на конкретные перенесенные реализации. Этот процесс, хоть и "оптовый", все равно требует предварительной подготовки данных и ручной работы по сопоставлению.

Этот метод может быть менее трудоемким, чем точечный взаимозачет, но все равно требует четкого алгоритма и данных о детализации из исходной системы.

3. Доработка правил обмена

Наиболее эффективным, но и наиболее трудоемким решением является доработка типовых правил обмена. Мы должны модифицировать запросы и алгоритмы выгрузки/загрузки таким образом, чтобы они формировали в УТ 11 (или аналогичной системе) корректные КлючиАналитикиУчетаПоПартнерам для каждого незакрытого заказа покупателя или документа расчетов (реализации). Это позволит сохранить детализацию и даст возможность в дальнейшем распределять платежи по конкретным объектам.

При доработке правил необходимо:

1. Извлечь детальные данные: В УТ 10 мы должны получить не просто остатки по договорам, а остатки по каждому расчетному документу (реализации) или заказу, который сформировал этот долг.
2. Создать или сопоставить объекты расчетов: При загрузке в УТ 11 для каждого такого остатка мы должны создать или найти соответствующий "объект расчетов" (например, перенесенную реализацию или заказ).
3. Сформировать КлючиАналитикиУчетаПоПартнерам: На основе партнера, договора и объекта расчетов мы должны корректно сформировать записи в справочнике КлючиАналитикиУчетаПоПартнерам.
4. Загрузить остатки с новой детализацией: Остатки взаиморасчетов должны быть загружены в регистры УТ 11 с привязкой к этим новым, детализированным ключам аналитики.

Этот подход требует глубоких знаний как структуры баз УТ 10, так и внутренней архитектуры УТ 11, а также навыков работы с конвертацией данных и языком запросов 1С. Это проектная задача, которая часто требует привлечения опытных программистов 1С.

4. Использование документов "Ввод остатков по взаиморасчетам" с расширенной аналитикой

Если мы не готовы к полной доработке правил обмена, но хотим получить детализацию, мы можем использовать документ "Ввод остатков по взаиморасчетам" в УТ 11 с максимально возможной детализацией. В этом документе, помимо партнера и договора, мы можем указать "объект расчетов" (например, конкретный заказ или реализацию).

Шаги для реализации:

1. Сформировать список детализированных остатков: В исходной системе (УТ 10) мы должны получить полный список всех незакрытых реализаций или заказов с их остатками по каждому контрагенту и договору.
2. Подготовить данные для ввода: Этот список будет основой для заполнения документа "Ввод остатков по взаиморасчетам" в УТ 11.
3. Заполнить документ "Ввод остатков": В документе мы построчно указываем контрагента, договор, а главное — объект расчетов (выбирая или создавая соответствующие документы-основания в УТ 11) и сумму остатка.

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

5. Перенос документов-оснований

Вместо переноса только свернутых остатков, можно перенести сами незакрытые заказы покупателей и реализации из УТ 10 в УТ 11. Эти документы могут быть перенесены как "фиктивные" или "исторические" документы, если они не должны повторно влиять на оперативный учет или движение товаров. После переноса этих документов мы сможем использовать механизм корректировки или взаимозачета в УТ 11 для "привязки" перенесенных остатков к этим документам.

Этапность действий:

1. Определить объем незакрытых документов: Идентифицировать все незакрытые заказы и реализации в УТ 10, по которым существуют остатки взаиморасчетов.
2. Перенести документы: Создать правила обмена для переноса этих документов в УТ 11. Возможно, потребуется пометить их особым образом (например, комментарием "Перенесен из УТ 10") или использовать отдельный статус.
3. Перенести остатки: Использовать документ "Ввод остатков по взаиморасчетам", указывая перенесенные заказы или реализации в качестве "объекта расчетов", или же использовать механизм корректировки долга.

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

Рекомендации по учету в УТ 11 после перехода

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

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

Эти настройки гарантируют, что все новые документы (реализации, оплаты) будут формировать движения в регистрах взаиморасчетов с требуемой детализацией по КлючамАналитикиУчетаПоПартнерам, что позволит бухгалтерам корректно распределять платежи и анализировать задолженность.

Особенности перепроведения документов в исходной системе

Один из вопросов, который часто возникает, — это возможность изменения настроек детализации в договорах в исходной системе (УТ 10) перед переносом. В сообщении 6 автор справедливо отмечает, что изменение в договоре типа расчетов с "По договору" на "По расчетным документам" или "По заказам" в УТ 10 без последующего перепроведения всех связанных документов не приведет к изменению детализации в регистрах.

Перепроведение всех документов, сформировавших взаиморасчеты, в рабочей базе УТ 10 (особенно если их тысячи) может быть крайне длительным, ресурсоемким и рискованным процессом, который может привести к нарушению последовательности документов и ошибкам в учете. Поэтому такой подход, как правило, не рассматривается как практичное решение для подготовки данных к переносу.

Проверка и верификация перенесенных данных

После любой миграции критически важна тщательная проверка и верификация перенесенных остатков. Мы должны:

1. Сверить общие суммы: Убедитесь, что общие суммы дебиторской и кредиторской задолженности по каждому контрагенту и договору совпадают между исходной и целевой системами.
2. Проверить детализацию: Если детализация была сохранена, выборочно проверьте, что остатки по конкретным заказам или реализациям корректно отражают исходное состояние.
3. Тестирование: Проведите тестирование ввода новых платежей и их распределения по детализированным объектам расчетов в УТ 11, чтобы убедиться в корректности настроек и функциональности.

Заключение

Перенос остатков взаиморасчетов с сохранением детализации при миграции с УТ 10 на УТ 11 — это сложная задача, требующая глубокого понимания архитектуры обеих систем. Мы видим, что типовые правила переноса часто не обеспечивают нужный уровень детализации, агрегируя данные по договорам. Для решения этой проблемы нам необходимо либо дорабатывать правила обмена, чтобы они корректно формировали КлючиАналитикиУчетаПоПартнерам и объекты расчетов в УТ 11, либо использовать комбинацию переноса документов-оснований и групповых корректировок долга. В любом случае, это требует тщательного планирования, анализа данных и, возможно, значительных усилий по программированию и ручной верификации. Главное — помнить, что проблема решаема, если мы четко понимаем механизмы новой системы и готовы инвестировать время и ресурсы в адаптацию процесса переноса.