gifts2017

Управление резервами товаров в УТ 11 и ERP. Особенности и нюансы

Опубликовал Олег Демиденко (FFelix) в раздел Управление - Практика учета

Система управления резервами является сердцем работы большой части торговых компаний. Данная статья сделана как обзор типовых механизмов резервирования и основных проблем, с которыми приходится сталкиваться при его использовании. Статья написана на примере торгового функционала. Но для производственного предприятия всё описанное ниже тоже актуально; просто в нём вместо потребности в готовой продукции по Заказам клиентов будет возникать потребность в материалах по Заказам на производство, а принципиально механизм резервов устроен точно так же.


Три слоя регистров – три варианта остатков товаров

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

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

Обособленный учет только по ВидамЗапасов – опасный рудимент

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

В чем подвох? Все отчеты в типовой конфигурации, сообщающие о свободных остатках, резервах, планируемых поступлениях и т.п. – строятся на регистрах управления резервами, а эти регистры о видах запасов ничего не знают. Т.е. вы можете увидеть в отчете информацию о свободных остатках товаров, но продать их не сможете – при попытке проведения Реализации товаров система будет писать о нехватке товаров организации под какой-то там вид запасов. Провести документ продажи, в данном случае, можно только с указанием той же Сделки/Менеджера/Подразделения, которые были указаны в документе закупки. По аналогии с текущими остатками, обособленные виды запасов не видны в планируемом товародвижении. Т.е. при закупках через рабочее место «Обеспечение потребностей» - программа не скажет, что нужны товары именно под определенную сделку. А если вы будете рассчитывать на ожидаемое поступление товаров, для которых в заказе поставщику указан вид запасов – можно попасть в совсем плачевную ситуацию, когда вы пообещаете клиенту товар, а потом не сможете его продать, т.к. уже потом, по факту поступления на склад, выяснится, что он был изначально предназначен для других целей.

Исторически, виды запасов были первым механизмом конфигурации по обособлению товаров под конкретное назначение (Сделку, Менеджера). На текущий момент – это рудимент, использование которого не рекомендуется, если вы не готовы сразу решить как поступать со всеми подвохами, которые в них скрыты.

Единственное принципиальное преимущество обособленного учета по видам запасов – вместе с учетом по видам запасов всегда идёт учет себестоимости. Т.е. если товары разделены по разным видам запасов, и разные виды запасов были куплены по разным ценам (поставщик продаёт товары дешевле, при условии их продаж определенным клиентам) – можно будет увидеть, что прибыльность у сделок получилась разная.

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

Функционал «обособленного учета себестоимости по видам запасов» включается в разделе Администрирование – Финансы.

Указание порядка резервирования в документах

Порядок резервирования товаров в последних версиях конфигураций (УТ 11.1.9, ERP 2.0.9) в Заказах клиентов указывается индивидуально в каждой строке списка товаров.

Возможны следующие варианты:

  • Резервировать на складе – резерв товара из текущего складского остатка
  • Резервировать к   - резерв товара по графику (подробнее – ниже), из планируемого количества остатков на эту дату
  • К обеспечению – товар никак не резервируется. В формировании заказов на обеспечение потребностей (заказов поставщикам, на перемещение с другого склада и т.п.) – будет видна потребность в этом товаре, будет предложено его заказать. Важно отметить, что в данном случае никак не контролируется, что товар действительно получится обеспечить в указанную дату. В версиях 11.0 конфигурации «Управление торговлей» такая возможность существовала (см. РС НастройкаКонтроляОстатков, реквизит ДатаГраницыГрафика), но от неё отказались ради упрощения интерфейса.
  • Не обеспечивать – товар никак не резервируется. И при формировании заказов – потребность в этом товаре также не будет фигурировать.
  • Обеспечивать обособленно – товар будет предложено обеспечить обособленно, см ниже – резервы «под назначение».
  • Отгрузить – команда, означающая что по данной строке заказа уже разрешена отгрузка. Например, при отгрузке только по факту оплаты – программа позволяет построчно управлять отгрузкой при получении частичной предоплаты.

