SD Tutorials

This tutorial discusses the different fields in the SAP Sales Order and their importance in brief. For more information on SAP SD Training, please visit the page.

Sales order is a key transaction in SAP SD which may include a myriad of subtopics including Sales Order Header, Sales Order Line Items and Sales Order- Schedule Line etc. Let’s discuss the key items in the header, line item and schedule line items in that order.

Sales Order Header:

Sales Order header usually contains Customer related information such as payment terms, customer id etc. It is usually recorded on basis of sale done to a particular customer. As it is mentioned above, sales order header may contain data which are customer specific such as customer number, name, payment terms, shipping information. It is the Sales Order Header which is common throughout the Sale Order topic and it also applies to all the Line Items.

Ø      Sales Order header Interface:
Sales Order header Interface contains Sales Order Number, Customer Number, Ship To and associated parties related to the particular sales order, Purchase Order number, Purchase Order Date, Net price of the order ( It may or may not include taxes) etc. In a sales order header there are approximately 40 to 50 different fields.

Ø      Sales order header Toolbar:
This toolbar includes all Sales Order related shortcuts. Here you may find some of the important shortcuts such as deletion, document flow etc

Ø      Sales Oder Header Tabs:
Tabs proffers us a clean way of organizing relevant data. You may find different tabs on the interface and each tab contains different data. For entering sales related data, there is a Sales tab which contains different fields. To reach sales order header tab to explore the fields, you can either use the Menu path or else you can also click on the Header Detail button on the screen. After clicking on the Header Detail button, which is also the short way to reach header items, you will reach the main screen. This screen will include tabs such as Sales, Shipping, Billing Document, payment Cards, Accounting, Conditions, Account Assignments, Partner, Texts Order Data and Status.

Sales Oder Line Items:
Line Items, as the name may suggest, are sales items listed in order, with certain relevant information. The Line Items contains all information related to the customer’s need and the data is saved in a listed format. It will quote the items such as M01 M02 or M03 etc as required by the customer. It also contains quantity of product requested by the customer. Based on this information the SAP system develops a Schedule Line data.   In short, Sales Order Line Items are customer’s request for material; the customer may have requested M01, M02 etc, in the needed quantity.

In order to reach to the Sales Order Line Item detail screen, for a particular item, you just need to double click on the relevant line item row.  The next screen will show detail related to particular Sales Order Line item, e.g. 10 and particular material, say M01. On this interface there are several similar tabs, such as Shipping, Billing Document, Payment Cards, Accounting, Conditions, Account Assignments, Partners etc. However, if you seek more detailed information, then you can click on the Arrow sign on the extreme right of all the tabs, this will open remaining tabs which are not generally seen on the screen due to lack of space on the screen.  By clicking on the relevant arrow button you will find a list popped up, which will include the tabs, in order to select these tabs you need to just click on the desired tab title in the list.

Sales Order Schedule Line:
For each of the line item there is a Schedule Line, which depicts the schedule of delivery. It may include information on dates of delivery and product units available etc. For example a customer has requested item M01 on 1st April 2010 and requires the item in quantity of 10, the information will be reflected in Sales Oder Schedule Line section along with its availability on the particular delivery day. The availability is decided by determining the quantity of requested item that can be delivered on the date and scheduling another date for delivering the remaining amount of the item. After a complex calculation, when the SAP system decides to set a later date for the delivery of remaining amount of product, it is called as Forward Scheduling.

On the Schedule Line screen you may find different columns such as Item, Material, Order Quantity, Description etc. Under these columns you will find Items listed with their relevant information. If you want to retrieve information on Schedule Line details, you need to click on the particular line item and then click on the schedule line button which is at the bottom of the screen, this will open the Schedule Line details for the particular item and the information may include dates and confirmed quantity etc.  Get more details on schedule line and SAP Training here. You will also be able to determine that whether the item requested on the particular date was confirmed or not, this can be done by matching the Order Quantity column on the upper screen and the Confirmed Quantity column on Schedule Line detail screen. If the ordered quantity was not confirmed on the requested date then the further scheduled date on which the remaining quantity was confirmed will be mentioned.

