Что делать в 1С:ERP, если Заказ поставщику создается без договора, а расчеты нужно вести правильно?

Встречается ситуация, когда на момент оформления документа Заказ поставщику в 1С:ERP договор с контрагентом еще не согласован или не подписан. Менеджеры или закупщики создают заказ, чтобы зафиксировать потребность, а договор появляется позже, уже в документе Приобретение товаров и услуг, который кладовщик создает на основании этого заказа.

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

Почему нельзя просто отключать движения по взаиморасчетам у Заказа поставщику?

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

Эта цепочка может выглядеть так:

1. Заказ поставщику (создается первый объект расчетов).
2. Заявка на расходование ДС (ссылается на объект расчетов из заказа).
3. Списание безналичных ДС (оплата аванса, которая также привязывается к этому объекту расчетов).
4. Приобретение товаров и услуг (поступление товара, которое должно зачесть аванс по тому же объекту расчетов).

Если вы "выпилите" движения из Заказа поставщику и заставите Приобретение товаров и услуг создавать свой собственный объект расчетов (например, на основании договора), вы разорвете эту логическую цепь. Это приведет к серьезным последствиям:

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

Вывод: изменять базовый механизм формирования объектов расчетов — крайне рискованный путь, который нарушит целостность данных в системе. Гораздо правильнее адаптировать бизнес-процессы или использовать менее инвазивные доработки.

Альтернативные и безопасные решения проблемы

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

Решение 1: Добавить контроль заполнения договора

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

Как реализовать:

1. Создайте расширение конфигурации.
2. Добавьте подписку на событие ОбработкаПроведения для документа Приобретение товаров и услуг.
3. В коде обработчика подписки добавьте проверку: если поступление вводится на основании Заказа поставщику, то необходимо проверить, заполнен ли реквизит Договор в самом заказе.

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

Процедура ОбработкаПроведенияПриобретенияТоваровУслуг(Источник, Отказ, РежимПроведения) Экспорт

    // Проверяем, что документ проводится не в режиме отмены проведения
    Если РежимПроведения = РежимПроведенияДокумента.Оперативный 
        Или РежимПроведения = РежимПроведенияДокумента.Неоперативный Тогда

        // Проверяем, что есть документ-основание и это Заказ поставщику
        Если ЗначениеЗаполнено(Источник.ДокументОснование) 
            И ТипЗнч(Источник.ДокументОснование) = Тип("ДокументСсылка.ЗаказПоставщику") Тогда

            // Получаем объект заказа-основания
            ЗаказОснование = Источник.ДокументОснование.ПолучитьОбъект();

            // Проверяем, заполнен ли договор в заказе
            Если НЕ ЗначениеЗаполнено(ЗаказОснование.Договор) Тогда
                // Выводим сообщение пользователю и отменяем проведение
                Сообщение = Новый СообщениеПользователю();
                Сообщение.Текст = "Проведение документа невозможно! В заказе-основании №" 
                                + ЗаказОснование.Номер 
                                + " от " + Формат(ЗаказОснование.Дата, "ДФ=dd.MM.yyyy") 
                                + " не указан договор. Пожалуйста, укажите договор в заказе и повторите попытку.";
                Сообщение.Сообщить();
                Отказ = Истина;
            КонецЕсли;

        КонецЕсли;

    КонецЕсли;

КонецПроцедуры

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

Решение 2: Использование "рамочных" или "технических" договоров

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

Как организовать процесс:

1. В справочнике Договоры контрагентов создайте для поставщика специальный договор с наименованием, например, "Рамочный договор" или "Договор на согласовании".
2. Менеджеры при создании Заказа поставщику, когда основного договора еще нет, указывают этот "рамочный" договор.
3. Документ проводится, создается корректный Объект расчетов, по нему можно проводить авансовые платежи.
4. Когда основной договор подписан, есть два варианта действий:
   • Идеальный вариант: если по заказу еще не было движений (оплат, поступлений), менеджер просто заходит в Заказ поставщику и меняет "рамочный" договор на основной.
   • Рабочий вариант: если движения уже были, "рамочный" договор остается в заказе. В документе Приобретение товаров и услуг и последующих документах также указывается этот "рамочный" договор. Это не нарушает учет, так как вся цепочка операций будет связана одним объектом расчетов, а аналитика по конкретным договорам будет доступна в отчетах. При необходимости можно будет сделать корректировку задолженности для переноса расчетов на основной договор.

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

Решение 3: Разделение процессов с помощью разных документов

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

Схема процесса:

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

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

Решение 4: Использование статусов заказа

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

Пример настройки процесса:

1. Настройте статусы заказа, например: "Черновик", "На согласовании" (договор не указан), "Согласован" (договор указан), "К поступлению".
2. Установите правило (административно или программно), что создавать Приобретение товаров и услуг можно только на основании заказа со статусом "К поступлению".
3. Добавьте проверку (через подписку на событие или в самом модуле документа через расширение), что перевод заказа в статус "Согласован" или "К поступлению" возможен только при заполненном реквизите Договор.

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