Резервирование по графику («к дате отгрузки» и «требуется»)

Одной из наиболее удобных возможностей управления запасами в УТ 11 и ERP, по сравнению со старыми системами, является возможность резервирования по графику. Логика этой системы – контроль остатков по товарному календарю. Рассмотрим ситуацию – сейчас товара нет в наличии, но есть планируемые поступления по заказу поставщику. Старые системы (УТ 10.х, УПП 1.х) предлагали «разместить» заказ клиента в конкретном заказе поставщику. Но в целом ряде ситуаций такая связь может быть неудобна:

  • Если заказ поставщику отменяется, а вместо него планируется другой – нужно перепривязаться к новому заказу.
  • Если заказ поставщику опоздал, но на складе появились свободные остатки – эти остатки могут забрать для другого клиента, а клиент, оформивший заказ раньше, останется ждать задерживающегося заказа поставщику.

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

Контроль резервов по графику работает по-другому – все планируемые отгрузки и поступления товаров выстраиваются по датам в товарном календаре. И если заказ клиента запланирован с отгрузкой в определенную дату – он не привязан ни к одному конкретному поступлению, а только к плановому наличию товара на эту дату. Когда принимается новый заказ клиента – для всех существующих заказов проверяется условие:  если в предыдущую дату добавится еще одна отгрузка – хватит ли товара на дату заказа? Т.е. из какого именно заказа поставщику будет обеспечен заказ клиента – заранее неизвестно, при каждом контроле резервов контроль производится сопоставление дат на момент контроля.

Дата

Документ

Планируемое изменение

Планируемый остаток

01.11

Текущий остаток на складе

10

02.11

Заказ поставщику

50

60

03.11

Можно сделать заказ с отгрузкой в эту дату, до 30 шт.. Больше запланировать нельзя – для Заказа №2 не хватит товара

 

04.11

Заказ клиента 1

-10

50

05.11

Заказ клиента 2

-20

30

06.11

Заказ поставщику

50

80

07.11

Можно сделать заказ с отгрузкой в эту дату или любую последующую дату, до 55 шт. Больше запланировать нельзя – для Заказа №3 не хватит товара

 

08.11

Заказ клиента 3

-25

55

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

В действиях в Заказе клиента для резервирования по графику нужно использовать вариант «Резервировать к [дате отгрузки]».  Когда ожидаемые поступления еще не запланированы – указанный вариант действий будет недоступен, т.к. его указание означает для продавца гарантию наличия товара к определенной дате, при условии соблюдения графика поставок.

При отсутствии товара на складе следует указывать действие «К обеспечению». После того как поставки товаров будут запланированы – требуется вручную зайти в заказ клиента и изменить резерв на вариант «к дате отгрузки», до этого товар не будет числиться в резерве. Таким образом, при отсутствии товара на складе – конфигурация не позволяет гарантировать для продавца его наличие к определенной дате. Если в момент, когда была запланирована поставка, продавец не успел поставить резерв под свой ранее оформленный заказ – его коллега может забрать этот резерв под свой более новый заказ, действует правило «кто раньше встал, того и тапки». Таким образом, даже при гарантированных сроках поставок товаров на склад – для клиента гарантировать наличие товара к определенной дате невозможно!

Возможность поставить товар в резерв с учетом еще не запланированных поступлений, исходя из стандартных сроков поставки товаров, существовала в УТ 11.0, но потом от неё отказались ради упрощения интерфейса.

 

Надо отметить, что если компании требуется максимально сократить избыточные резервы, то даже при наличии товара на складе – следует использовать резервирование к дате отгрузки, а не резервирование со склада. В типовой конфигурации на текущий релиз (УТ 11.1.9, УП 2.0.9), при наличии товара на складе и отсутствии ожидаемых поступлений в – нельзя использовать резерв по графику, пользователю доступен только резерв со склада. Архитектурных ограничений для этого в конфигурации нет, в версиях 11.0 существовала возможность ставить резерв из графика, когда планируемых поступлений еще нет, но товар есть на текущих остатках. Эту возможность убрали ради упрощения функционала. Но если компания имеет высокий товарооборот по одной номенклатурной позиции – может быть целесообразно доработать программу и вернуть такую возможность. Стоит отметить, что частичный возврат этих возможностей из версии 11.0 – потребует значительных трудозатрат, т.к. потребуется частично переписать логику многих интерфейсов и контролей резервов.