Menu bar:

If you want to access any tabs using the Menu Bar then you just need to click on Goto option, and select Header, you will find possible available tab options popped out. Amongst these options you can select your desired tab by clicking on it. In case if you want to see a Schedule Line of a line item, then you need to select the Line Item and then follow Menu bar path and Goto the Schedule Line of that line item. For example you need to select the line item M01 and select Goto, then click on Item and schedule line. These are the Menu path way of going to Header tab or/and Item tabs.

Significant Fields of Sales Order Header:

Ø      Order Number: There are numerous fields in the Sales Order Header and Order Number is one of the important fields which may be denoted as Standard Order. Whenever, you see a ‘c’ mark it indicates that there is configuration available for that. This means that the ordered number can be configured and made internal or external, numeric or alphabetical, as required. But typical Oder Number is a numeric data. It is also generally set to Auto-increment, for example the Order Number will start with 1, 2, 3, and so on; the effect can be noticed as soon as you create the next order. The order number is used as a unique identifier which helps you to easily retrieve or manipulate information by just entering the unique Order Number.

Ø      PO Number or Purchase Order Number: PO Number is given by the customer to us and is treated as the unique reference of the customer, because it is seen from the customer’s point of view; and for the customer it is a purchase order and not a sales order as we would see it. This is an important number which is used by the customer to track the sales order. In cases customer might directly provide the Order Number but even he is unable to provide Order Number then we should be able to track the order using PO number.

Ø      Net Value: Net value is in fact the total value of the sales order; in elaborated terms, it is the individual value of all the order Line Items put together. It should be remembered that taxes and everything else will be calculated on the Line Item level; however, in some cases certain values are calculated at the Header Level. Price is an example which is calculated at Header Level.

Ø      PO Date or Purchase Order Date: Similar to Purchase Order, even Purchase Order Date is seen from the customer’s point of view. It is generally used to manipulate and backdate or forward the date according to customer. This is allowed because PO Date dose not normally have any logistic effect on information of the Sales Order. This helps the customer to set the date of purchase according to his company’s requirement. It is crucial to understand that the Creation Date of a sales order is not equivalent to PO Date of sales order in terms of logic and importance. PO Date can be manipulated but creation date cannot be changed. This is essential as the system should have some log of the actual creation of the sales order.

Ø      Sold To Party: This field contains information about the Functional Owner of the Goods/ Services. This is the person or any entity for which the customer is actually purchasing the goods.

Ø      Ship To Party: Ship to Party is just the receiver of the product or services. It can be possibly the warehouse of the customer or any personal address. In simple terms Ship to Party field contains information on, to whom the order is actually sent or shipped on an address. There are cases wherein a customer may order items in bulk and may ask delivery at different location or addresses, in such a scenario the seller will create different line items for every location. The company will input information on Line Item number, quantity shipped and Ship-To-Location etc, for every particular location under the same transaction. In simple terms a single order may have several Line items which denote Ship To Information for numerous places. This can be done at Line Item level; however, in general cases Ship-To can be created as Header level.

Ø      Bill To Party: Bill To contains data on the party which will receive the invoice. For example, in some cases where a bank serves as the intermediary and looks after the affairs of a business, the bank is considered as the Bill To Party and the invoice is received by the bank.

Ø      Payer: Payer is an entity who actually pays for the invoices. It should be understood that Bill To Party may need not be a Payer as the party may only receive the invoice and forward to the relevant Payer who will pay for the invoice. There can be more than one payer for a particular transaction.


Note:
All the partners completing are transaction are considered as the business partners for that particular transaction. This means that any person or entity who acts as a stake holder in a particular transaction can be considered as a business partner. This can be done at Header as well as Line Item level.

