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