Резервирование под «назначение» (под заказ)

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

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

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

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

Обособленное обеспечение под назначение имеет следующие принципы работы:

  • Назначение всегда формируется со стороны потребности. Т.е. нельзя запланировать поставку под какое-то назначение, пока в заказе клиента не указано, что он  должен быть обеспечен обособленно.
  • Под назначение не может быть обособленно больше товаров, чем для него необходимо.

Сценарий работы с обособленным обеспечением следующий:

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

Согласно второму принципу обособленного обеспечения: под назначение не может быть обособленно больше товаров, чем для него необходимо. Поэтому, если заказ клиента отменятся по какой-либо причине – нужно сначала отменить поставку или указать другое назначение в заказе поставщику, и только после этого программа позволит отменить заказ клиента. Данный принцип очень удобен, когда обособленно обеспечивается низколиквидный товар – что-то сделанное индивидуально под клиента, или даже типовое, но с редким спросом и купленное только ради клиента. Функционал программы заставляет сначала принять решение о том, что делать с запланированной поставкой: отменить, или положить на склад (т.е. получить неликвидный товар), и только потом позволяет зафиксировать факт отказа клиента от заказа. Т.е. в этом случае продажинку не удастся втихаря отменить заказ и принести компании убытки, в виде неликвидного товара. Если за закупки отвечает другой сотрудник – потребуется сначала договориться с ним о судьбе ненужного товара.

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

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

 

Функционал «обособленного обеспечения заказов» включается в разделе Администрирование – Закупки. Но данная функциональная опция включает только само обеспечение, для обособленного учета себестоимости по разным назначениям – нужно поставить соответствующий признак в разделе Администрирование – Финансы; при включении обособленной себестоимости – для каждого назначения товаров будет генерироваться отдельный ВидЗапасов.

Связь управления резервами с контролем оплат. Резервы и реализации

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

  • Аванс (до обеспечения)
  • Предоплата (до отгрузки)
  • Кредит (после отгрузки)

При выборе варианта оплаты «Аванс», и отсутствии соответствующей оплаты - будет невозможно установить в заказе клиента любое действие типа «К обеспечению…». Точнее, эти действия можно будет установить, но заказ будет доступен для проведения только в статусе «На согласовании», при котором никаких движений по обеспечению он еще не формирует. Таким образом, можно контролировать, что товары планируются к закупке только под те заказы, по которым уже получена предоплата.

Тут есть важный нюанс – до получения аванса программа позволяет использовать вариант резерва со склада. В этом случае, при установке резерва в одном заказе – под другой уже оплаченный заказ свободного остатка может будет не хватать.  Скорее всего, в этом случае будет принято решение о дополнительной закупке товара. Таким образом, хотя аванс от покупателя еще не поступил – его заказ вынудит нас потратить деньги на закупку товара. Если этот риск является для компании неприемлимым – требуется доработка, запрещающая резерв со склада до получения аванса от клиента.

В УТ 11 и ERP появилась возможность использования Реализации товаров как Заказа. Реализация имеет статус «К предоплате», в котором она отражает не продажу товара, а его постановку в резерв на складе. Если в документе указан обязательный процент предоплаты – перевести реализацию в статус «К отгрузке» будет невозможно до получения оплаты. В статусе «К отгрузке» товар отражается как проданный по РН ТоварыОрганизаций, но еще числится на складе, если используется ордерная схема. При отражении складского ордера – товар списывается по РН ТоварыНаСкладах.

Инструменты контроля и управления резервами

В программе реализован ряд сервисов по управлению резервами:

Функция "Заполнить обеспечение" в заказе

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

Состояние обеспечения

Для анализа ситуации с обеспечением заказов – можно использовать «Состояние обеспечение», доступное по одноименной кнопке в командной панели списка товаров в заказе клиента (на узких мониторах – см. «Все действия»).

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

