Planning Scenario Determination
It is possible to determine the planning scenario base on the order type and hierarchy data.
Planning scenario determination (1)
Maintain your order types and planning scenarios.
Planning scenario determination (2)
Overloading Profile Definition and Determination
In the definition of the Overloading Profile we can specify in addition, if the resources are supposed (because of the Overloading Profile) to work during weekends or holidays (additional checkboxes in the definition of the Overloading Profile),
In the definition of SRS Document Type we can specify when (if) the Overloading Profile is to be cleared in the SRS Demand data. We can also specify when (under which circumstances) the Overloading Profile should be determined.
Table below describes (using the use cases approach) what are the new functions:
| Activity | Result |
|---|---|
We prepare the following workers:
So far we do not do anything with Overloading Profile. |
Please notice, that in total we have 250 % of the resource Worker *. |
We setup the procedure to perform the allocation on the Worker * level. We create the first order. | We have in average 83% of Worker *: (calculated as (100% + 50% + 100%) / 3 = 83%). The resource Worker * has been consumed with the percentage of 83%. Thereby the task, which normally takes 2 h now is assigned for 2 h 30 min:
Note: Please notice, that this is a change of the logic compared to the previous releases. Previously the logic was “We have 250%, so it means, that we have at least 100%, so we consume 100%). Since 19.11 we consume the average availability, in this case 83%. |
We create next 2 orders | All 3 order have been allocated in the same way:
We have consumed fully the capacity of Worker * in the time 08:00 – 10:30.
|
We deallocate previous orders. We change the availability of KAM_WORKER01 from 100% to 150%. We switch the planning procedure – we allocate on the given Worker level (not on the Worker * level). We create the first order. | KAM_WORKER01 wins – because his performance is 150%, he will do the 2h job in 1 h 30 min (08:00 – 09:30):
|
We create next order. | KAM_WORKER03 wins – he will do the job in 2 h (08:00 – 10:00):
|
We create next order. | KAM_WORKER01 wins – he will do the job in 1 h 30 min (09:30 – 11:00):
Please notice, that KAM_WORKER03 is still available and he is still without work – because of his low performance. |
We create next order. | Finally KAM_WORKER02 gets something to do. Because he is available at 50%, he needs 4 hours to do the job, which normally needs 2 h. He has received this job because there is nobody, who could do this job faster. The allocations are now the following: |
We deallocate all the previous orders. We create next order. We set KAM_WORKER03 as the preferred resource. We allocate it. | KAM_WORKER03 gets the job (although KAM_WORKER01 would be faster). The duration of this allocation is 2 h:
|
We change the allocation to KAM_WORKER01 (we use “with rescheduling” option). | KAM_WORKER01 gets the job, the duration is changed automatically to 1h 30 min: (if we used drag & drop to KAM_WORKER02, the duration would be changed to 4 h) |
We start to play with Overloading Profile. We configure the determination and clearing of Working Profile. | We use new fields of SRS Order Type: We specify the Overloading Profile determination to take place always, whenever the SRS Demand gets allocated. The Overloading Profile will be redetermined as well each time, when the SRS Demand gets allocated (regardless if the Demand is already allocated or the Overloading Profile has already been determined (set)). We can have the following values, as far as the determination is concerned: We specify the Overloading Profile clearing to take place, whenever the demand gets deallocated. We can have the following values, as far as the clearing is concerned: The Overloading Profile is determined using Lean Condition technique. The following fields are taken into consideration: Field - Description CAPPL - Calling Application HIERARCHY_ID - Hierarchy ID BUKRS - Company Code VKORG - Sales Organization WERKS - Plant VTWEG - Distribution Channel SPART - Division WPO_DOC_TYPE - Document Type ORDER_TYPE - Order Type PLAN_SCENARIO - Plan Scenario PARTNER - Business Partner Number CUSTOMER - Customer Number MAKE_CODE - Make Code MODEL_CODE - Model Code DEMAND_TYPE - Demand Type
ON_OVERLOAD_PROF_DET_01 - Determine the Overloading Profile ON_OVERLOAD_PROF_DET_02 - Influence Overloading Profile Determination – change Lean Condition Communication Structure fields |
Add Comment