В этой статье мы подробно разберем ситуацию, с которой часто сталкиваются пользователи и консультанты при работе в 1С:ERP (в частности, версий линейки 2.5.12). Речь пойдет о проблеме автоматического закрытия заказа клиента при использовании гибридного варианта расчетов.
Представим сценарий: мы полностью отгрузили товар и получили полную оплату от клиента. Казалось бы, цепочка завершена, и заказ должен перейти в статус "Закрыт". Однако система продолжает считать его незавершенным, требуя каких-то действий. Чтобы понять, на каком этапе произошел сбой, полезно провести детальный анализ выполнения отгрузок и оплат по заказам покупателей. Давайте разберемся, почему это происходит и как работает архитектура взаиморасчетов в различных версиях конфигурации.
Рассмотрим ситуацию, описанную в исходном вопросе. У нас есть следующая вводная:
Заказ клиента установлен аналогичный вариант расчетов.Мы выполняем стандартный процесс:
Реализация товаров и услуг на полную сумму.В результате, по данным управленческого учета, долгов нет, товары отгружены. Мы ожидаем, что при такой идеальной картине заказ клиента должен быть закрыт (автоматически регламентным заданием или вручную по кнопке закрытия). Но заказ остается в статусе "В работе" или "К выполнению", и система не позволяет его закрыть стандартным способом.
Давайте углубимся в логику работы этого механизма. Чтобы понять причину, нам нужно посмотреть на то, как система распределяет объекты расчетов.
Суть настройки «Аванс по заказам, долг по накладным» заключается в динамической смене объекта расчетов в процессе жизненного цикла сделки:
Заказ клиента. Поступившие авансы "вешаются" на заказ.Реализация товаров и услуг происходит перенос задолженности. Система формирует движения, которые "забирают" долг с заказа и переносят его на накладную. Теперь объектом расчетов для оставшейся части суммы становится сама накладная.В версиях ERP до обновления архитектуры (в частности, в 2.5.12) механизм проверки условий для закрытия заказа работает следующим образом: он проверяет, выполнены ли финансовые обязательства непосредственно по объекту Заказ клиента.
Проблема возникает из-за разрыва связи в момент проверки статуса. Система видит, что:
В регистрах накопления мы увидим два разных объекта расчетов: Заказ клиента и Реализация товаров и услуг. Хотя сальдо в целом по партнеру нулевое, алгоритм закрытия заказа в версии 2.5.12 не всегда корректно "собирает" эту картину воедино, ожидая завершения расчетов именно в контексте заказа.
Важно отметить, что разработчики 1С признали сложность и неочевидность такого поведения. В версиях, начиная с 2.5.13, была проведена масштабная переработка архитектуры взаиморасчетов, так называемые "Новые расчеты" или "Онлайн-взаиморасчеты".
В обновленной архитектуре:
РасчетыСКлиентамиПоСрокам, который позволяет более детально отслеживать график оплат.Если мы обновим конфигурацию до актуальной версии (2.5.13 и новее), то описанный выше сценарий отработает корректно: система "увидит" оплату накладной и позволит закрыть заказ клиента без дополнительных манипуляций.
Если обновление в данный момент невозможно, нам придется использовать обходные пути, так как "заставить" алгоритм 2.5.12 работать иначе мы не можем без изменения кода конфигурации.
Давайте рассмотрим, что можно сделать:
В некоторых случаях проблема кроется не только в оплате, но и в регистре сведений, отвечающем за статусы заказов. Если визуально все оплачено и отгружено, но заказ "висит", проверьте регистр сведений (через функции технического специалиста), связанный со статусами заказов. Иногда там могут "зависать" записи с состоянием "Ожидается оплата".
Самый действенный метод для старых релизов — ручная установка статуса. Алгоритм автоматического закрытия может блокировать действие, но ручная установка статуса часто позволяет обойти проверку.
Попробуйте выполнить следующие действия:
Если система выдает ошибку при проведении закрытого заказа, внимательно читайте текст ошибки. Если она ссылается на незавершенные расчеты, перейдите к следующему пункту.
Вместо простого изменения статуса в документе, воспользуемся специализированной обработкой.
Перейдем в раздел Продажи – Сервис – Закрытие заказов клиентов. Этот инструмент проводит более глубокую диагностику. Часто он позволяет увидеть детальную причину, а для полной проверки цепочек документов пригодится анализ оплат и реализаций по заказам клиентов, который покажет, какими именно документами были закрыты потребности.
В версиях 2.5.12 критически важно точное совпадение сумм в графике оплат (вкладка "Правила оплаты" в заказе) и фактических движений.
Проанализируйте табличную часть ЭтапыГрафикаОплаты в заказе. Убедитесь, что:
Если платежи разбились иначе, чем запланировано (например, аванс был чуть меньше, а постоплата чуть больше), система может считать, что условия графика по "предоплате" не выполнены, даже если общая сумма верна.
Если вы настраиваете систему для клиента и планируете использовать схему «Аванс по заказам, долг по накладным», мы рекомендуем придерживаться следующих правил:
Ведомость расчетов с клиентами в такой схеме обязательно учитывайте группировки. Для полноценного контроля за ситуацией проводите регулярный анализ продаж и оплат по объектам расчётов. Если включить группировку по "Объекту расчетов", вы увидите "рваное" сальдо (плюс на заказе, минус на накладной или наоборот). Для корректного анализа с клиентом всегда отключайте детализацию до объекта расчетов, оставляя только Договор/Контрагента.Подводя итог: поведение, когда заказ не закрывается при полной оплате и отгрузке в режиме смешанных расчетов на версии 2.5.12, является известной особенностью той архитектуры. Решением является либо переход на более новую версию платформы, либо ручной контроль и принудительное закрытие таких заказов.