Почему корректировка реализации не изменяет статус заказа клиента в 1С:Управление торговлей 11 и как это исправить?

← На главную

Мы рассмотрим распространенную проблему, с которой сталкиваются пользователи конфигурации 1С:Управление торговлей 11 (и аналогичных, таких как 1С:ERP) при работе с документом «Корректировка реализации». Суть проблемы заключается в том, что после проведения корректировки реализации на уменьшение количества товаров статус связанного заказа клиента не обновляется должным образом. Это приводит к тому, что заказ остается в состоянии «Ожидается оплата(после отгрузки)» или «К отгрузке», хотя фактически отгрузка была скорректирована или отменена. Подобное расхождение искажает реальное состояние выполнения заказов и может привести к неверному планированию отгрузок и некорректным взаиморасчетам. Мы выясним, почему возникают эти несоответствия, и предложим несколько подходов к решению данной ситуации, включая использование альтернативных документов и доработку конфигурации.

Анализ проблемы: почему корректировка реализации не влияет на статус заказа?

Мы начнем с анализа основной причины такого поведения. Документ «Корректировка реализации» в 1С:УТ 11 по своей природе является в первую очередь финансовым документом. Его основная задача — скорректировать финансовые показатели (выручку, себестоимость, взаиморасчеты с клиентом, НДС) уже совершенной операции реализации. Однако, он не всегда предназначен для оперативного изменения состояния выполнения заказов клиентов или движения товаров по складским остаткам в том же объеме, что и первичные документы.

Когда мы формируем документ «Реализация товаров и услуг» на основании заказа клиента, система делает движения по нескольким ключевым регистрам. Эти движения и определяют статус заказа и состояние склада:

«Заказы клиентов»: В этом регистре фиксируется, сколько товаров было отгружено по заказу. Именно этот регистр напрямую влияет на определение статуса заказа (например, «Ожидается оплата», «К отгрузке», «Отгружен»).
«ТоварыКОтгрузке»: Здесь отслеживается количество товаров, которое еще предстоит отгрузить по заказам. Отгрузка уменьшает ресурсы этого регистра, а возврат — увеличивает.
«Расчеты с клиентами»: Фиксируется задолженность клиента, изменяется состояние оплаты. Это регистр взаиморасчетов.
«ТоварыНаСкладах»: Уменьшаются свободные остатки товаров на складе после отгрузки.
Бухгалтерские и налоговые регистры: Формируются проводки по выручке, себестоимости, НДС, что относится к финансовому учету.

При вводе «Корректировки реализации» на уменьшение количества, документ корректно изменяет финансовые регистры (например, уменьшая выручку и задолженность клиента в регистре Расчеты с клиентами). Однако, в типовом функционале он часто не производит обратных движений по оперативным регистрам, таким как Заказы клиентов и ТоварыКОтгрузке, которые отвечают за фактическое состояние выполнения заказа и доступность товаров к дальнейшей отгрузке. Именно это отсутствие движений и приводит к тому, что статус заказа остается неизменным, как будто отгрузка все еще актуальна или ожидает оплаты, хотя товар фактически был «возвращен» или его количество уменьшено по документам. Мы сталкиваемся с ситуацией, когда финансовая сторона скорректирована, а операционная – нет.

Решение 1: Использование документа «Возврат товаров от покупателя»

Мы рассмотрим первый и зачастую наиболее корректный с точки зрения методологии учета способ решения проблемы — использование документа «Возврат товаров от покупателя». Этот подход рекомендуется большинством экспертов и самой фирмой «1С» в случаях, когда требуется не просто скорректировать финансовые данные, а именно «отменить» часть ранее проведенной отгрузки или принять товар обратно на склад.

Почему «Возврат товаров от покупателя» предпочтительнее:

Комплексное воздействие: В отличие от «Корректировки реализации», документ «Возврат товаров от покупателя» разработан для полноценного отражения обратного движения товаров. Он корректно влияет как на финансовый, так и на оперативный учет.
Изменение статуса заказа: При проведении возврата товаров от покупателя, система автоматически формирует необходимые движения по регистру Заказы клиентов. Это уменьшает количество отгруженных товаров по заказу и тем самым изменяет его статус на соответствующий (например, «К отгрузке» или «Согласован», если возврат полностью отменяет отгрузку и делает товар снова доступным к планированию отгрузок).
Складской учет: Документ правильно отражает поступление товаров обратно на склад, увеличивая их остатки в регистре ТоварыНаСкладах.
Взаиморасчеты: Корректно уменьшает задолженность покупателя в регистре Расчеты с клиентами и формирует соответствующие проводки по НДС, если таковые требуются.

