В практике торговых предприятий часто возникает ситуация, когда клиент возвращает большее количество многооборотной тары (поддонов, кег, ящиков), чем за ним числится в учетной системе. В конфигурации 1С:Управление торговлей 11.5 (а также в ERP 2.5 и КА 2.5) встроен жесткий механизм контроля, который блокирует проведение документа Возврат товаров от клиента, если количество возвращаемой тары превышает накопленный долг контрагента. В этой статье мы подробно разберем, почему так происходит и какими способами можно обойти это ограничение.
Для начала выясним причину, по которой система выдает ошибку. Весь учет возвратной тары в 1С:УТ 11.5 ведется в специализированном регистре накопления ПереданнаяВозвратнаяТара. Когда мы отгружаем товар в таре, этот регистр делает движение «Приход», фиксируя долг клиента перед нами в количественном и стоимостном (залоговом) выражении. При возврате система делает движение «Расход».
Алгоритм проведения документа Возврат товаров от клиента обязательно обращается к этому регистру и выполняет проверку: «Остаток по клиенту >= Количество в документе». Если клиент возвращает 10 ящиков, а по данным регистра за ним числится только 8, система прерывает проведение, так как не может списать в «минус» то, чего официально нет. При этом отключение общего контроля остатков товаров на складе в настройках НСИ и администрирование не помогает, так как контроль тары — это обособленный механизм взаиморасчетов. Для детального анализа истории отгрузок и возвратов тары в разрезе клиентов можно использовать отчет «Акт сверки взаиморасчетов по номенклатуре».
Рассмотрим самый быстрый «штатный» способ, который не требует изменения программного кода. Если клиент действительно привез лишнюю тару, и вы готовы ее принять, значит, в вашей базе данных не хватает сведений о ранее переданной ему таре (возможно, это остатки из старой системы или неучтенные ранее поставки). При переходе на новую версию программы для переноса накопленных остатков, документов и справочной информации используется инструмент переноса данных из УТ 10.3 в УТ 11.
Для исправления ситуации выполним следующие шаги:
После этого регистр ПереданнаяВозвратнаяТара пополнится «виртуальным» долгом клиента, и документ возврата проведется без ошибок. Проанализируем ситуацию: этот метод хорош тем, что сохраняет целостность методологии 1С, но требует ручных манипуляций при каждом «излишке».
Если логика вашего бизнеса допускает, что клиент может вернуть «чужую» тару или тару, которая уже перешла в его собственность, то методически правильно оформить это не как возврат, а как закупку.
Разберем этот процесс подробнее:
Вместо документа Возврат товаров от клиента мы создаем Приобретение товаров и услуг. В этом случае:
ПереданнаяВозвратнаяТара вообще не затрагивается, так как мы не «забираем долг», а «покупаем имущество».В дальнейшем эту тару можно будет снова выдавать как возвратную, так как на складе она будет числиться под тем же кодом Номенклатура.
Если подобные ситуации случаются постоянно и бухгалтерия не хочет плодить лишние документы ввода остатков, можно внести изменения в программный код через механизм расширений. Наша задача — заставить систему игнорировать нехватку остатка, если тип номенклатуры соответствует Тара.
Проанализируем программную логику. Проверка остатков обычно происходит в модуле менеджера документа или в специализированных серверных модулях, таких как ЗапасыСервер. Нам необходимо найти процедуру, отвечающую за контроль остатков переданной тары, и добавить условие.
Примерный алгоритм изменения логики в расширении (псевдокод):
&После("СформироватьДвиженияПереданнаяВозвратнаяТара")
Процедура ИТ_СформироватьДвиженияПереданнаяВозвратнаяТара(Отказ, Движения, Параметры)
// Здесь система обычно проверяет остатки и устанавливает Отказ = Истина
// Мы можем проанализировать таблицу ошибок и, если ошибка касается только тары,
// сбросить флаг Отказ, позволяя документу провестись в "минус".
Для Каждого СтрокаОшибки Из Параметры.ТаблицаОшибок Цикл
Если СтрокаОшибки.Номенклатура.ТипНоменклатуры = ПредопределенноеЗначение("Перечисление.ТипыНоменклатуры.Тара") Тогда
// Логика игнорирования ошибки
// Внимание: это приведет к отрицательным остаткам в регистре!
КонецЕсли;
КонецЦикла;
КонецПроцедуры
Важный момент: разрешая проведение в «минус», вы должны понимать, что в отчете Ведомость по переданной возвратной таре у клиента возникнет отрицательный остаток. Это означает, что теперь вы должны клиенту тару. При следующей отгрузке этот минус автоматически закроется.
Посмотрим на настройки регистра сведений Настройки контроля обеспечения. В некоторых релизах УТ 11 можно попробовать настроить исключения для конкретных складов или групп номенклатуры, однако для регистра ПереданнаяВозвратнаяТара штатной возможности «разрешить минус» через интерфейс настроек обычно нет. Тем не менее, стоит проверить, не включен ли расширенный контроль остатков в разрезе организаций, который может дублировать проверку. Для выявления таких несоответствий можно использовать отчет для поиска расхождений между регистрами товаров на складах и товаров организаций.
Выясним, к чему может привести бесконтрольный прием лишней тары. Основной риск связан с залоговой стоимостью. Если клиент вернул тару по одной цене, а в базе она числится (или будет числиться в будущем) по другой, возникнут расхождения в суммовом учете. Кроме того:
Подводя итог, наиболее сбалансированным решением является Решение №1 (Ввод остатков). Оно позволяет сохранить строгий учет и при этом оперативно «узаконить» появление лишней тары в базе без привлечения программистов.