Рабочее место позволяет не только контролировать текущую ситуацию, но и управлять резервами. Из рабочего места можно изменить способ резервирования товаров и перепланировать дату отгрузки, если в запланированную дату обеспечить его невозможно.

Понять весь функционал по письменному описанию невозможно, т.к. в нем много мелких сервисных возможностей. Но т.к. это ключевой инструмент продавцов по управлению резервами и их контролю, то разобраться ним лучше детальнее. Лучший способ это сделать – создать разные заказы клиентов, конкурирующие за один товар, затем усложнить ситуацию частичным наличием товара на складе, частичным наличием в ожидаемых поставках и далее нужно «поиграть» с этим инструментом, чтобы разобраться как он работает в разных комбинациях резервов.

Аналогичное рабочее место можно использовать по всем заказам сразу, см. раздел «Закупки» - «Состояние обеспечения заказов».

Подбор товаров в документы продажи

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

Отчет «Доступные для продажи товары»

Сводную картину по текущим остаткам товаров и резервов можно получить в отчете «Доступные для продажи товары». В данном отчете показываются:

  • наличие на складе,
  • товары в категории «отгружается» - товары, переданные на отгрузку, но еще не отгруженные со склада (в случае использования ордеров при отгрузке).
  • резервы товара со склада и из графика,
  • обособленные резервы под назначение
  • свободные остатки = наличие на складе минус резервы и товары к отгрузке.

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

 

 

 

Возможные проблемы с резервами

  • При выборе в заказе варианта "Требуется"- можно указать любую дату отгрузки, даже нереалистичную. Также после планирования поставки под данный заказ – его могут зарезервировать под другой заказ, т.к. очередности обеспечения заказов в статусе «требуется» нет, действует правило – «кто первый встал, того и тапки». Данная проблема решается использованием логики периода контроля из УТ 11.0
  • Контроль резервов по графику работает день в день. Т.е считается что заказ поставщику с датой поставки 20.11 будет обеспечивать заказ клиента с отгрузкой в эту же дату, хотя физически отгрузки товара могут происходить по утрам, а поступления на склад – по вечерам. Проблема решается доработкой документов обеспечения, чтобы все плановые поступления в РН ГрафикДвиженияТоваров отражались датой на один день больше.
  • В программе нет инструментов предупреждения пользователей о том, что товар уже не удастся поставить к указанной дате: если произойдет срыв поставки товаров, то продавец узнает об этом только если самостоятельно построит отчет и увидит, что в нужную дату товара в наличии не будет. Одной из крайне полезных доработок, которую мы делали на одном из внедрений, было автоматическое создание задач и писем пользователям, по заказам которых возникли проблемы из-за переноса срока поступления товара от поставщика.
  • В конфигурации отсутствует возможность запретить использовать резервы  со склада, или резервы по графику, хотя такая возможность бывает необходима.
  • Хотя этап оплаты «Аванс» подразумевает, что до аванса обеспечивать заказ нельзя – резерв со склада можно установить и без аванса.
  • Во многих компаниях бывает востребовано автоматическое снятие резервов при просрочке оплаты или отгрузки. Зависание резервом приводит к лишним закупкам товаров и снижении оборачиваемости запасов и оборотных средств. Организационно стимулировать менеджеров на своевременное закрытие заказов не очень просто, да и проблемы может быть просто в том, что они забывают отменить неактуальные резервы.
    В типовой конфигурации возможность автоматического снятия резервов пока отсутствует.
  • Отсутствие полной информации о других заказах клиентов и плановой даты поступления товара на склад – снижает удобство обработки «Подбор товаров». Часто бывает полезным её доработать соответствуюим образом.
  • Регистры учета резервов не имеют разреза «Организации», если продавать товары нужно строго с определенной организации, но владеет им другая организация – о невозможности продать товар от имени желаемой организации программа сообщит только при проведении документа продажи.

Особые случаи использования резервов. Резервы по сериям 

Одним из особых случаев управления резервами является резервирование с учетом серий.