Как оформить «Возврат товаров от покупателя» в 1С:УТ 11:

Открытие документа: Мы можем создать документ «Возврат товаров от покупателя» одним из двух способов:
- На основании реализации (рекомендуемый способ): Откройте исходный документ «Реализация товаров и услуг». Нажмите кнопку «Создать на основании» и выберите «Возврат товаров от покупателя». При этом большая часть данных (клиент, номенклатура, цены, договор) будет заполнена автоматически, что минимизирует ошибки.
- Из списка документов: Перейдите в раздел «Продажи» -> «Возвраты товаров от клиентов». Создайте новый документ и вручную заполните все поля, включая ссылку на документ реализации (в поле «Документ реализации») и связанный «Заказ клиента».
Выбор номенклатуры и количества: В табличной части документа возврата нам необходимо указать те товары и их количество, которые клиент фактически возвращает или которые мы хотим «отменить» из первоначальной отгрузки. Система может предложить заполнить эти данные на основании исходной реализации.
Указание заказа клиента: Критически важно убедиться, что в документе возврата указан тот же Заказ клиента, что и в исходной реализации. Это обеспечит правильное связывание движений возврата с заказом и корректное обновление его статуса.
Указание склада: Мы должны указать склад, на который возвращается товар.
Проведение документа: После заполнения всех необходимых полей и проверки корректности данных, мы проводим документ. Система сформирует все нужные движения по регистрам, включая Заказы клиентов, ТоварыНаСкладах и Расчеты с клиентами.

Нюансы с НДС при «Возврате товаров от покупателя»:

Как отмечалось в сообщении 10, иногда могут возникать вопросы с корректным отражением НДС при возвратах, особенно если возврат происходит в другом налоговом периоде или имеются специфические условия договора. Эти нюансы, как правило, требуют внимания бухгалтера и, возможно, дополнительных настроек или документов (например, корректировочных счетов-фактур), но в целом «Возврат товаров от покупателя» остается наиболее предпочтительным способом отмены отгрузки с точки зрения оперативного и финансового учета.

Решение 2: Доработка конфигурации для формирования движений по регистрам «Заказы клиентов» и «ТоварыКОтгрузке»

В случаях, когда использование «Возврата товаров от покупателя» по каким-либо причинам нежелательно или невозможно (например, если корректировка реализации вызвана исключительно изменением стоимости без физического возврата, но при этом необходимо обновить статус заказа, или если бизнес-процесс требует использования именно «Корректировки реализации»), мы можем рассмотреть вариант доработки конфигурации. Этот путь более сложный и требует навыков программирования на платформе 1С, но позволяет добиться желаемого поведения документа «Корректировка реализации».

Основная идея доработки заключается в том, чтобы заставить документ «Корректировка реализации» формировать дополнительные движения по оперативным регистрам Заказы клиентов и ТоварыКОтгрузке, аналогично тому, как это делает документ «Возврат товаров от покупателя».

Мы будем работать с механизмом обработки проведения документа. Нам потребуется внести изменения в код модуля объекта документа КорректировкаРеализации, добавив в него логику формирования движений по указанным регистрам. Давайте разберем по шагам, как это можно реализовать, основываясь на представленном примере из форума.

