Mallika Sagar Senior Software Engineer. 20 Feb Node Capacity IBM Corporation

Transcription

1 Mallika Sagar Senior Software Engineer 20 Feb 2014 Node Capacity

2 Agenda Understand the requirement for Node Capacity Assumptions and Limitations Overview of design UI changes Configuration Involved Few Examples Database Changes Properties introduced APIs used Demo 2

3 Requirement This feature enables business users, store managers or store associates to source items from a node based on its available capacity (if it has not reached its quota of units) when there are multiple nodes or distribution centers. Once the node capacity is reached, other distribution centers are considered for sourcing even if they are not optimal sources. A node can be marked as ineligible for a day to prevent overloading. Benefits Distribution centers are not overloaded since a distribution center is considered for sourcing only when it has not reached its quota of units (pick, pack, ship). Optimally utilizes the workforce while meeting the customer service goal, thereby reducing the cost of idling workforce, if any. 3

4 Assumptions and Limitations We will not differentiate orders with different fulfillment options (direct to consumer vs pick up from store) or carrier service level (overnight, standard) in factoring node capacity. All will be considered a pick unit. Quantity for an order will not be split across days due to capacity availability. A day with enough capacity will be chosen. Time zones will not play a role in inventory capacity as capacity is maintained at a date level. IBA ignores capacity No UOM conversions will occur. 4

5 Design Overview Using existing resource pool tables, inventory managers will be able to define their own resource pools to configure how many UNITs can be processed a day or how many releases can be processed a day. When availability is checked for a particular day, the number of units already against that node on that day will be considered. If inventory has met capacity, then inventory will not be available on that date. Instead, it may be available the following day or even at another node. To enable node capacity at a node, a resource pool should be created for the node with Purpose as INVENTORY. Standard capacity can be defined which will represent how much demand is allowed per day of the week. The time components will be 00:00 23:59 for PROD based resource pools. When an API determines the dates for which to consume, consumption records will be made against the necessary nodes, resource pools, and dates. 5

6 Configuration Required Switch to the Node being used 6

7 Under Inventory, select Manage Node Capacity 7

8 Select the Capacity UOM 8

9 Select the period for which capacity needs to be set 9

10 Add capacity for respective days of the week 10

11 From the Related Tasks, select Weekly Capacity 11

12 This shows the capacity details for the current week 12

13 Created an order for 3 qty and scheduled it against inode, capacity consumption gets updated 13

14 UI Changes Sourcing Template 14

15 UI Changes contd.. Sourcing Template 15

16 When based on Order Releases During schedule, consumption will be created per unique release determined by scheduleorder. At this point in time, release consolidation template is used to determine the unique releases. Consumption quantities will be based on the unique releases that scheduling is processing. When backordering or cancelling quantity, the release consolidation template for that order will be used to determine the calculated releases for the order. If after cancellation or backorder, this number has changed, then the consumption will be updated accordingly. 16

17 Ex1: Usage with Gift Flag Assume an order is created for three items (ITEM1, ITEM2, and ITEM3), where ITEM1 is a gift (aka GiftFlag=Y). Upon scheduling the order, consumption records should be as follows: Resource Pool Qty Date OHKey ORKey SN OH1 Null The order line schedules will look as follows: OrderLineKey ShipNode Expected Ship Date OL1 SN OL2 SN OL3 SN When cancelling line OL3, consumptions in the DB will remain. The release consolidation template will be used to determine if the line being canceled belongs to any other line s release. Only after cancelling OL2 will the consumption picture look as follows: Node Qty Date OHKey ORKey SN OH1 Null 17

18 Ex 2: Affect on availability Assume the following supply picture for an item: Quantity Supply Type ETA 150 ONHAND PO_PLACED PO_PLACED Assume the following demand picture for an item: Quantity Demand Type Demand Ship Date 50 SCHEDULED Due to the above demand, consumption for 50 exists for this node on Below is how much quantity that can be fulfilled for each date: Date Std. Capacity Available Quantity In case the resource pool is configured based on number of releases, inventory will not be available on days that are full. 18

19 Ex 3: Qty will not be split across days due to insufficient capacity Assume the following inventory and capacity picture where consumption is based on UNITs: Date Item Node Supply Demand Capacity Consumptio n ITEM1 SN ITEM1 SN If asking for 2 quantity, the only option would be to ship on the 2 nd for the quantity. The quantity will not be split across two days. 19