Ø      Requested delivery Date: As the name suggest, Requested Delivery Date, contains the date on which the customer has requested the delivery to be made. In some cases the order might be created a month in advance, for example in November but the customer desires the delivery to be done on requested date in December. The date is generally based on the request of the customer. However, if it is not based on the customers requested then in such a case there will be a Lead Time, which will be automatically added, this setting is configured in the Sales order configuration. So for example an order may be created on 1st of November and there is no Requested Delivery Date by the customer, then the system will automatically set the Requested Delivery day according to the Lead Time set in the sales order type configuration, so anytime you create an order of a specific type it will have Lead Time added. It can be any number of days as set in the system and can be removed according to the requirement.

Requested Delivery Date also helps in determining the delivery scheduling, which means that if the goods are available before the requested date then the system will try to make the delivery on the requested date. However, if the requested quantity of items is not available even on the requested date, then the system will try to do Delivery Scheduling automatically, according to the availability of the product, from the Requested Delivery Date onwards and not according to the order date.

This is also the base of MRP Scheduling. For example a customer orders 10 units of product on a requested date Nov 1st and there are only 5 units available, then system will set a plan from the requested date onwards.  So that means there is one Schedule Line created for November 1st for 5 units. Now the remaining 5 units should be either manufactured or procured from a vendor and supplied to the customer. Manufacturing and procurement is set by Strategy tool which decides how it should be brought and supplied, manufacturing lead time, procurement lead time and will add buffet which may include lead time such as quotation, packing lead time, shipping etc. After doing all this complex ‘Scheduling’ calculation it will give us a dead line.

Ø      Complete Delivery: Complete Delivery field is actually a check box which means that the entire order should be delivered in one go and not in breakups of multiple scheduled dates or Schedule Lines. So to ensure delivery in one go you just need to click on Complete Delivery check box. The system will set the date on the basis of availability of the goods. For example if half of the requested quantity of goods is available on 1st and the entire requested quantity of the goods is available on 2nd then it will be shipped on 2nd avoiding partial delivery.

Ø      Delivery Block: Delivery Block field, as the name indicates, is used to deliberately block the delivery as set by the system. Depending upon the scenario and the reason for which the Delivery Block is applicable, the system may generate a Delivery Block or you may have to do it manually. Manually blocking the delivery may depend on reasons not mentioned is configuration settings and an example of scenarios for automatic delivery block may be pending payments etc. If you see a ‘c’ marked in a small circle, it indicates that it can be configured.

Ø      Billing Block: Similar to Delivery Block where we can block the delivery, in case of billing block we can stop billing from happening.  This is helpful in scenarios wherein the order is extensive and accuracy should be maintained, so you have a chance to first block the bill initially and then remove it from the Billing Block mode after all the rectification is done and accuracy is ensured. Again if you find a ‘c’ mark it is understood that Billing Block is easily configurable.

Ø      Pricing Date: Pricing Date is in fact a date which is used to determine pricing and is different from the order creation date and PO date. It is useful in scenario wherein you want the price of some other date to affect the particular order. Let us see an example of seasonal offers. Suppose there is a seasonal offer proffered by you which offers a discount of 10% and is valid from 1st December to 13th December. But the order you create is either a day before 1st December or after 13th December; however, you want the seasonal offer discount of 10% to be effected on the order; hence, you can set the pricing date to any date between 1st December and 13th December to ensure discounted price to the customer. This will not alter PO Date, Delivery Date or Order Creation Date.

Ø      Payment Cards: Payment Cards is a field which contains information on the type of card used to make the payment such as Credit Card, Debit Cars etc. This field will also ask you for the kind of card whether Visa or Maestro and you should also feed in the credit card number which is 16 digit numbers in norm cases. You may also see a ‘c’ sign which indicate that the field can be configured. There are also associated fields such as Card Verif Value. In Card Verif Value field you should enter, card verification number. There is also an Expiration date field which requires you to enter the date on which your card will be expired. The processing of Credit Card requires a payment gateway.

Ø      Incoterms: Incoterms is a widely known factor and it is in fact the abbreviation of International Commerce Terms. Incoterms has two parts wherein the fist part is the three characters ID (you may also call is short form or abbreviation). This is generally according to the global commerce standards. However, it can be personally defined based on the understanding ability of the associated party. Nevertheless, companies usually try to adopt standard terms. The second part of the Incoterm field holds location or position and is easily definable e.g. until the docks, until the plant, from the plant etc.


