Анализ движения резервов по заказам (1С:УНФ)

Резервирование запасов — полезная функция в 1С:УНФ, которая позволяет зарезервировать товары на складе под конкретный "Заказ покупателя" и сделать их недоступными для отгрузки другим клиентам. Также можно резервировать материалы и сырье под "Заказы на производство", что помогает исключить путаницу на производстве из-за перехвата материалов под другие заказы.

При движении товара по внутренним документам резерв тоже перемещается. Например, когда мы передаем зарезервированные материалы со склада в производство, резерв со склада снимается и появляется в производственном подразделении.

Бывает так, что резервы «зависают» в документах, которые стали неактуальными, но менеджеры забыли их отменить. Кроме того, существует человеческий фактор, из-за которого резерв иногда записывается некорректно. И получается, что на складах у нас лежит реальный товар, но отгрузить его или взять в производство невозможно — система не позволяет. Возникает вопрос: как найти ошибку в резервах 1С УНФ?

В УНФ есть стандартный отчет «Остатки товаров на складах», в котором можно увидеть количество зарезервированного товара на складах. Проблема в том, что мы видим только количество резерва, но не видим, из чего данный резерв сложился, какой путь прошел по документам.

Чтобы выяснить, в каких конкретно «Заказах клиентов» и «Заказах на производство» размещены резервы ТМЦ, нами был разработан отчет «Анализ движения резервов по заказам», позволяющий найти ошибку и оценить, стоит ли оставлять данный резерв или лучше его снять (а может перевесить на другой Заказ клиента / другой склад).

Отчет одинаково корректно работает как для УНФ ред 1.6, так и для ред 3.0. (Проверено на релизе 3.0.11.161)

Пример использования (производственное расследование)

Руководителю компании «Наша фирма» начали поступать жалобы от сотрудников, что возникают проблемы при оформлении Заказов покупателей и Расходных накладных — система показывает, что доступных остатков нет, хотя товара на складе значительно больше, чем должно быть в актуальных резервах под клиентов. На данном предприятии в 1С:УНФ с товарами работают менеджеры по продажам (Заказ покупателя, Резервирование запасов), логист (Заказ поставщику) и кладовщик (Расходная / Приходная накладная, Перемещение). Начали разбираться, что вызывает сбой в учете.

Для анализа взяли одну номенклатуру: Торшер. При оформлении нового Заказа покупателя менеджер по продажам не смог его провести, получаем уведомление об ошибке: «Не хватает остатка по учету запасов и затрат». Хотя товар на складе закуплен с запасом, ничего мешать для отгрузки просто не должно.

Для анализа обратились к стандартному отчету «Остатки товаров на складах», который показывает количество зарезервированного товара по заказам покупателей. Заказов много, под каждый сделан резерв, визуально они никак не отличаются.

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

Однако они предпочли упростить себе задачу и обратились к разработке МИКО — Внешний отчет «Анализ движения резервов по заказам». Преимущество данного отчета именно в том, что он показывает нам документы, по которым двигался товар, в результате чего на каждом этапе (документе) мы видим, как изменяется остаток в резерве.

Здесь нам открылась совсем другая картина. На скрине видно, что отчет отображает все документы, которые работают с резервами (Заказ, Накладная, Резервирование). Большинство резервов возникло из документов Заказ покупателя, Заказ на производство или Резервирование запасов, то есть резерв устанавливался на товары, которые уже были на складе в свободных остатках. А вот резерв, относящийся к Заказу покупателя №7, был создан по другому сценарию — он зарегистрирован в момент проведения документа Приходная накладная. Вот его-то мы и будем анализировать!

Так как резерв возник при проведении Приходной накладной, мы понимаем, что под данный Заказ покупателя был создан Заказ поставщику (схема «Заказ под заказ») — именно в такой ситуации резерв возникает в момент поступления товара, и будет стоять в резерве, пока мы не отгрузим товар или не снимем резерв с этого заказа.

Заходим в Заказ покупателя. Было заказано 5 шт торшеров. Переходим в связанный с ним Заказ поставщику — в данном заказе количество товара уже 50 шт. Соответственно, все Торшеры по данной Приходной накладной попали в резерв по Заказу покупателя, и после отгрузки 5 шт оставшиеся 45 шт так и остались висеть в резерве. Соответственно, данный товар было невозможно ни зарезервировать под другие заказы, ни отгрузить, хотя фактически это свободный остаток.

Как это произошло? Начали восстанавливать хронологию событий.

Выяснилось, что менеджер по продажам оформил в 1С УНФ Заказ покупателя на 5 торшеров. На основании этого документа логист создал Заказ поставщику, в котором решил заказать не 5, а 50 торшеров, т.к. им нужно было пополнить склад для продажи из свободных остатков. Он просто изменил исходное количество 5 шт на 50, увидел, что в Заказе поставщику отражаются необходимые 50 шт, и пустил документ в работу.

Товар поступил на склад. Необходимые 5 торшеров отгрузили Покупателю 1. Кладовщик оформил Приходную и Расходную накладные, соответственно.

Ни логист, ни кладовщик не занимаются резервами. А менеджер по продажам провел свой документ Заказ покупателя корректно. В чем же была загвоздка?

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

Расследование окончено!

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

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

В данной статье мы рассмотрели только один вариант применения отчета «Анализ движения резервов по заказам», как пример. Каждая компания уникальна и решает свои задачи, а следить за их четким выполнением помогают автоматизированные решения.

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