Учет серий удобно использовать для различия физически различающихся товаров, даже если производитель не делит их по сериям. Например, компания торгующая кабелем может иметь на остатках бухты кабеля разной длины. Потенциальный клиент, заказывая 50 метров кабеля будет ожидать, что ему дадут этот кабель единым куском, а не обрезками по 20 и 30 метров. Таким образом, для подобных товаров необходимо хранить информацию об остатке кабеля в каждой бухте. Для этого каждую бухту можно обозначить отдельной серией и учитывать остатки товаров в разрезе серий, т.е. остатки кабеля в каждой бухте. При получения заказа от клиента – достаточно будет найти единственную серию достаточной для клиента длины и предложить её.

Аналогичный принцип учета по сериям может применяться для кабелей, тканей, веревок и т.п.

Похожий принцип может использоваться для обоев и красок. Хотя их обычно продают полными рулонами и полными ведрами (для краски), но в разных сериях может незначительно отличаться цветовой оттенок. Чтобы гарантировано продать клиенту товары с одним оттенком – разные партии рекомендуется обозначать отдельными сериями и отпускать клиенту товары только одной серии.

Возможности по резервированию конкретных серий в программе ограничены. Резерв по сериям можно сделать только из текущих складских остатков. Для случаев, когда серии имеют физические различия (например, разные оттенки цвета) это может являться ограничением, если какая-то серия, продававшаяся ранее или имеющаяся на остатках, еще раз придет в одном из планируемых поступлений. Однако, когда деление товара на серии производится только для учета длины – подобных резервов скорее всего будет вполне достаточно, т.к. в планируемых поставках мы всегда ожидаем получить полные бухты кабелей, а не их обрезков, т.е. учитываться их с той же детализацией, с которой учитываются складские остатки, нет необходимости. Если всё же необходимо под конкретного клиента зарезервировать конкретную ожидаемую поставку – вместо резервов по сериям можно воспользоваться обособленным обеспечением по назначениям, и привязать будущую поставку к конкретному заказу клиента.

См. также

Подписаться Добавить вознаграждение
Комментарии
1. Александр Шалимов (shalimski) 26.11.14 04:00
Большое спасибо вам за статью!
2. юрий гулидов (gull22) 26.11.14 10:07
Спасибо за информацию. Плюс.
3. vtolga (vtolga) 26.11.14 11:41
Огромное спасибо, будет очень полезно.
4. Алексей Роза (DoctorRoza) 26.11.14 13:42
Спасибо, хорошая статья!
SunShinne; +1 Ответить
5. DAnry (DAnry) 26.11.14 13:51
Статья хорошая для общего ознакомления с системой управления резервами. В теории выглядит все красиво. Но на практике приходится сталкиваться с "человеческим фактором", когда такая "академическая" статья не поможет. Например у меня был случай: торговая фирма занимающаяся в основном оптовыми и мелкооптовыми продажами. Клиенты разделены между менеджерами по продажам. Менеджеры "на проценте" от дохода от продаж. Конечно есть ходовой товар и товар, который продаётся плохо. При поступлении ходового товара менеджеры сразу (один перед другим) резервируют его своим клиентам, даже если реально заказы ещё не поступали, и держат сколько можна. В результате свободный остаток 0, хотя товар на складе в наличии. Сначала установили параметр "держать в резерве не больше Х дней". Не помогло. По истечении срока менеджеры просто "перерезервировали" (простите за каламбур) резерв. Не буду перечислять другие "программные" механизмы, которыми пробовали решить проблему. Помогла простая беседа, точнее мужской разговор по душам.
olexich; aesafonov; ogre2007; +3 Ответить 2
6. Денис Соломасов (Denis S) 26.11.14 14:29
Спасибо за хорошую статью! Очень пригодилось!
7. Руслан Ястребов (ruslan88) 26.11.14 15:22
Хорошая статья! Будет полезно.
8. unknown unknown (unknownN) 26.11.14 15:58
Весьма интересно, благодарю.
9. Марк Воронов (yam) 26.11.14 16:03
Отличная статья, все очень грамотно разъяснено. Спасибо!
10. 22 2233 (losara1983) 27.11.14 21:47
Супер разжевали, спасибо!
11. Neo. (Neo.) 30.11.14 04:25
Спасибо за статью.