Incoterm also manifests the transfer of title. In relevant case if you ship expensive products to the costumer, you should ensure to provide the Transfer of title proof. It is also crucial to mention the place where it is happening, whether at your location or the customer’s location. This determines the liability (answerability) in case if any damage to the product has occurred.

Incoterm also specifies the Transport as well as shipping details. It also includes shipping terms which in return integrates information on freight details and insurance information, such as freight charges, who pays the insurance, who pays towards shipping charges etc.

Ø      Payment terms or Terms of Payment: Payment terms field contains information on how the customer makes the payment. For example it may contain something like “Payable Immediately Due Net” this does not actually mean payable in cash but as soon as the invoice is created the payer has to pay the bill. It also contains information on encouraged payment. This means that a period of time is given to the customer (I can be any number of days or months) within which the payment should be made. If the payment is done within the said period of time, a discount will be given to the customer.
Again, if you notice a ‘c’ sign, you should understand that it is freely configurable. Payment Terms is highly useful in case of Accounts Receivable or A/R department where you have all the Line Items which contain information matured case, actions to take in cases that are mature and takes care of cash flow etc. It is generally configured by FICO Consultant.

Ø      Sales Area: Sales Area is actually a combination of three organizational structures, namely, Sales Organization, Distribution Channel and Division. On the system the Sales Area field has three parts to be filled. It has implication in terms of configuration. You need to analyze and understand different factors whether what documents are attached to it before you create an order in sales area. For example pricing is configured in Sales Area, this is SAP’s way of specifying configuration specific to particular organization’s internal structure.  It should also be understood that each sales order can only belong to one sales area.

Item Detail Tab in Header

Item detail contains line item specific detail represented at Header Level. These tabs contain many fields such as Sales Document Item, Item Category, Order Quantity etc.

Plant: Where does Plant come from? The answer to this is that it may come from the Customer Master or it may also come from the Material Master etc, Irrespective of the source we should understand that the data is available. Delivering Plant is from which the material is configured to be delivered. The plant is available at Header level because there are several materials which should be delivered from different Plants, so this could change with the Line Item.

Procurement Tab in Header:
Procurement may be presented as a tabular representation of information and you may come across various columns in it. Some of the important fields are explained below.

Ø      ATP Quantity: ATP stands for Available to Promise. It is the quantity of product that is available right now and can be promised to offer. The system after evaluating the availability of the requested products denotes the number of available products that can be promised to the customer. In case there may be products available but may have reserved for some other interested customer. So the system keeps track of reserved and available product units and show ATP Quantity accordingly.

Ø      Route: Route is used by companies who do there own Logistic, they do their own shipping etc. It should be understood that Route deals with the kind of transportation techniques or mechanism a company is willing to undertake along with other aspects. There are some dedicated chapters on Route so at this point of the course, it is reasonable to be satiated with basic understanding about what is Route. These further chapters will focus on Route determination, or how actually the route is determined. It should be understood that Route is determined automatically and it is determined based on Destination, Source and type of good, whether the good are perishable or imperishable; depending upon the type of good the kind of container or vehicle and route for transportation is determined. Destination is the place of delivery and Source is the plant from which it has to be dispatched.
Route is again configurable but it can be configured based on various aspects such as location of plant etc; and this is done automatically.

Ø      Reason For Rejection: Most people will perceive that Reason for Rejection field may contain information on why an order is rejected; and they may also link it with reasons such as Credit Limit or Due Payments. But here the scenario is quite different. Normally, orders are not deleted in the system as these may be required by the auditors or for business intelligence purpose, so rather than deleting the order we normally ‘reject’ it. For example a customer may want to cancel a Line Item so rather than deleting it we classify it as Rejected. You can mention a reason for order cancelation. This is again configurable, this means you can set several reasons and select any one relevant reason for a cancelation; and these reasons may be depended on the industry. It is also helpful for stopping the transfer of requirement.  In case this of transfer of requirement; the MRP department is informed about the requirements and also the quantity and deadline. So when there is a reason for rejection is entered or stimulated the system will automatically stop the further procedure by canceling the request of transfer.
It will also help in canceling the reservation made against it. This means that while entering the order the customer may have demanded some quantity of goods which might have kept reserved for the customer. But as the order is tagged as Rejected the system will automatically cancel the reservation made against the order and make the reserved goods available.
If you want to tag the entire list of line item as rejected, then you can click the eighth button from the left, in the toolbar, which is denoted with a cross in red. This will help you select a reason for rejection which will be reflected on all the line items, canceling the entire order.

