The pricing condition PR00 is marked as mandatory condition (T683S-KOBLI) in the pricing procedure (transaction V/08).
The same pricing procedure contains subsequent price conditions (conditions having Condition Class = B in V/06).
Due to the last price logic (see SAP note 836243) the PR00 price condition gets deactivated by one of the subsequent price conditions during SD document processing.
It means, KONV-KINAK / XKOMV-KINAK (condition inactive) is filled for PR00.
If you create a downpayment invoice, only the last active price condition is copied into the downpayment item and the deactivated PR00 condition is ignored. Since PR00 is a mandatory condition, the error message V1801 "Pricing error: Mandatory condition PR00 is missing" is displayed which hampers further activities.
It is the standard design of SAP system that inactive (KONV-KINAK) or statistical (KONV-KSTAT) conditions are not taken over into invoices having downpayment items.
For example billing type FAZ has downpayment items.
The following source code is responsible for this behaviour:
* By default, statistic and inactive conditions are not copied
* in downpayment positions. By setting U15_SUBRC to '1' the
* copying is suppressed.
if konv-kstat ne ' ' or konv-kinak ne ' '.
u15_subrc = 1.
By using FORM USEREXIT_PRICING_COPY (RV61AFZA) you can easily change this behaviour and fulfill your requirement. Changing the field U15_SUBRC in the user exit achieves that statistical or inactive conditions are copied into downpayment items.
An example for the source code development:
if ( konv-kstat ne ' ' or konv-kinak ne ' ' ) and amount_rule ca '45'.
u15_subrc = 0.
Let me share with you the most relevant KBAs related to ERP SD. Perhaps they will be useful to you in a situation you may face in the future.
These are the most relevant KBAs in terms of number of views since SAP started to make Knowledge Base Articles available to its customers.
Here's the list:
The following KBAs also rank in the top viewed, but are related to Brazil's NFe:
Always remember: if you find a KBA deserves some recognition, you can give it a star rating on the top right corner!!!
Maybe you can comment if you have found a KBA to be very useful which is not on the top viewed list I just shared.
In some cases it is necessary to modify the customer master data (name, address ...) of a business partner within a productive SAP system.
As a result of that modification you face the problem that already existing SD documents are updated according to the new master data.
Thus old SD documents already sent to customers contain now new partner data (for example different address).
You might think this is a system error, in case you need to issue an output for an old SD document, since it displays now different data than the one it used to have in the past before master data change.
This phenomenon is not a program error but the standard design of the system.
SAP can not store all the master data inside the SD document tables.
An address change in the customer master record is always transferred to all existing documents (unless the document has a manual address).
The system does not save the master data in the document, but in the master record. The document shows only a reference to the master record.
Following SAP note provides an explanation:
You can find the documentation in R/3 Library under the following path:
- Basis Components
- Basis Services / Communication Interfaces (BC-SRV)
- SAP ArchiveLink (BC-SRV-ARL)
- SAP ArchiveLink - Scenarios in Applications (BC-SRV-ARL)
- SAP ArchiveLink - Archiving Scenarios (SD)
Use transaction OAAD (Administration of Stored Documents) to display documents from the optical archive
Stored documents are classified according to document types. The system uses the following document types in case of SD documents:
|SDOBONUS||Rebate credit memo|
You can make use of the activation of ArchiveLink functionality even after real document archiving. Sometimes people need the output of an already archived document. But it can not be opened from the archive and the reload of archived documents into the system is not supported by SAP.
In that case you can easily have an access to the output of documents stored by ArchiveLink in the Attachment list.
The following image shows how you can access the stored PDF output of an already archived billing document in VF07 transaction.
The output is also available from SARI transaction.
For more information have a look at the following notes:
When you reversal billing document by VF11, the error message appeared as below:
Due to this billing which create without refer to actually sales document or delivery document, the may be created by POS or IDoc with Billing category as "W" (filed: TVFK-FKTYP and VBRK-FKTYP); In this case, we can't revesal billing use VF11 by normal program. We should assign copying requirment route 410 to filed TVFK-GRBED within Billing document. Then we can reversal billing by VF11.
PS: for more detial information, pls refer to sap note 489678, this note just for you reference to resolve issue quickly.
If you look at the 'Scope of Check' that was setup for your Sales Order Availability Check, you'll see a choice that says: 'Check without RLT?'
Besides the question being a bit confusing (when I check it on, is it with or without RLT??), the decision has many, some hidden, implications. First off: when the choice is checked, your availability check performs its routine without the Total Replenishment Lead Time.
So what is the difference between the two? Let's look at an example:
Assuming you have nothing in inventory today and a customer orders 100 pieces with a desired shipment sometime in the near future. There are 50 pieces coming from the production line BEFORE the customer wants to pick up 100, and 50 coming in AFTER the customer wishes to pick up 100 - the last 50 are coming after the end of the Replenishment Lead Time.
If our sales availability check performs with Total replenishment Lead Time (the option in the 'Scope of Check' is unchecked), the following happens:
The system checks ONLY within the Replenishment Lead Time and ignores all receipts outside of it. It also assumes unlimited availability at the end of the TRLT. Therefore 50 pieces can be confirmed to the customer's requested delivery date and 50 are confirmed just after the end of TRLT.
This has the following implications: First, the sales order will confirm ANY quantity, no matter how crazy the request is, right after the TRLT, and second, it confirms quantities that are not on the schedule or even on the plan at that moment. Only after MRP is run, there will be a planned order to meet the new demand. This is a very unreliable and noisy way to do business and, in my personal opinion, only makes sense if you run MRP every day, or in a Make To Order situation, where there is no stock, nor any receipts.
On the other hand, when you check without Total replenishment Lead Time, the system checks the entire planning horizon for receipts, but doesn't let you confirm, if there aren't any.
Doing this right is imperative to business success, leveling demand, reducing noise in the production program and increasing visibility on what's demanded for the production scheduler and what's available for the customer sales representative.
Sales Order Delivery Block due to Material Costing Update
Sometimes we create sales order with Material MRP schedule line (CP). As per schedule line sales order refers the product to production department for Production Process. Then production team produce the finish goods against the Sales Order. But Sales Order line item showing “Delivery Block Status: Blocked”.
During create of sales order if material costing not update then below status shown in sales order line item.
So sales order not possible to process for delivery. During creation of Delivery for the reference sales order system give some error. Like
“Create Delivery” not allowed (Sys. Status cost, object VB ……………………………)
How can we solve the error?
That’s mean delivery is not allow for this sales order due to material costing update. This sales order material has a BOM and BOM item component. This material and component item also needs to update material price costing. For this material we need to maintain Activity Type / Price Planning by Cost Center and Activity Type wise.
We can use this transaction by T-Code: KP26
Like : Cost Center : Production
Activity Type : LABOUR, MACHIN, POWER
After maintain Activity Type / Price Planning we can active the material costing price update by T-Code: CK11N
now open the sales order and save the sales order then material costing already updated and sales order material block status changed in " Not Blocked" Status.
now this sales should be allow for delivery process.
this way we can remove sales order update material costing and allow for delivery process.
Md. Enayet Hossain
Many times being at Functional side having some technical knowledge is a great way to make a big skills move in SAP. When you've a real passion for some particular area then I believe it’s equally important to start focusing on development efforts against your particular module along with functional role so sharing this document which I’m sure will be helpful for many of us.
WHY SUCH REQUIREMENT??
Question arises that why there’s a need to modify F1 documentation for any Data Element/Keyword and the answer is sometimes you need to display a Custom message for that particular field, sometimes you want to display the F1 help in Multi-languages and sometimes it’s just that more Documentation is required according to the user level.
SAP provides its own documentation for each of the data elements which we can view as an F1 help for screen fields based on the particular Data Element. This documentation can be enhanced via T-code CMOD.
First we need to get the data element of the corresponding field for which we want to change F1 Help and the 1st step is knowing the data element. Suppose in Customer Master, I want to change the F1 help for ‘Data Line’ Text box and in order to get the Data Element the same press F1 and then click on Technical Information Icon.
Execute T-code CMOD
Now click on Goto --> Text Enhancements --> Data Elements --> New DE cust. docu.
You’ll get the below mentioned screen, copy the data element that you've got after clicking Customer Master ‘Data Line’ field.
Click on the Mark icon or press enter, following screen will appear.
Give unique name in Modification Name Text box while creating the same. It depends upon you as if what starting point you want will it be the Original Text or as a Template. This will be copied into the modification screen which can further be changed accordingly.
In below mentioned screen I've defined customized usage of this field as I don’t want other fields to be displayed so deleted them. Moreover, you can use other features like formatting, paragraph style etc. Don’t forget to activate this Modification after saving.
After activating it, click on F1 help of ‘Data Line’ field in Customer Master and you can see the changes in below mentioned screen.
Now this ‘Data Line’ field name might be confusion for many of the End users who are responsible for maintaining Customer Master Record hence we can also change the keyword as per our requirement using CMOD once again.
Click on Goto --> Text Enhancements --> Keywords --> Change; mention the Data Element once again as shown in below screenshot.
This is the default description that you will be going to see after clicking on the Mark icon.
You can make the changes in above mentioned text fields as per your requirement.
Go to XD02/XD03 and you will see the changes that you've made are reflecting against that particular field.
We can cross verify the done changes in SE11 by entering the structure name as ADDR1_DATA, press F7 for the view and you can clearly see the changed short description like in below mentioned screen shot.
WHERE TO USE CMOD:
This enhancement technique mentioned above can be used to fulfill business requirements however before applying such changes we need to be careful as changes made through CMOD are directly linked to the dictionary object and the same will be reflected at all those places wherever that particular field is available.
I hope it will be helpful for those who always are ready to meet client's requirement at any cost or where there's a Top Management demand to fulfill wishes like that for their reporting purpose. Fruitful comments of all valuable members are most welcome. Thanks.
Read about intended audience / purpose / approach towards these posts => Additional info
This my recent initiative. Give me feedback how I could improve it further, any topic you would like me to discuss in particular, change my writing approach / style etc.
In this post I touch various controls, objects that are in action during item pricing and interplay between them(form order document down all the way to to billing / invoicing). It is assumed you are already aware of concepts like - pricing condition technique, condition type, copy controls. item category etc.
ITEM CATEGORY CONTROLS:
(Remember "item category" == "document type" + "item cat. grp." + "high lvl. item cat." + "usage")
As soon as you enter the material in sales order, SAP runs through item category determination rules. Identifying appropriate item category for an item with-in the context of this transaction. Item category has 2 configuration settings that are highly relevant in pricing context:
As you can see standard item category (TAN) is relevant for standard pricing (‘X’). and so normal pricing is carried out when TAN is identified as material’s item category in standard order (OR)
whereas, free-of-charge material category (KLN) is not relevant for pricing (BLANK). and so no pricing is carried out for the material in free-of-charge subsequent order type (FD)
COPY CONTROL SETTINGS
More detailed discussions on copy controls in later posts, but basically with-in pricing context the copy control settings (at item-level) control
(condition value are copied from source to target document at item-level only. Never at header level. and so for time being I only discuss item-level copy controls in pricing context)
NOTE-1 :: Pricing source set to ‘E’ (delivery / order) for standard item category (TAN) in source document. This means for every condition type included in billing document’s pricing procedure, SAP tries to copy value from delivery document. Only, if billing document does not find condition value in delivery document will it try to access condition value from sales order. This is particularly useful when freight conditions are entered in delivery document and other conditions are n sales order. Make sure the condition type being copied is also included in order / delivery pricing procedure. (remember order / delivery / billing - each have their own pricing procedures, more on that towards the end of this post)
NOTE-2 :: If an item category is order related (Billing relevance = order related) the system gives error if you choose Price Source as delivery (B / D / E / F. why?
NOTE :: remember "Billing date" in billing document is always "actual GI date" from the delivery (Delivery document => Item overview screen). This can be different form planned GI date, which is copied form sales order)
Coming back to sales order, as soon as you enter the material in sales order and SAP finds the item to be price relevant, it runs trough pricing procedure determinations rules and determine the relevant pricing procedure.
This pricing procedure controls what all condition types constitute overall item pricing. Each condition type can be
Depending upon business needs, it is also possible that a condition type be only added manually (not automatically!) to an item pricing. Despite relevant condition records existing. For example one-off special discount discussed case-by-case with customers. In order to achieve that, check the “Manual” check-box against the relevant condition type in the pricing procedure (V/08). In such situation, as-soon-as condition type is added manually, automatic determination kicks-in whereby SAP automatically picks the relevant condition records if there is one that exists. Or you just have to enter “Condition Amount (rate)” or “Condition Value” manually. Again make sure condition type shoudl still be set to be manually editable as described above.
Condition Amount (rate) and Condition Value are two different things
and, Condition value == Condition amount (rate) * Condition base
(This is very important concept esp. when it comes to distributing header level "group condition" to various items or condition types that are % based. I have met even semi-experienced consultants alien to this concept!
SALES / DELIVERY / BILLING PRICING PROCEDURE
Now that we are on sales order stage, all condition types that comprise item price have been determined (or added manually). Next step is to make a delivery document, followed by billing / invoice document. How the prices / condition values flow from document-to-document?
It is a common myth that conditions types and respective amount (rate) and values are copied from sales document => delivery document and from there on => billing document. That’s not what happens exactly. In-fact if you look sales => delivery copy control, VTLA, there exist no controls for copying pricing data
Sales, delivery and billing document each has its own pricing procedure assigned to it
During billing / invoicing phase, SAP copies condition values from order document or from delivery document or both. Based on “price source” setting in delivery => billing copy controls, VTFL (Or, for order related billing relevance, order => billing copy controls, VTFA). Make sure all the condition types you want to include in billing / invoice exist in both
Because condition values are copied only if the condition type exists on both source and target document. In order to test that, try to leave out PR00 pricing condition type from billing pricing procedure. Then try to bill the delivery. In the billing document you wont notice PR00 condition anymore.
In practice though we can
To fulfill special requirements in text processing, it is possible to create customer own specific data transfer routines in transaction VOFM. The customer specific name space in this case is from 50 until 99.
An example for a created routine would be number 91, which then has as technical include name RV45TE91:
All created routines are inserted into the Include RV45TENN, which functions as the object holder of all:
Now of course after the creation of such an own text data transfer routine, it should be transported to the productive system. At this step you will face the problem that the include RV45TENN can not be transported.
This is due to its development class, the include belongs to package $TMP, which is for temporary objects:
As temporary objects can never be transported, the transport of RV45TENN will fail with an error message.
To be able to solve the problem, the procedure described in Knowledge Base Article 1922260 should be followed. In the transport organizer tool (transaction SE03) the attributed package will have to be changed from $TMP to VMOD:
With VMOD the transport will become possible.
|327220||VOFM function and its objects|
|32394||Change object development class allocation|
As we know, we have 5 parameter help us to determine batch determination procedure for SD module within SAP system. (for instance : Sales organizaiton/ Distribution channel/ Division/ Sales order document -- Batch Search procedure)
when we create a STO delivey document, we are referecen puchase order instead of sale order; According the batch search procedure rule, we cannot to use the purchase order document type replace sale order document type as the parameter to determine batch search procedure.
In this circumstance, we have a concept of default sale document type to solve this situation.
1. we will assign a default sale document type to STO delivery document type, eg. NLCC or NCR (as figure 1 & 2)
2. and then use the default salt document type as we peremater to determine Batch Search procedure (as figure 3)
3. at the end we activate automatic Batch determination in SD for item category NLC and NCRN
when we finished all activity that mentiond as above, then the system will automatic determine batch within STO business scenario.
During condition maintenance a syntax error occurs in the corresponding condition info report, that leads to the problem that the report can not be generated.
Some affected reports: RV13ANAA, RV13ANAB, RV13ANAC, RV13ANAD, RV13ANAE, RV13ANAF, RV13ANAG, RV13AAEA, RV13ANBT, etc...
1. Enter a condition in transaction VK11 / VK12 / VK13
2. Click on button 'Condition Information'
As a result the following error is shown:
- System error: Report RV13AAEA could not be generated (Message no. VK759)
- Report RV13AAEA has a syntax error (Message no. VK806)
To see which condition table is affected it is necessary to carry out a syntax check in the mentioned report (In this case RV13AAEA).
As you can see the syntax error is caused by the non-existing field KBSTAT in condition table A385.
The problem is usually due to an inconsistency in the access sequence. To get to know which access sequence is assigned to the condition type (8PR0) you need to open transaction V/06.
To see which access of this access sequence uses the condition table A385 you need to open transaction V/07.
The corresponding access (90) contains the field KBSTAT, however this field is not part of the table A385.
This is the root cause of the problem.
SAP Note 902296 describes how such an inconsistency can occur. It provides a source code correction that prevents the system from such an error in the future.
- The incorrect access has to be deleted from the access sequence.
- Then the access sequence has to be saved.
- After these steps you can re enter the previously deleted access with the correct fields.
Make sure you navigate to the field level when entering the new access.
I have been continuously contributing in SD forums from last year and I have seen many threads about Sales BOM. Sometime users want to modify sales BOM as per their own business scenarios so here I am going to explain how sales BOM helps us to meet different requirements.
Here, I assume that you know how Sales BOM, item category, schedule line category and copy control works in SD process.
If you google with search term "Sales Bom in SAP SD" system will give you a lot of information about standard settings of sales BOM by using item category group ERLA and LUMF. This information can be found on following link.
In standard settings you can control pricing, inventory and delivery related indicator either on main item level or sub item level. If you use ERLA item category group in finished goods material master data, it will control pricing and inventory at header level and sub items will work as text items. For sub item level control you use item category group LUMF.
A very common and easy to understand example which SAP's standard documents have used is sale of a computer. In a computer sale, we sell it with brand name and specification. For instance if we sell a Dell pentium 4 desktop computer, it will have a mouse, keyboard, monitor and speakers but as a whole this is a Dell pentium 4 PC. So we will enter only one material in sale order with material description DELL Pentium 4 Desktop PC and system will determine all compnents automatically.
Sometime we get some requirements which SAP standard item categories and schedule line categories cannot meet. So we need to understand the basic concepts of item categories and schedule line categories and change them to fulfill our requirement. Let me explain with some real business scenarios.
Scenario 1: In SAP free goods standard settings we can maintain 1 free good material against 1 main item i.e. there is 1:1 combination. We can play with material's quantity but not with number of materials. If we get a requirement from client that if customer buys 5 quantity of material A then he will get 1 quantity of material B then it can be fulfill with standard free goods by maintaining it in VBN1. But if customer will get 1 quantity of material B and 1 quantity of material C on buying 1 quantity of material A then we can get this done by using Sales BOM.The settings for main item and sub item will be as follows. I am assuming that you want to cumulate cost prices of sub items in main item at the time of billing. If you don't want this then simply dont mark the check box in copy control from delivery to billing at item level for cumulate cost. Also maintain BOM for master data in CS01 with usage 5.
Main Item Settings
|Schdule line Allowed||Check|
Standard Shedule line category (CP) is used and Item Category Group in Material master sales view is Z001 which is customized for free goods main item materials. I will be using same material group for other scenarios as well.
Sub Item Setting
|Schdule line Allowed||Check|
Standard Shedule line category (CP) is used and Item Category Group in Material master sales view is NORM.
Item Category Assignment
Here ZMZM is my order type and Z001 is material group which I have maintained only in main item material's sales view field Item category group from material master (MVKE-MTPOS). Here no need to maintain in General item category group (MARA-MTPOS_MARA). ZTS1 is main item and ZTS2 is sub Item.
Scenario 2: Lets take another example of a split air conditioner. We are selling split air conditioners to customers and producing them in our plant. In split air conditioner Indoor, outdoor and Remote control are three separate materials. We sell split air conditioner in finished goods with capacity and brand name like 1 Ton Samsung AC 2 Ton Mitsubishi AC and we can also sell components individually. So we need to maintain prices at both level header and item. Here we will maintain stock at item level and price at item and header both. If we are selling a whole package of split air conditioner then it will be at header level and if we are selling only one component then there will be individual price of component.
When we are selling a whole package
|Schdule line Allowed||Check|
For this You have to use schedule line CT with no movement type and relevant for delivery if you want to use delivery related billing and copy the main item in delivery document. If you dont want to copy it in delivery then you can simply use CD shedule line category for main item but for this you have to use order related billing. It is good to copy main item in delivery just like a text item.
|Schdule line Allowed||Check|
For Sub item we can use CP or CN as per your requirement.
Item Category Assignment
When we are selling a component
When you will enter compnent material in order, system will determin normal item category TAN and with billing and pricing activated and price will be determined from condition record which you have maintained for it. So you can sell a whole package or component in same order type.
Scenario 3: If you are dealing with some business process in which you need to maintain multi level BOMs then you can achieve this by changing item category settings of main item and assignment of item categories. I don't have any real business scenario but lets assume we are selling comupters and in our company we are maintaining BOMs for computers and CPU separately. If we are selling a desktop computer then system will explode BOM of Dell 780 Computer in which we have maintained Monitor, CPU, Key Board, Mouse and Speakers materials and for CPU we have another BOM with Mother Board, Power Supply, Hard Drive and Super drive etc. Now when we enter Dell 780 material system will explode two BOMs. Prices will be maintained for Computer (Exluding CPU). For CPU we will maintain seprate price. Stock and deliveries will be maintain at sub item level.From configuration point of view there will two differences from scenario 2.
|Schdule line Allowed||Check|
Sub Item settings and schedule line settings will be same as in scenario 2.
Item Category Assignment.
With this you can sell whole package and also compnents separately.
These are some basics and most common business processes and I have shared these just to give you an idea. You can modify them as epr your scenario. It is all about playing with item category and schedule line settings. If you have some other BOM related business scenario or process which you are not able to configure with sales BOM, you can post your scenario in comment and let me help you in that.
There are many other controls like not to change quantity or material of sub items, copy whole package in delivery or allow single items too, creating automatic PR (third party sale) and maintain prices for compnents and whole package etc. I am not going in detail of these as we can find a lot of links in SCN describing these controls.
Value addition comments and suggestions will be highly appriciated. TW Typewriter if there is any other business scenario or example in your mind please share with me.
Our customer need to transfer project stock(Q) from cross company.
But Standard CC STO can not support it, because movement 643&645 do not allow Q stock business.
3. Check out STO configuration( created new transfer order type and assign new delivery type to it )
4.Set POD-Relevance Depending on Delivery Item Category &Change customer master da
5.Test the three business solutions
Plant (1000) -[VL02N:681]-> v.CST (1000) ----------[VLPOD:685 + 101]-------> Plant (0001)
Plant (1000) -[VL02N:681]-> v.CST (1000) -[VLPOD:685+107]-> v.CST (0001) -[MIGO:109]-> Plant (0001)
Plant (1000) ------------------[VL02N:683+107]-> v.CST (0001) -[MIGO:109]-> Plant (0001)
Thanks for Vinod's help.
To measure service with SAP software is not a simple task. Mostly because there really isn't a standard report, but also because there are so many factors that play a role in the calculation of a service rating and if these are not all lined up correctly and used properly... then it is nearly impossible to correctly determine if the service was ok or not.
One of the most important decisions to take is the MTO versus MTS one. If an item is designated to be replenish by MTS, the customer order (or stock transport order) has to check for stock and incoming receipts, whereas in an MTO scenario the availability check uses the Total Replenishment Lead Time to determine the confirmed date for delivery. If you don't classify your products by MTO or MTS on a regular basis, you simply can't set a reasonable confirmation date against which you would measure your service. And that will result in an incorrect report.
Another important feature is whether or not you fix dates and quantities in the delivery proposal. I've dealt elaborately with this issue in my video on YouTube http://www.youtube.com/watch?v=TWq_sxJsZ8M&feature=c4-overview&list=UUcNy4oxKL3pwqDNSbN3tvCg and you can see there what happens when you leave the the fixing indicator unchecked and what happens when you do not (broken down into four possibilities for MTO and four for MTS). The video also explains functionality around confirming delivery dates and that leads me to talk about what we should actually measure against...
SAP has created an Add-On tool called the "Service Level Monitor" which measures three KPIs:
- Delivery Service which measures whether or not the requested quantity was delivered in ful on the customer's requested delivery date
- Delivery Ability which measures if the requested quantity was confirmed on the customer's requested delivery date
- Delivery Reliability which measures against the confirmed date and shows what proportions was delivered in full to that date.
These measures work for both MTO and MTS since they go after the confirmed dates. The Delivery Ability then measures how good we produced to a forecast and therefore works well for MTS products. In a way you can also derive a measure for forecast accuracy on that KPI.
It should become obvious now that if the MTS versus MTO decision hasn't been done properly or if the availability check result is not saved correctly, the resulting KPI's and measures are not very meaningful. It is therefore imperative to fix the process first, before you start measuring the result.
SAP offers Add-On tools that can help you with a number of things that aren't available in the standard suite. The MRP Monitor helps you calssify your products for a a segmentation by consumption variability, replenishment lead time and more... so that you can periodically check whether your product should be setup for MTS or MTO. It also helps you set that policy in an automated way...
Once all factors are lined up you can use the Service Level Monitor to evaluate your orders by the three KPIs we discussed before:
feel free to contact me to discuss more....