20 Ex 4: Scheduling Optimization - Given Factor as 1 and the flag enabled, when determining between shipping a product between the following two nodes: Node Percentage Capacity Used Calculated Cost N1 58/1000 = 5.8% 5.8 N2 955/1000 = 95.5% 95.5 Here, N1 s cost is cheaper than N2 s. Cost of the assignment will be based on the capacity available per date. An assignment is originally generated with a date range. When comparing two assignments to determine the best one to use during costing, the cost will be based on the lowest consumption percentage. - Assume the following inventory picture: %Capacity Used 11/1/ /2/ /3/2010 N1 58/1000 = 5.8% 50/1000 = 5% 100/1000 = 10% N2 955/1000 = 95.5% 0/1000 = 0% 10/1000 = 1% Available Supply N1 = 942 N2 = 45 N1 = 950 N2 = 1000 N1 = 900 N2 = 990 When optimizing on cost, the best option will be to ship from N2 on 11/2/2010 due to its low cost. 20

21 Sourcing Nodes Based On Capacity Sourcing rule details can be configured to only include nodes that have a certain level of capacity availability. This will be allowed for both shipping and procurement rules. In addition, the number of days to consider for the available capacity percentage can be provided. If provided, the minimum available capacity will be used to determine percentage. If not specified, then all days being considered for inventory (future inventory window) will be used. 21

22 Ex 5: Usage of percentage set in sourcing template Given that the sourcing rule detail has defined the percentage to be 20% and the given capacity availability exists between the nodes. Node Consumed Capacity Avail % N % N % N % N % When scheduling an order, the order will be scheduled against N3. This will continue until all nodes reach this 20% capacity availability. If none of the nodes have 20% available capacity, then the next sourcing rule detail will be read. 22

23 Ex 5: Usage of percentage set in sourcing template(contd..) Assume the following sourcing rules Consider only ONHAND inventory for N1 N4 whose capacity available is > 20%. Consider all inventory from V1 Consider all inventory from N1 N4 whose capacity available is > 20%. Consider all inventory from N1 N4. Assume the following inventory picture and capacity: Node Onhand Supply N /10 9/10 8/10 7/10 N /10 8/10 8/10 8/10 N /10 8/10 8/10 8/10 N /10 8/10 8/10 8/10 V1 1 When scheduling an order for 1 quantity, N4 will be selected and consumption will be placed for today s date. Upon placing another order for the item and scheduling, inventory is not available at N1 N4 for today s date. Therefore, V1 will be used on that order for today s date. Placing another order for the item and scheduling, inventory is not available due to capacity for N1 N4 for today s date. Inventory is not available at V1. The only node with more than 80% available capacity is N1, so N1 will be used with a ship date of

24 Few Other Notes When a node doesn t have enough inventory and needs to procure inventory from another node, consumption will be made against the procurement node and not the ship node. Node Capacity will get released on Reservation expiration only after execution of Inventory Reservation Purge Agent. 24

25 Capacity Locking If node capacity locking is enabled via the yfs.nodecapacity.lock property, the following sequence takes place: 1. Each capacity check determines whether capacity is below a threshold specified with the yfs.nodecapacity.threshold property. 2. If node capacity is above the threshold, locking is not performed for the desired resource pool and date. If node capacity is below the threshold, then future availability checks will require locking before checking availability. This notifies all other threads for this resource pool and date that a lock is required. 3. Subsequent availability checks will await the lock for the timeout interval specified in the yfs.nodecapacity.timeout property. 4. If this interval expires, the availability check assumes that there is no capacity available and reverts to whatever sourcing and inventory logic is already configured 25

26 Ex 6: Capacity Locking Assume the following capacity and consumption picture for an item at a node. Also, locking threshold is set to 10%. Date Std. Capacity Consumption When scheduling an order for one quantity, an object lock record will not be inserted as the availability check revealed 89% consumed. The following will be the capacity picture: Date Std. Capacity Consumption When scheduling another order for one quantity, availability will be checked and it will be observed that capacity has reached 90%. At this point in time, an object lock record will be inserted for this resource pool for However, it will not be locked. This order will go through as normal and get scheduled: Date Std. Capacity Consumption

27 Ex 6: Capacity Locking contd.. When scheduling an order for 9 quantity, the object lock record will be locked. Availability will be performed on that date, and the order will be scheduled. Date Std. Capacity Consumption When scheduling an order for 1 quantity, the object lock record will be locked. Availability will be performed on that date and determined that the object lock can be removed. Thus, it will be removed. The order will get scheduled as usual and the cycle will repeat for the next date. Date Std. Capacity Consumption

28 Database Changes for Node Capacity Table Name: YFS_RES_POOL_CONSMPTN_DTLS (exists) FIELD_NAME Data Type Requirement Comment ORDER_RELEASE_KEY NCHAR(24) A reference to the order release for which this consumption details record was made. Only applicable for inventory capacity resource pools. Table Name: YFS_SOURCING_CONFIG (exists) FIELD_NAME Data Type Requirement Comment CONSMPTN_PE RC_COST_FACT OR Number(14,4 ) The factor to apply to consumed capacity percentage to determine the cost of shipping from a node. CONSMPTN_PE RC_COST_CURR ENCY NVARCHAR(2 0) The currency to use when converting consumption percentage into cost. 28