Toolbar Items (Sales order header Toolbar)

Document Flow: Document Flow is the first item in the toolbar item arrangements. Document flow contains a list of previous as well as subsequent items.

Status Overview: The next sign to Document Flow, which is denoted as cross and check mark is the status overview button which shows the status of the order. It may include status of order whether delivered or not delivered, complete etc. This option includes Header Status as well as Line Item status.

Preview Output: Seventh button in the same line of Toolbar is the preview output button. This helps in previewing the output before it is sent or printed. In case if you desire to see a preview of the order confirmation you need to click on this button.

Header Detail Button: Again the Header Detail Button which is not listed in the Toolbar but is an important short-cut way to reach to all the tabs related to Sales Order. This button is located on the right- hand bottom corner of the interface.

Costs can be seen on the service order and production order. There are two types of costs.

Planned Costs

Actuals Costs

Planned Costs : At the time of creation of the service / production order planner plans the required labor and components. The costs of these planned labor and costs is called planned costs.

Actual Costs : In reality to service an equipment or to produce a material, actual labor, components consumed may vary from the planned labor an d components. The cost of actual labor and components consumed is called actual labor. Difference between planned costs and actual costs is known as variance.

Costs are stored by cost elements. Ex : labor cost is associated with one cost element, trading goods with another, semi-finished with another.

The follwoing tables stores the costing information.

  1. COSP
  2. COSS
  3. COSA
  4. COSD
  5. COSP

K_KKB_KKBCS_CO_OBJECT_READ function module reads all this information grouping by table. Input for this function module is the order number

Click here for SAP Training and SAP Access.

Contracts in SAP SD

Tweet

Related Trainings

SAP Training

SAP SD Training

SAP Access

This article describes what contracts are and the different types of contracts in SAP.

Contracts in SAP SD

View more from Magna Training.

Schedule Line Category

Tweet

Related Trainings

SAP Training

SAP SD Training

SAP Access

Teaching Aid

Schedule line category

View more presentations from Magna Training.

Concept

Schedule Line Category determines how the schedule line behaves through the course of the logistics cycle.

 

Schedule Line Category

 

We already know that the sales item category is partly determined by the sales document type. The item category ( along with the MRP type of the material ) determines the schedule lines. It is also possible to determine schedule line category purely based on the item category irrespective of the MRP type. The schedule Line type can be seen either in the Procurement tab on the header or in the schedule lines tab at the line item level. The picture above shows that for line item 10 with item category TAN, the schedule line category is CP.

A schedule line category as discussed in the summary section determines many things about how the line item should behave. For example, it determines

  1. If the Schedule Line is Relevant for Delivery
  2. If the line item is Relevant for Transfer of Requirements
  3. If the line item is relevant for Goods Movement. If yes, what is the Movement Type to be used.
  4. If the line item can be procured externally ? If yes, which purchase order type should be used, the corresponding item categories etc

The following picture summarizes the key areas that the schedule line category impacts.

 

Schedule Line Category determines

 

Here are some examples of standard schedule line categories and how their different controls affect the transaction’s line item. For example schedule line CP ( Standard schedule line derived from TAN item category ), has a movement type of 601, makes the line item relevant for delivery, performs availability check and transfers requirements to MRP. Similarly, schedule line category CS ( derived from standard item category TAS ) makes the line item not relevant for delivery, availability check of transfer requirements.

 

Standard Schedule Line Categories

 

Configuration

