Вопрос пользователя: «Я перебросил резерв с заказа А на заказ Б. Хорошо, заказ Б теперь «В резерве». А что стало с заказом А? Он «сломался»? Как система с ним поступит?»
Суть проблемы
Пользователь, совершив операцию переброски, беспокоится о судьбе исходных заказов. Не приведет ли его решительное действие к хаосу: появлению новых «синих» строк, о которых он забудет, и срыву сроков у других клиентов? Нужно понимать последствия, чтобы управлять ими.
Что может 1С ERP?
Система автоматически пересчитывает состояние заказов, у которых был изменен резерв, по четким правилам. Она не оставляет их «висеть» в неопределенности, а приводит в соответствие с новой реальностью.
Суть подхода:
После переброски резерва система выполняет следующие действия:
- В целевом заказе (который получил резерв): На зарезервированное количество устанавливается или меняется действие на «Резервировать на складе». Это жесткое резервирование существующего остатка.
- В заказах-«донорах» (у которых резерв забрали):
Если у них было действие «Резервировать на складе», то на переброшенное количество оно меняется на «Резервировать по мере поступления». То есть жесткий резерв превращается в план обеспечения из будущих поступлений.
Если у них было действие «Резервировать по мере поступления», оно остается без изменений, но система автоматически перераспределяет для них запасы заново, согласно общим правилам (по приоритету и дате). - Автоматический пересчет: Для заказов-«доноров» система заново запускает алгоритм распределения запасов. Если для них найдутся другие свободные остатки или ожидаемые поступления, они будут обеспечены. Если нет – их статус изменится на «Обеспечить» (синяя строка), что станет сигналом для менеджера о новой возникшей проблеме.
Преимущества подхода:
- Автоматизация рутины: Пользователю не нужно вручную исправлять действия в заказах-«донорах».
- Соблюдение правил: Система возвращает заказы в общий контур планирования, где они конкурируют за ресурсы по установленным в компании правилам.
- Прозрачность: Последствия операции сразу видны: либо заказ-«донор» нашел новое обеспечение, либо он стал новой точкой контроля (статус «Обеспечить»).
Решение и рекомендации
- Всегда проверяйте последствия. После переброски резерва обязательно посмотрите, что стало с исходными заказами. Возможно, для них теперь тоже нужно искать решение.
- Используйте приоритеты. При ручном выборе «доноров» отдавайте предпочтение заказам с низким приоритетом или более поздней датой отгрузки – у системы будет больше шансов найти для них альтернативное обеспечение без вашего участия.
- Не бойтесь синих строк. Появление статуса «Обеспечить» у заказа-«донора» – это не ошибка, а корректный сигнал о том, что потребность стала неудовлетворенной и требует внимания. Это лучше, чем неверные данные о резервах.
Итог простыми словам
Представьте, что вы пересадили цветок из горшка А в горшок Б. Система не оставляет горшок А пустым. Она автоматически проверяет свои запасы: есть ли у нее на складе другой подходящий цветок или семена? Если есть – сажает новый цветок в горшок А. Если нет – ставит на горшок А табличку «Требуется посадка» (статус «Обеспечить»), чтобы садовник (менеджер) это увидел и принял меры. Таким образом, управление одним кризисом может создать новый, но контролируемый, сигнал.
Типичные сценарии использования:
- Сценарий 1: Переброска с «жесткого» резерва. С заказа №1 (действие «Резервировать на складе») сняли 5 шт. для заказа №2. В заказе №1 действие на эти 5 шт. поменялось на «Резервировать по мере поступления». Система тут же попыталась найти для этих 5 шт. новое обеспечение (например, в ожидаемой поставке). Если не нашла – статус заказа №1 частично стал «Обеспечить».
- Сценарий 2: Переброска между «гибкими» заказами. Резерв перебросили с заказа №3, где стояло «Резервировать по мере поступления». Действие в заказе №3 не изменилось, но система пересчитала его обеспечение. Возможно, он был привязан к поставке X, а теперь перепривяжется к более поздней поставке Y, что автоматически отодвинет его дату обеспечения.