29 Database Changes for Node Capacity contd Table Name: YFS_ORDER_LINE_SRC_CNTRL (exists) FIELD_NAME Data Type Requirement Comment SUPPRESS_NOD NCHAR(1) If set to Y, inventory node E_CAPACITY capacity will not be used to determine availability of this line for this node. 29

30 Property File Changes Action Property Name Description Valid Settings Add Yfs.nodecapacity.lock Determines whether Y or N locking should be enabled or not. Add Yfs.nodecapacity.threshold The availability threshold in percentage before beginning to lock for availability checks. Add Yfs.nodecapacity.timeout The amount of time in Integer seconds before giving up on the lock and assuming it is unavailable. 0 means wait indefinitely. 30

31 APIs Used managesourcingrule The new configuration attributes will be exposed in this API. AvailableCapacityPercentage: Determines the amount of available capacity is required within the DaysToConsiderAvailableCapacityPercentage before considering any nodes in this sourcing rule detail. DaysToConsiderAvailableCapacityPercentage: The number of days to consider for available capacity percentage. If not set, all days considered for inventory will be used. This is recommended to be set due to performance. Input & Output XML <SourcingRuleHeader> <SourcingRuleDetails> <SourcingRuleDetail FutureInventoryWindow= > <SourcingTemplate> <AdditionalData ExpandToMinimizeNumOfShipments="" IdleAsset="" Radius="" RadiusUOM="" AvailableCapacityPercentage= DaysToConsiderAvailableCapacityPercentage= /> </SourcingTemplate> </SourcingRuleDetail> </SourcingRuleDetails> </SourcingRuleHeader> 31

32 APIs Used contd.. createresourcepool A new Purpose will be allowed to be used. If this purpose is INVENTORY, then the following validations will be performed. ItemGroupCode= PROD ProvidesAllServices= Y AllRegionsServiced= Y CapacityMaintainAtResourceLevel= N CapacityUnitOfMeasure is either RELEASE or UNIT Node is passed CapacityOrganizationCode is passed. ServiceSlotGroupId not passed. The following defaulting will occur if Purpose= INVENTORY. ResourcePoolDescription if not passed will be the shipnode s description. ResourcePoolId if not passed will be the shipnode s key. Adjusting standard capacity will assume 00:00 and 23:59 as the StartTime and EndTime respectively. 32

33 APIs Used contd.. changeresourcepool When adjusting standard capacity, 00:00 and 23:59 will be defaulted for StartTime and EndTime respectively for resource pools with Purpose= INVENTORY. managecapacityreservation CapacityConsumption will default StartTime and EndTime as 00:00 and 23:59 respectively for resource pools with Purpose= INVENTORY. overrideresourcepoolcapacity StartTime and EndTime will default to 00:00 and 23:59 respectively for INVENTORY purpose resource pools. getresourcepoolconsumptiondetailslist <ConsumptionDetailList> <ConsumptionDetail OrderReleaseKey= > <CapacityConsumption ConsumptionDate= EndTime= StartTime= /> </ConsumptionDetail> </ConsumptionDetailList> reserveavailableinventory Upon reservation in order release mode, each individual reservation ID will be considered its own release until that is placed against an order 33

34 APIs Used contd.. cancelreservation This API will remove or adjust the associated consumption. createorder, changeorder, getorderlist, getorderdetails (output XML) Input & Output XML <Order > <OrderLines> <OrderLine> <OrderLineSourcingControls> <OrderLineSourcingCntrl SuppressNodeCapacity= N Y /> </OrderLineSourcingControls> </OrderLine> </OrderLines> </Order> 34

35 APIs Used contd.. getpossibleschedules, getworkorderappointmentoptions, getfulfillmentoptionsforlines, createworkorder, modifyworkorder, scheduleorder, releaseorder These APIs will be enhanced to check availability using the SuppressNodeCapacity flag. createworkorder, modifyworkorder, managecapacityreservation, scheduleorder, releaseorder, createchainedorder, changeshipment(events) CAPACITY_CHANGE.ON_CAPACITY_FILLED This event will be raised whenever capacity consumption fills standard capacity for a day. CAPACITY_CHANGE.ON_CONSUMPTION_FREED This event will be raised whenever consumption that previously filled standard capacity is removed and makes capacity available. 35

36 Item Based Allocation When IBA creates order line reservations, then consumptions will be updated accordingly. IBA will not consider available capacity when reshuffling demands. Scheduling will determine the dates to be used. OrderLineReservations created by IBA will have the IBA_APPROVED flag set to Y. These order line reservations will not create consumptions in the DB. However, negative order line reservations will reduce consumptions accordingly. So, any future consumptions will be removed and during rescheduling, the correct consumptions will be made for the order. 36

37 Q & A 37