(5) DAnry, мы поступили таким образом. Менеджер оформляет заказ покупателя. Документ резервирует товар на складе или размещает в заказах поставщику по одному из условий: заказ полностью оплачен, покупатель является VIP, под ответственность начальника отдела. При поступлении товара на склад, он резервируется за покупателем на N дней. Если товар не забран в течении этого периода, то резерв снимается. Самостоятельное резервирование запрещено всем, кроме начальника отдела. Есть нюансы когда именно происходит резерв (проведение документов оплаты или заказа покупателя) и размещение (заказ поставщику ещё может не существовать), сколько держать товар в резерве, снимать ли с него, но это уже особенности фирмы.
12. Сергей (Che) Коцюра (CheBurator) 03.12.14 03:37
Спасибо
Хорошая статья для вводного обзорного ознакомления
Почерпнул полезного

Вызывает сомнение адекватность для менеджеров имеющихся инструментов по выставлению видов резервирования в заказах и их управлением
Если пару заказов на пару строк то возможно ок
Если в день несколько дестков заказов по несколько стоен строк тире все должно делатьс както на автомате с использованием какихто политик или регламентов
И вот здесь начинаютс сомнени в адекватности типово конигурации
13. Олег Демиденко (FFelix) 03.12.14 10:23
(12) CheBurator, Я не понял какой вариант обеспечения именно вас смущает - "по графику" или "по назначению", где вы уже жестко связываете заказы.
В обоих вариантах заказы поставщикам могут быть сформированы автоматически с помощью инструмента "формирования заказа по потребностям" (в меню создания заказов поставщикам).
А в целом такие инструменты управления уже показали свою эффективность:
Обособленно обеспечиваемые заказы (под назначение) используются там, когда менеджеру нужно запретить отказываться от заказанного товара. Например, когда он продает клиенту редкий товар. Единственная необходимая доработка на внедрении - для таких товаров следует запретить указывать другие варианты.
Резервы по графику (из других заказов, но необособленно) - помогают сэкономить на оборотных запасах.
Инструмента, которого не хватает в типовой сильно - это запретить использовать определенные способы резервирования для определенных товаров; один из примеров я выше указал. В остальном, принципиально все вместе варианты резервирования позволяют реализовать практически любой режим работы.
14. Валентин Будкин (vabue) 18.12.14 00:44
Скажите, Олег, а по проблемам с резервами, озвученными вами в статье — стоит ли надеятся на решение их 1С в процессе развития типовой?

Или не рассчитывать на это, а ломать типовой механизм своими велосипедами?
15. Олег Демиденко (FFelix) 18.12.14 19:18
(14) vabue, вы спросили конечно...
Думаю, с закрытием заказов с просроченной отгрузкой/оплатой - когда-нибудь в типовой решат. Также когда-нибудь решат проблему попадания в один день поставок и отгрузок.
Вопрос - когда. Может быть в течение года, а может быть и дольше придется ждать. Имеет смысл просить разработчиков на форуме partners.v8.1c.ru
Если просить о чем-то будут чаще - есть небольшой шанс, что это сделают быстрее.
Но в целом, если решение обязательно нужно в ближайшие полгода - надо делать самому.
16. sergey_irk sh (sergey_irk) 19.12.14 00:49
Спасибочки! Статья понравилась особенно для обзорного ознакомления. Кое что почерпнул для себя.
17. Андрей Вовк (wowkai) 11.01.15 20:32
Изучаю УТ11 и почти с каждым обновлениям у них что-то меняется в системе резервирования товаров.
Спасибо за статью!
18. Сергей Сергеев (Рамзес) 15.01.15 11:21
Спасибо за подробное и понятное изложение функционала резервирования и возможных сценариев его применения. Очень полезно!
19. grayshadow grayshadow (grayshadow) 13.02.15 07:16
Вопрос по резервированию серий - не получается заюзать одновременно серии и назначения. Делаем заказ клиента, обеспечиваем обособленно. Закупаем товар, в ПТУ раскидываем поступившие серии по назначениям, в регистре ОбеспечениеЗаказов все списывается как надо. Заходим в заказ клиента, чтобы сделать долгожданную отгрузку, жмем кнопку Состояние обеспечения, все обеспечиваем... - и хрен нам, в ТЧ заказа серии не проставились, надо их снова указывать вручную. Кому-нибудь удавалось это победить?
20. Александр Мумладзе (agmumladze@gmail.com) 01.04.15 19:05
Добрый день.
Очень толковая статья!
С тех пор, как 1С перевернула все резервирование и поставила его с ног на голову, не мог найти ничего толкового.
На ИТС только вопросы и ответы, из которых приходится по крупицам собирать то, что здесь изложено просто и понятно!
От ИТС (Рарус) не добился никакого ответа, кроме присылания мне документации 2011 года с описанием старой системы резервирования и обеспечения заказов.
21. Maxim Kolkin (the1) 02.04.15 00:11
В последнем релизе (11.1.10.111) отчет "Доступные для продажи товары" числится как неиспользуемый и исключен из интерфейса.
Для интереса сравнил показатели этого отчета и "Остатки и доступность товаров", различается существенно, причем заметно, что 1-й отчет врет.