Определение учетных механизмов документа:
Прежде чем документ сможет формировать движения по каким-либо регистрам, его модуль объекта должен указать системе, с какими учетными механизмами он взаимодействует. Это делается в процедуре ЗарегистрироватьУчетныеМеханизмы. Мы должны убедиться, что механизм "Продажи" (который часто включает работу с заказами) добавлен. Если он не добавлен, его следует добавить:
```
Процедура ЗарегистрироватьУчетныеМеханизмы(МеханизмыДокумента) Экспорт
    МеханизмыДокумента.Добавить("Продажи");
    // ... другие механизмы, если они уже есть в типовой конфигурации
КонецПроцедуры
```
Далее, внутри процедуры обработки проведения документа (или в соответствующем общем модуле, который вызывается из этой процедуры) нам потребуется добавить вызовы функций, которые будут формировать запросы для движений по нашим регистрам ЗаказыКлиентов и ТоварыКОтгрузке:
```
/////////////////////////////////////////////////////////////////////////////////////////////
ТекстЗапросаТаблицаЗаказыКлиентов(Запрос, ТекстыЗапроса, Регистры);
ТекстЗапросаТаблицаТоварыКотгрузке(Запрос, ТекстыЗапроса, Регистры);
/////////////////////////////////////////////////////////////////////////////////////////////
```
Эти строки должны быть размещены в соответствующем месте процедуры обработки проведения документа, где формируются запросы для всех регистров (например, в конце процедуры, отвечающей за формирование запросов).
Формирование движений по регистру «Заказы клиентов»:
Теперь мы создадим функцию ТекстЗапросаТаблицаЗаказыКлиентов. Эта функция будет возвращать текст запроса, который система затем использует для создания движений по регистру ЗаказыКлиентов. Важно понимать, что корректировка на уменьшение должна сторнировать (т.е. отменять) предыдущее движение отгрузки. Для этого мы будем использовать ВидДвиженияНакопления.Приход с отрицательными значениями количества и суммы. Это означает, что мы как бы "возвращаем" товар в "заказанное" состояние, увеличивая остаток по заказу на то количество, которое было уменьшено корректировкой.
```
Функция ТекстЗапросаТаблицаЗаказыКлиентов(Запрос, ТекстыЗапроса, Регистры)
    ИмяРегистра = "ЗаказыКлиентов";
    Если НЕ ПроведениеДокументов.ТребуетсяТаблицаДляДвижений(ИмяРегистра, Регистры) Тогда
        Возврат "";
    КонецЕсли;
    ТекстЗапроса = "ВЫБРАТЬ
                   | ЗНАЧЕНИЕ(ВидДвиженияНакопления.Приход) КАК ВидДвижения,
                   | ТаблицаТовары.Ссылка.Дата КАК Период,
                   | ТаблицаТовары.ЗаказКлиента КАК ЗаказКлиента,
                   | ТаблицаТовары.Номенклатура КАК Номенклатура,
                   | ТаблицаТовары.Характеристика КАК Характеристика,
                   | ТаблицаТовары.Серия КАК Серия,
                   | ТаблицаТовары.номерстроки КАК КодСтроки,
                   | ВЫБОР КОГДА ТаблицаТовары.Номенклатура.ТипНоменклатуры В (ЗНАЧЕНИЕ(Перечисление.ТипыНоменклатуры.Товар),ЗНАЧЕНИЕ(Перечисление.ТипыНоменклатуры.МногооборотнаяТара)) ТОГДА
                   | ТаблицаТовары.Склад
                   | ИНАЧЕ
                   | ЗНАЧЕНИЕ(Справочник.Склады.ПустаяСсылка)
                   | КОНЕЦ КАК Склад,
                   | -ТаблицаТовары.Количество КАК Заказано,
                   | -ТаблицаТовары.Количество КАК КОформлению,
                   | -Сумма КАК Сумма,
                   | ЗНАЧЕНИЕ(Справочник.ПричиныОтменыЗаказовКлиентов.ПустаяСсылка) КАК ПричинаОтмены
                   |ИЗ
                   | Документ.КорректировкаРеализации.расхождения КАК ТаблицаТовары
                   | где ТаблицаТовары.Ссылка = &ссылка";
    ТекстыЗапроса.Добавить(ТекстЗапроса, ИмяРегистра);
    Возврат ТекстЗапроса;
КонецФункции
```
Мы проанализируем этот код, чтобы понять логику:
- ВидДвиженияНакопления.Приход: В контексте сторнирования отгрузки, «Приход» с отрицательным количеством фактически отменяет ранее сделанный «Расход» (отгрузку) по заказу. Это позволяет системе «увидеть», что ранее отгруженное количество по заказу уменьшилось.
- ТаблицаТовары.Ссылка.Дата КАК Период: В качестве даты движения мы используем дату документа корректировки.
- ТаблицаТовары.ЗаказКлиента КАК ЗаказКлиента: Это поле связывает движение корректировки с исходным заказом клиента. Без этой связи система не сможет корректно обновить статус заказа.
- -ТаблицаТовары.Количество КАК Заказано, -ТаблицаТовары.Количество КАК КОформлению, -Сумма КАК Сумма: Это ключевой момент. Отрицательные значения сторнируют ранее проведенные движения. Заказано и КОформлению используются для учета состояния выполнения заказа, отражая, сколько по заказу должно быть еще отгружено или оформлено.
- ТаблицаТовары.номерстроки КАК КодСтроки: Как было отмечено в обсуждении на форуме (сообщения 12, 13), использование номерстроки в качестве КодСтроки может быть не идеальным, если строки заказа могут меняться или удаляться. Однако, в данном конкретном случае, это решение работает и помогает связать движения корректировки с конкретными строками заказа. В более сложных сценариях может потребоваться более надежный идентификатор строки заказа, но для простой схемы оно приемлемо.
- Документ.КорректировкаРеализации.расхождения КАК ТаблицаТовары: Запрос берет данные из табличной части «Расхождения» документа корректировки, где указывается, какие товары и в каком количестве корректируются.
Формирование движений по регистру «ТоварыКОтгрузке»:
Аналогичным образом мы создадим функцию ТекстЗапросаТаблицаТоварыКотгрузке для регистра ТоварыКОтгрузке. Этот регистр показывает, сколько товаров еще предстоит отгрузить по заказам. Если корректировка отменяет отгрузку, то товар снова должен стать "доступным к отгрузке". Это критически важно, если мы планируем повторную отгрузку по этому же заказу, как это было упомянуто в сообщении 7.
```
Функция ТекстЗапросаТаблицаТоварыКотгрузке(Запрос, ТекстыЗапроса, Регистры)
    ИмяРегистра = "ТоварыКОтгрузке";
    ТекстЗапроса = "ВЫБРАТЬ
                   | ЗНАЧЕНИЕ(ВидДвиженияНакопления.Приход) КАК ВидДвижения,
                   | ТаблицаТовары.Ссылка.Дата КАК Период,
                   | &ссылка КАК регистратор,
                   |ТаблицаТовары.ЗаказКлиента КАК ДокументОтгрузки,
                   | &Партнер КАК Получатель,
                   | ТаблицаТовары.Номенклатура КАК Номенклатура,
                   | ТаблицаТовары.Характеристика КАК Характеристика,
                   | ТаблицаТовары.Серия КАК Серия,
                   | ТаблицаТовары.номерстроки КАК КодСтроки,
                   | ВЫБОР КОГДА ТаблицаТовары.Номенклатура.ТипНоменклатуры В (ЗНАЧЕНИЕ(Перечисление.ТипыНоменклатуры.Товар),ЗНАЧЕНИЕ(Перечисление.ТипыНоменклатуры.МногооборотнаяТара)) ТОГДА
                   | ТаблицаТовары.Склад
                   | ИНАЧЕ
                   | ЗНАЧЕНИЕ(Справочник.Склады.ПустаяСсылка)
                   | КОНЕЦ КАК Склад,
                   | -ТаблицаТовары.Количество КАК КОтгрузке,
                   | -ТаблицаТовары.Количество КАК КОформлению
                   |ИЗ
                   | Документ.КорректировкаРеализации.расхождения КАК ТаблицаТовары
                   | где ТаблицаТовары.Ссылка = &ссылка";
    ТекстыЗапроса.Добавить(ТекстЗапроса, ИмяРегистра);
    Возврат ТекстЗапроса;
КонецФункции
```
Основные моменты данного кода:
- ВидДвиженияНакопления.Приход с отрицательными значениями: Также, как и для ЗаказыКлиентов, мы используем приход с отрицательным количеством. Это действие отменяет предыдущее уменьшение ресурсов КОтгрузке и КОформлению, тем самым «возвращая» товар в резерв или делая его доступным для последующей отгрузки по этому же заказу.
- &ссылка КАК регистратор, ТаблицаТовары.ЗаказКлиента КАК ДокументОтгрузки: Правильно связываем движение с документом корректировки (регистратором) и исходным заказом клиента (документом отгрузки).
- &Партнер КАК Получатель: Передаем партнера (клиента), поскольку этот регистр может использоваться для аналитики по получателям.
- -ТаблицаТовары.Количество КАК КОтгрузке, -ТаблицаТовары.Количество КАК КОформлению: Отменяем предыдущее уменьшение этих ресурсов, восстанавливая количество, которое может быть отгружено.
Устранение проблем с регистром «РаспределениеЗапасов»:
В ходе обсуждения на форуме (сообщения 9, 10, 11) была выявлена еще одна проблема, связанная с документом КорректировкаРеализации: он может некорректно двигать регистр РаспределениеЗапасов. Регистр РаспределениеЗапасов используется для предварительного резервирования и планирования движения товаров, и его некорректная работа может приводить к тому, что отчеты по остаткам и доступности товаров показывают завышенные или некорректные данные, искажая общую картину доступности товаров для будущих отгрузок.

