← На главную

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

1. Наши первоначальные намерения: какое количество товара и по какой цене мы планировали заказать (исходя из потребностей обеспечения склада или под заказы клиентов).
2. Подтверждение поставщика: какое количество позиций и по какой стоимости поставщик согласился нам поставить после согласования заказа.
3. Фактическое поступление: сколько товара и по каким ценам реально пришло на склад по сопроводительным документам.

Если со вторым и третьим пунктами всё понятно (они фиксируются стандартными документами Заказ поставщику и Приобретение товаров и услуг), то фиксация первого пункта часто вызывает вопросы у пользователей. Рассмотрим подробнее, какими стандартными методами в программе «1С:Управление торговлей» версии 11.4 / 11.5 (а также в 1С:ERP и 1С:Комплексная автоматизация) можно реализовать эту схему без привлечения программистов.

Метод 1. Использование механизма причин отмены и разбиения строк (Внутри одного заказа)

Этот способ является наиболее популярным, так как он не требует использования дополнительных подсистем планирования и позволяет видеть всю историю изменений непосредственно внутри одного документа Заказ поставщику.

Разберем данный процесс по шагам:

Шаг 1. Фиксация первоначальных намерений (Шаг 1)
При создании документа Заказ поставщику мы вносим в табличную часть «Товары» всю номенклатуру, которую хотим приобрести, в исходном количестве и по целевым ценам. Документ проводится в статусе «Согласован». В этот момент он отражает наши чистые намерения и отправляется поставщику на согласование.

Шаг 2. Отражение подтверждения поставщика (Шаг 2)
Когда от поставщика приходит обратная связь с корректировками (например, мы хотели заказать 10 штук товара, но поставщик подтвердил только 7 штук), менеджер переводит документ в статус «Подтвержден». При этом категорически нельзя просто перезаписывать количество в строке, иначе информация о первоначальной потребности (10 штук) будет безвозвратно утеряна.

Вместо этого мы используем встроенную функцию разбиения строки:

1. Выделяем нужную строку в табличной части документа.
2. Разбиваем ее на две строки: в первой указываем подтвержденное количество (7 штук), во второй — неподтвержденный остаток (3 штуки).
3. Для второй строки (на 3 штуки) устанавливаем флаг «Отменено».
4. В поле «Причина отмены» указываем соответствующее значение из справочника, например: «Отказ поставщика» или «Нет в наличии у поставщика».

Проанализируем результат: строка с отмененным количеством визуально выделяется серым цветом, она не делает движений по регистрам накопления (не ожидает поступления), но сохраняется в документе для истории. Таким образом, мы сохранили исходную потребность (7 + 3 = 10) и зафиксировали подтвержденный объем (7).

Шаг 3. Оформление фактического прихода (Шаг 3)
При поступлении товаров на склад на основании заказа создается документ Приобретение товаров и услуг. Если фактический приход совпал с подтвержденным (пришло ровно 7 штук), заказ успешно закрывается.

Если же возникли новые расхождения при приемке (например, привезли только 6 штук из подтвержденных 7), мы можем зафиксировать это расхождение с помощью документа Акт о расхождениях после поступления либо аналогично отменить в заказе еще одну штуку с причиной отмены «Недопоставка при транспортировке».

Метод 2. Разделение процессов через подсистему «Планирование»

Если бизнес-процессы компании предполагают предварительное планирование закупок, то разделение шагов 1 и 2 на уровне разных документов выглядит более методологически верным.

Выясним, как работает этот сценарий:

1. Фиксация намерений (Шаг 1): Все наши потребности и планы по закупкам у конкретных контрагентов мы регистрируем с помощью документа План закупок (раздел «Планирование»). Этот документ выступает «черновиком» и фиксирует наши чистые намерения по объемам и ценам.
2. Формирование заказов (Шаг 2): На основании утвержденных планов закупок с помощью специального встроенного помощника «Формирование заказов поставщикам по планам» создаются документы Заказ поставщику. В этих документах фиксируется уже согласованное с поставщиком количество.
3. Анализ отклонений: Для сопоставления первоначальных намерений и подтвержденных объемов мы используем стандартный отчет «Исполнение планов закупок». Он наглядно покажет разницу между тем, что планировалось изначально (Шаг 1), и тем, на сколько в итоге были оформлены и подтверждены заказы (Шаг 2).

Метод 3. Использование непроведенного заказа-дубля

Рассмотрим еще один альтернативный вариант, который иногда применяют на практике без изменения конфигурации:

1. Менеджер создает первый документ Заказ поставщику, заполняет его исходными потребностями и оставляет в статусе «Не проведен» (или просто не проводит его, используя как архивный шаблон). Он будет выступать эталоном Шага 1.
2. На основании этого документа создается второй (рабочий) Заказ поставщику, в котором менеджер уже правит строки под реальные ответы поставщика и проводит его.
3. Для связи этих двух документов используется механизм «Дополнительные реквизиты», где в рабочем заказе дается ссылка на исходный непроведенный заказ-шаблон. Это позволяет в будущем строить отчеты по сопоставлению данных двух документов.

Анализ результатов с помощью стандартных отчетов

Для того чтобы руководство и менеджеры могли оперативно видеть расхождения между планом, подтверждением и фактом, в системе предусмотрены следующие стандартные отчеты:

• Отчет «Состояние выполнения заказов» — вызывается непосредственно из формы документа Заказ поставщику. Он показывает в реальном времени, сколько товара было заказано (подтверждено), сколько уже поступило по факту, а сколько еще ожидается к поступлению.
• Отчет «Причины отмены заказов поставщикам» — позволяет детально проанализировать, какая часть товаров сорвалась на этапе согласования (с группировкой по поставщикам и менеджерам). Благодаря этому можно выявить ненадежных поставщиков, которые регулярно не подтверждают заявленные объемы.

Таким образом, мы видим, что типовой функционал программы 1С:Управление торговлей 11 предоставляет гибкие механизмы для контроля всей цепочки поставок без необходимости программирования и доработки системы.