The menu path to do the configuration is [ SPRO -> IMG -> Sales & Distribution -> Sales -> Sales Documents -> Schedule Lines] or t-code [VOV6]. Look at the controls behind the standard schedule line category CP

  1. Does not Have a delivery block by default
  2. Use the standard movement type 601 ( Goods Issue against a delivery )
  3. Is not relevant for external Procurement ( Since there is no PO Type, Item Category and Account Assignment )
  4. The item is relevant for delivery
  5. (Req./Assembly ) -> Implies that the requirements in the sales order are transferred to MRP
  6. Availability check is performed.

All of these controls are pretty self-explanatory. Go through other standard schedule line categories to understand different combinations of the same.

 

Schedule Line Category CP

 

You can see different examples of how the item category and hence the schedule line affects the logistics cycle.

Movement Type : For example, you can see the effect of the schedule line category CP on the movement type used in the PGI.

 

Movement Types

 

Triggering external Procurement : Similarly, you can see how the item category and hence the schedule line category affects the delivering cycle. In case of TAN the line item follows the standard delivery cycle. In case of TAS ( and CS ) a purchase requisition is triggered ( This is an example of an Individual Purchase Order triggered from the sales order ), because TAS determined CS schedule line category and the schedule line category is linked to NB Purchase Requisition.

 

Use of external procurement in the sales order line item

 

You can see an example of an actual Purchase Requisition generated out the line item because of the schedule line category.

 

Example of a purchase requisition triggered from a sales order line item

 

Similarly, the following 2 slides show the effect of the schedule line on availability check and transfer or requirements.

 

Effect of schedule line on availability check

 

 

Effect of schedule line on Transfer of Requirements

 

Please click here for SAP Training.


Questions and Comments Welcome


Item Category

Tweet

Related Trainings

SAP Access

SAP Training

SAP SD Training

Teaching Aid

Item category

View more presentations from Magna Training.

Concept

Similar to the way an SAP Sales document type determines the nature of the sales order transaction, an item category determines how a line item in a sales transaction behaves.

 

SAP Item Category

 

Just like the way a sales document type determines the way the document behaves ( If its a standard order, contract, quotation etc ), the item category controls how the item should behave in terms of

  • If the item is relevant for Billing ?
  • If the item is relevant for Pricing ?
  • If schedule Lines are allowed for the line item
  • If the value of the line item should be considered for credit management
  • If the type of item is relevant for special stock ( In case of consignment, empties management etc )
  • Whether a BOM ( Bill of Material ) should explode or not
  • The relevant text determination, partner determination procedures, status profile etc.

Let’s see some examples

 

Examples of different item categories

 

Let’s say you are buying a Honda CRV vehicle. You would select the different options that would make up the vehicle including the model, wheels, power options, other service options like extended warranty etc. Each of these line items represent different type of items and the way they behave is very different from each other through the course of the logistics and financial cycle.

For example, Honda CR-V could cost you 25 K but the options themselves ( Model, Alloy Wheels might just cost zero dollars ). Or the top item Honda CRV could cost zero dollars, whereas the total cost could be an addition of all the sub-items inside it.