Предлагаемое решение для этого конкретного бага, как это было сделано в сообщении 9 — заблокировать движение по регистру РаспределениеЗапасов для документа КорректировкаРеализации. Это делается путем комментирования соответствующей строки вызова функции формирования запроса для этого регистра в процедуре обработки проведения документа:
//ОтразитьРаспределениеЗапасовДвижения(Запрос, ТекстыЗапроса, Регистры);
Мы должны понимать, что это скорее обходной путь для известной недоработки в конфигурации. Полное понимание роли этого регистра и корректная его обработка документом КорректировкаРеализации требовали бы более глубокого анализа и, возможно, сложной доработки, которая не всегда оправдана в рамках текущей задачи, особенно если документ не должен влиять на резервы в принципе. Комментирование этой строки предотвращает нежелательные движения, но не исправляет корневую причину, если таковая существует.

Важные моменты и рекомендации при доработке

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

Резервное копирование: Перед внесением любых изменений в конфигурацию, мы всегда должны делать полную резервную копию информационной базы. Это позволит нам вернуться к исходному состоянию в случае непредвиденных проблем.
Разработка в тестовой базе: Все доработки должны сначала проводиться и тестироваться в отдельной тестовой информационной базе, которая является полной копией рабочей. Мы должны избегать прямых изменений в рабочей конфигурации.
Тщательное тестирование: После доработки необходимо провести тщательное тестирование в тестовой базе на различных сценариях:
- Корректировка реализации на уменьшение количества (как в исходной проблеме).
- Полная отмена реализации через корректировку.
- Частичная отмена реализации.
- Повторная отгрузка товаров по скорректированному заказу.
- Проверка отчетов по заказам, остаткам и взаиморасчетам.
Мы должны убедиться, что все регистры (Заказы клиентов, ТоварыКОтгрузке, Расчеты с клиентами) отражают корректные данные после проведения корректировки.
Влияние на обновления: Любая доработка конфигурации увеличивает сложность последующих обновлений. Мы должны быть готовы к тому, что при каждом обновлении конфигурации потребуется повторно анализировать и интегрировать внесенные изменения, возможно, адаптируя код под новые версии платформы или конфигурации.
Версионирование: Рекомендуется использовать систему контроля версий (например, хранилище конфигурации) для отслеживания всех изменений в коде.
Альтернатива "сверх заказа": Если после корректировки реализации на уменьшение количества нам необходимо отгрузить другой товар по тому же заказу взамен недопоставленного, можно оформить новую реализацию. Для строки товара, которая не была в исходном заказе или превышает его, можно указать признак "сверх заказа". Это позволит отгрузить товар, который формально не был учтен в оригинальной спецификации заказа, но требуется по факту.

Заключение

Мы видим, что проблема некорректного изменения статуса заказа клиента после «Корректировки реализации» в 1С:УТ 11 является достаточно распространенной и имеет свои корни в логике работы документа. Мы рассмотрели два основных пути решения, которые позволяют справиться с этой задачей:

Использование более подходящего для этих целей документа «Возврат товаров от покупателя». Этот метод обеспечивает комплексное и методологически правильное отражение операций возврата товаров, автоматически обновляя статусы заказов, складские остатки и взаиморасчеты. Мы рекомендуем этот подход как наиболее простой и надежный, если он соответствует вашим бизнес-процессам.
Доработка конфигурации путем добавления программных движений по регистрам Заказы клиентов и ТоварыКОтгрузке для документа КорректировкаРеализации. Кроме того, мы рассмотрели обход проблемы с регистром РаспределениеЗапасов. Этот путь требует программирования и глубокого понимания структуры конфигурации, но дает больше гибкости в случаях, когда типовой «Возврат товаров от покупателя» не подходит.

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