Professional Documents
Culture Documents
Dates:OrderDate
Date on which the sales order is entered. System proposes the current date by default.
Material AvailabilityDate
The date on which the material must be available. On the material availability date, the vendor must start the activities relevant for delivery, such as picking and packing the goods. The material availability date must be sufficiently early enough so that the goods are prepared by the loading date.
TransportationPlanningDate
We must arrange transportation by this date, so that the delivery can be sent to the customer. The date from which the organization of goods transport must begin. The transportation planning date must be selected early enough so that the transport is available on the loading date to load the goods.
LoadingDate
Picking and packing must be completed by this date so that the goods are ready for loading.
GoodsIssueDate
Goods must physically leave the shipping point by this date. The date on which the goods must leave the company to arrive at the customer location in time.
DeliveryDate
Customer should receive delivery of the goods by this date. The date on which goods are to arrive at the customer's premises. Example: The delivery date can be the delivery date requested by the customer (desired delivery date) or the date confirmed in the vendor's order acknowledgment or shipping confirmation (confirmed or acknowledged delivery date).
Times:Pick/PackTime
Difference between the material availability date and loading date.
TransportationLeadTime
Number of days required for organizing a shipment for an item to be delivered.
LoadingTime
Transit Time
Number of days required for delivering an item from your company to the customer via a certain route.
Enter Plant & Checking Rule, against which the Availability is to be checked. For Sales Order Checking Rule = A, Delivery = B, Back Order = BO
Check Rule : A End Lead Time Refers to the end of Replenishment Lead Time. If that is not included in the Configuration, then this field is not visible. Totals Display:** Receipts = Sum of all +ve Quantities in Rec./Reqd qty Column (Leave out the last row, MRP Element 001, since it is a total) These are all the Planned Incoming Movements Issues = Sum of all -ve Quantities in Rec./Reqd qty Column These are all the Planned Outgoing Movements Confirmedissues = Sum of all (+ve) Quantities in Confirmed Column These are the confirmations against ATP.
o o
BackwardsScheduling
Controlof AvailabilityCheck
ForwardScheduling
Result of AvailabilityCheck:SomeSampleScenarios
Above is the Availability Screen as seen in Sales Order. It has following Buttons: Onetimedelivery In the results of Availability, we have 3 options to choose from. This is Case 1, when we can confirm the Customer's Requested delivery Date. The details of this are visible in the first sub screen below. Completedlv.
This is Case 2, when we can confirm the Customer's Requested complete delivery at a future Date. The details of this are visible in the second sub screen below. Deliveryproposal This is Case 3, when we can confirm the Customer's Requested delivery in partial quantities at future dates. The details of this are visible in the third sub screen below. Continue If we select one of the above options, the same gets saved in the ATP results. Otherwise, we can select this button. In that case, system leaves the ATP screen without saving the ATP results.
Case:Confirmationon RequestedDeliveryDate
Case:Confirmationafter RequestedDeliveryDate(CompleteDelivery)
We have created a SO (VA01 ) on 09 Feb, with requested Delivery date for 09 Feb.
Nowwe changethe Availabilitysituation,by changingthe PO Date to 12 Feb. See the screensbelowcorrespondingto this situation.
The first screen shows the Availability (CO09) Overview. We have an incoming PO on 12 Feb. See the new Cum ATP qty. date wise accordingly.
!image038.jpg!In the second screen We have created a SO on 09 Feb, with requested Delivery date for 09 Feb. See that the Delivery got staggered according to the new Availability situation.
Case:Confirmationafter RequestedDeliveryDate(ReplenishmentLeadTime)
In the screens below, we have simulated the RLT. In the first scenario RLT is not activated, see below: 'Check without RLT'. The system considers only the confirmed inward movements. So out of 500 only 21 is confirmed. See IMG Guide > SD > BF > AC & TOR > AC > AC with ATP > Control of Availability Check
See VA01
In the secondscenario RLT is activated, but corresponding data in material master is not maintained. Material is procured InHouse (E), but In-house Production time (1st screenshot) & RLT (2nd screenshot) are not maintained. The system assumes both these times as Zero. So, complete 500 are confirmed immediately. See MM01
In the third scenario RLT is activated, corresponding data in material master is maintained. Material is procured In-House (E),
In-house Production time (10 days) & RLT (not maintained). The system confirms 21 on basis of incoming material. Rest 479 is confirmed after 14 days. This is because 10 working days for in-house production + 4 holidays (Sat-Sun).
In the fourthscenario RLT is activated, corresponding data in material master is maintained. Material is procured In-House (E), In-house Production time (10 days) & RLT (20 days). The system confirms 21 on basis of incoming material. Rest 479 is confirmed after 14 days. This is because 20 working days for in-house production + 8 holidays (Sat-Sun).
Checking Group Checking Rule Scope of Check Strategy Group Partial Delivery Agreement Replenishment Lead Time
Material MasterData:MRP 1 > MRP Group MRP 2 > Planned Delivery Time MRP 2 > GR Processing Time MRP 3 > Checking Group for Availability Check MRP 3 > Strategy Group MRP 3 > Total Replenishment Lead Time
SchedulingData:Transit Time Loading Time Pick/Pack Time Transportation Planning Lead Time