As shown in the example picture above,

  • TAC – Configurable Item. Used as the top item in a BOM
  • TAN – Standard item. Is typically deliverable, counts for the credit limit, is relevant for billing and has the standard text and partner determination procedures.
  • TANN – Free of cost items. ( Let’s say that if you opt for heated seats, he will offer you free seat covers.
  • TAD – The 3 year service warranty is a service item. It is not relevant for delivery , but is relevant for billing and credit as well. There are other implications of these kinds of service items, but for the purpose of item categories we need to understand that this is just another item category.

Configuration

The configuration for item category involves

  1. [VOV7] Defining Item Categories
  2. Define Item Category Groups
  3. Define Default Values for Material Types
  4. Define item Category Usage ( Rarely Used )
  5. [ VOV4] Assign Item Categories OR Item Category Determination

The menu path for the same is [ SPRO -> IMG -> Sales & Distribution -> Sales -> Sales Document Item ]

 

Item category configuration menu path

 

We will only be dealing with the first configuration option ( ” Define Item Categories” ) in this article. The rest of the configuration will be dealt with in item Category Determination.

There are many standard SAP provided item categories. Some important ones are listed below and there are many more.

TAN – Standard Item
TAB – Individual Purchase Order

TAD – Service

TAS – Third Party Item
TATX – Text Item
TANN – Free of Charge

TAC – Variant Configuration
AFX – Inquiry Item
AGX – Quotation Item

BVN – Cash Sales Item
L2N – Debit Memo Req. Item
G2N – Credit Memo. Req. item

Let’s take the standard item category TAN and dissect it.

 

Business Data section of Item Category

 

This is the most important section of the item category configuration. Not all fields tend themselves to be understood easily unless the underlying concepts are understood. For example, if you do not understand the concept of Revenue Recognition ( which is a big subject in itself ), there is no point in trying to understand the key “Revenue Recognition” at the bottom. So, in this article, we will try to explain the simpler things and leave the rest to later articles. Sometimes, links will be given to other articles for further reference.

Completion Rule

Completion rule is mostly used in Pre-Sales documents ( Like Quotation, Contracts etc ) to determine if the reference to the line item is complete or not. For example, if you create a quotation for a material M-01 with quantity 10 and a subsequent order is created for a quantity of 5 referencing the quotation.

 

completion rule in item category

 

The quotation’s line item is not fully referenced yet ( There is 5 more qty left ). After you create another order for the remaining 5 qty, the quotation will be fully referenced as seen from the picture above. This switch is not relevant for the standard item category TAN as mentioned above, but more relevant for AGN etc. The various options possible are

  • ‘ ‘ Not relevant ( This is the option that is used for TAN )
  • A – Item is completed with first reference ( Meaning, the quantity need not be fully referenced. This could be a case when you want the quotation to be complete even though the total quantity is not fully referenced )
  • B – Item is completed only the full quantity is referenced. This is the example shown in the picture above.
  • C – Item is completed after the target quantity is fully referenced. ( Target quantity is the term that is used in Contracts typically )
  • D – Item is referenced via contract release.
  • E – item is completed after full target value is referenced.

Schedule Line Allowed

Schedule lines are allowed only for line items that need to be delivered. For example, the line items in sales documents like contracts or quotations cannot be delivered (until subsequent orders are created ) and hence the line items are not relevant for delivery. So the corresponding line items like AGN are not check marked with Schedule Lines Allowed. Other examples include credit and debit memo item categories like L2N or G2N.

 

Schedule Lines allowed field

 

Special Stock

Examples of special stock are consignment, project stock etc. The way this line item is handled is very different from standard orders, contracts, quotations etc. Hence this indicator is specially used only for item categories corresponding to special transactions like customer consignments, vendor consignments, project stock etc.

 

Special Stock Indicator

 

Billing Block

Not all items should be automatically billed. For example, a comcast installation with different items cannot be billed until the installation is complete and confirmed by the service personnel. So item categories like service that cannot be billed automatically can be put on billing block. The reason codes for the billing block can be configured elsewhere.

 

Billing Block

 

Pricing

Not all items are relevant for pricing. The standard requirement 2 in pricing procedure checks if the item is relevant for pricing or not. If this switch in the item category is set to blank, then the line items will not be relevant for pricing.

 

Pricing

 

Credit Active

In documents like quotations or contracts, the value of the document should not be used to calculate against credit management – Because, many quotations can be sent to the customer , but they should not be counted against their credit limit. Use this option in the item category when setting item categories for sales documents that does not require credit. Similarly in a standard sales order, if there is a particular line item type that is not relevant for credit, then this option can be used.

 

Credit Active

 

Transaction Flow

This section contains multiple determinations like the incompletion procedure, partner determination, text determination and status profile. You can read further about these by clicking on the links above.

 

Transaction flow

 


Questions and Comments


More Articles…

<< Start < Prev 1 2 3 4 5 Next > End >>

Page 1 of 5

Advertisements

2 thoughts on “SD Tutorials

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s