Какой посоветуете на замену с функционалом не ниже?
Нужны показатели
    Реальный остаток
    Зарезервировано
    Свободно для продажи
    Заказано у поставщика
    Требуется заказать
22. deevil deevil (deevil) 07.04.15 13:15
В статье не описаны ситуации, которые вызывают много вопросов:
1. если товара нет и нет плановых поставок. то ставим статус к обеспечению. Затем когда товар приехал он ведь не ставится автоматом в резерв.
2. обособленное обеспечение при работе с сериями подразумевает что отгрузить клиенту нужно туже серию.

Какие есть варианты решить эти моменты?
23. Олег Демиденко (FFelix) 08.04.15 22:31
(21) the1, Этот отчет был просто переименован, на сколько мне известно. Ищите аналогичный с другим названием.
24. Дмитрий Дорин (DmitriyDI) 09.04.15 12:41
(22) deevil, тут же написано, открываем обработку "Состояния обеспечения заказов", и ждем товар пришел, резервируем, кто успел тот молодец) или я так понимаю пользоваться обособленным обеспечением, но минусы описаны в статье
25. Lumis 10.04.15 17:49
У меня возникает странная ситуация с обеспечениями в заказах. Есть один и тот же товар на двух разных складах. На одном в количестве 5 штук, на другом в количестве 20 штук. При подборе менеджер указывает количество 15 штук, и сразу выбирает нужный ему склад (там, где есть 20 штук). Но после кнопки заполнить обеспечение, строчка делится на две, списывается весь остаток со склада, где есть 5 штук и 10 берется со склада, где есть 20 штук. Этого можно как-то избежать?
26. Олег Демиденко (FFelix) 11.04.15 01:08
(24) DmitriyDI, прошу обратить внимание - статья немного устарела. 1С объявили на мартовском семинаре о возможности обособленно обеспечивать количество большее, чем указано в потребности. Далее цитирую 1С:
В результате появляются следующие возможности:
    схема: заказ клиента - заказ поставщику - отмена заказа клиента (раньше контроль не позволял отменить заказ клиента);
    округление заказа поставщику на обособленный товар до упаковок. После прихода товара и отгрузки клиенту остаток можно разобособить документом корректировка назначения;
    свободное перемещение обособленного товара внутри предприятия;
    cхема: заказ клиента на склад отгрузки - заказ поставщику по потребностям склада отгрузки сразу на центральный склад - поступление на центральный склад - перемещение на склад отгрузки (раньше обязательно требовался заказ на перемещение иначе не возникало потребности на центральном складе).
27. Дмитрий Дорин (DmitriyDI) 14.04.15 17:00
(26) FFelix, очень понравилась ваша статья.
28. Михаил Ефименко (942644) 16.06.15 15:16
Спасибо за статью, есть полезная инфа
Есть описка "продажинку " вместо "продажнику"
В скриншоте Отчета доступности несоответствие с тем что в тексте про этот отчет
Написано "свободные остатки = наличие на складе минус резервы и товары к отгрузке." , тогда по артикулу СТ-910 свободно для продажи должно быть три, а на скриншоте ноль



29. Dim Dragonim (Dragonim) 25.08.15 14:16
(5) DAnry, Это называется "Решать административную проблему техническими средствами", ни чего хорошего от такого решения не ждите. Когда столкнулись с такой же проблемой порекомендовали начальнику отдела продаж удерживать процент стоимости товара с менеджеров, объясняя это тем что за купленный товар оплачены деньги и они не в обороте, а сам товар дорожает пролёживая на складе. Половина желающих резервировать без договорённости отпала, а для другой ввели обязательное указание причины отмены (есть такой столбец в заказе). В итоге желающие резервировать "на всякий случай" исчезли.
30. Евгений Ланкастер (JoeLan) 12.10.15 04:00
(26) FFelix,
=====
cхема: заказ клиента на склад отгрузки - заказ поставщику по потребностям склада отгрузки сразу на центральный склад - поступление на центральный склад - перемещение на склад отгрузки (раньше обязательно требовался заказ на перемещение иначе не возникало потребности на центральном складе).
=====
немного не понял, как работает. Т.е. как в заказе поставщику автоматически проставится центральный склад, а не склад отгрузки?
31. Мария Г (marivgo) 12.12.15 23:34
Это самое лучшее описание работы с резервами в ERP, которое мне когда-либо встречалось. Спасибо! Помогло обобщить уже имеющиеся знания.
32. Vadim Петров (Vadim75) 18.12.15 11:52
Плюсую. Не видел еще похожих статей по резервированию с таким количеством изложенной информации. Недостаток в иллюстрациях и сквозном примере, но думаю на приктике получится понять изложенные нюансы.
33. Сергей (Che) Коцюра (CheBurator) 19.12.15 04:22
Спасибо за статью!
Може ли автор подсказать неулевику в УТ11 что-то по:

Есть ли в УТ11 что-то, реализующее тем или иным способом штатно такую возможность:
1. есть некое количество товара, которое отложено "в сторону" - назовем это "обобщенный резерв" и недоступное для свободной продажи менеджерами (суть = запасы, отложенные под потребности сетей)
2. некая совокупность клиентов (отмаркированных неким свойсвтвом? признаком? лежащая в отдельной группе и ее подгруппах - это совсем на крайний случай)
3. При оформлении резерва на товар (заявка на склад) такие клиенты в первую очередь забирают запасы из свободной продажи, при нехватке товара в свободной продаже !автоматом! добирают нужное количество из "обобщенного резерва"
4. при необходимости товар из "обобщенного резерва" может быть переведен в свободную продажу вручную в произвольном составе.
4а. При необходимости товар из "обобщенного резерва" м.б. переведен под резерв конкретной заявки произвольного клиента вручную в произвольном составе (для обеспечения обычных клиентов из "обощенного резерва" по решению ответсвенного менеджера)
5. "обобщенный резерв" описывается неким "минимальным остатком" по каждой номенклатуре (по статистике отгрузок на сети)
6. При любом поступлении товара если обобщенный резерв меньше минимального остатка - товар из свободной продажи автоматом откидывается в "обобщенный резерв" до требуемого количества.
.
фактически склад - один, фирма - одна. Образовывать виртуальные склады/фирмы - не запрещено. Сейчас на клюшках такая схема у меня работает совершенно прозрачно, менеджеры даже не задумываются (в т.ч. и при подгрузке электронных заявок). Хочется не изобретать/писать все это заново.

Спасибо
34. Олег Демиденко (FFelix) 28.12.15 22:05
(33) CheBurator, Можно этот "обобщенный резерв" реализовать через резерв под направление деятельности, появившийся в ERP 2.1.3 (УТ 11.2.3 должна быть). Но пункты 3,5,6 так не реализуются