Difference between MTS and MTO

MTO - Make to Order

Make-to-order production with capacity checking enables vendors to trigger production of a requested product as soon as a sales order reaches the system. An automatic process checks machine capacity, schedules production, and determines the requested product’s availability date. This enables vendors to make immediate, reliable offers and commitments to their customers for the requested quantities and delivery dates. While particularly well-suited to high-tech manufacturers and makers of industrial machinery and equipment, this method also addresses the requirements of other make-to-order manufacturers.

MTS - Make to Stock

Make-to-stock production is designed for manufacturers that usually operate on the make-to-order model – configuring their finished goods after sales order entry – but that nevertheless manufacture the components of the finished goods in a make-to-stock process. The SAP best practice definition describes how manufacturers can accurately predict the future demand for components, communicate with suppliers of critical parts, and plan the production and distribution of finished goods, all based on actual material and capacity restrictions.

Difference between MTS and MTO

Comparison of FI and FI-CA

Submitted by Anil Kumar

FI-CA: The business partner is not confined to a role on the debit side or on the credit side. This role can change in the course of time. For example: with a supplementary pension public sector there is the contribution phase and the pension payment phase.

FI: A business partner is created as a customer or vendor, which fixes its role and the functionality available with it at the outset.

FI-CA: The contract account does not automatically exist in a one-to-one relationship with a business partner and several other partners are also permitted for one account.

FI: It is only possible to have several accounts for a business partner with separate account agreements, by creating parallel customer and vendor master records.
There is no possibility of keeping one account for several business partners. A common view to the accounts of several partners is only supported in subareas (e.g. via the worklists).

FI-CA: The document of the contract accounts payable and receivable represents an all but complete business transaction relevant to accounts. It is not necessary to generate several documents if different company codes or posting data are addressed in this business transaction.
The document does not directly serve to reconcile the G/L account transaction figures.

FI: The FI document only reflects one segment of a business transaction which affects a company code and a posting date. The FI documents give a direct explanation of the general ledger transaction figures.

Comparison of FI and FI-CA

Information on FI-CA (Financials and Contract Accounts)

Submitted by Anil Kumar

The term FI-CA stands for “Contract accounts receivable and payable.“ FI-CA contains the range of functions needed by different industries or projects for their accounts receivable and payable management. Currently, these industries include public sector, utilities and telecommunications companies.
The common factor among these companies is a multitude of customers, which means even more open items. The number of customers in each system may go into the millions, and the number of open items several times that.
Such volumes of data can be processed by FI-CA because the memory space required for storing open and cleared items was reduced and critical activities such as posting, paying, dunning and returns processing were accelerated.

The FI-CA documents provide for the current account assignments from the following application components:

The general ledger. Here it is the company code, business area, G/L account.
The overhead costs Controlling and the Profitability Analysis (CO-PA). Here it is cost center, order, project, Profit Center, profitability segment.

The documents update FI-CA posting totals which are subdivided according to the account assignments named above. However, because the FI-CA documents often only differ from each other with regard to amount, business partner and contract account, a large summarization effect arises in the FI-CA posting totals. So experience from IS-U shows that several hundred thousand FI-CA document items meet on a few hundred totals records.
The FI-CA posting totals form the basis for generating G/L documents, via which not only the general ledger, but also, by transferring the corresponding Controlling account assignments, the different areas of Controlling are updated.
In addition to the account assignment characteristics of G/L accounting and Controlling, the FI-CA posting totals can be grouped according to a freely definable reconciliation key.
This reconciliation key is stored:

• in the FI-CA document header
• in the FI-CA posting totals
• in the document header of the general ledger document as external reference

This makes it possible to understand from which FI-CA documents a general ledger transfer document has been formed. This is a way in which, for instance, a reconciliation between contract accounts receivable and payable and the general ledger for a complete payment run, billing run or a given pile of FI-CA documents can be executed.
The FI-CA documents provide for the current account assignments from the following application components:

• The general ledger. Here it is the company code, business area, G/L account.
• The overhead costs Controlling and the Profitability Analysis (CO-PA). Here it is cost center, order, project, Profit Center, profitability segment.

Integration

The documents update FI-CA posting totals which are subdivided according to the account assignments named above. However, because the FI-CA documents often only differ from each other with regard to amount, business partner and contract account, a large summarization effect arises in the FI-CA posting totals. So experience from IS-U shows that several hundred thousand FI-CA document items meet on a few hundred totals records.
The FI-CA posting totals form the basis for generating G/L documents, via which not only the general ledger, but also, by transferring the corresponding Controlling account assignments, the different areas of Controlling are updated.
In addition to the account assignment characteristics of G/L accounting and Controlling, the FI-CA posting totals can be grouped according to a freely definable reconciliation key.
This reconciliation key is stored:

• in the FI-CA document header
• in the FI-CA posting totals
• in the document header of the general ledger document as external reference

This makes it possible to understand from which FI-CA documents a general ledger transfer document has been formed. This is a way in which, for instance, a reconciliation between contract accounts receivable and payable and the general ledger for a complete payment run, billing run or a given pile of FI-CA documents can be executed.

It is thus in a way a subledger of FICO. FI-CA, though not a complete subledger accounting system, it is always a component of an industry solution or a project solution.

FI-CA is first and foremost a component of the following industry solutions:

• Utilities (IS-U)
• Insurance (IS-IS/PP)
• Public sector (IS-PS)
• Tele communication (IS-T)

FI-CA mainly covers the functionality of those areas in which at least two of the industries reveal the same type of requirements. Individual requirements from exactly one industry are to be achieved as an industry solution on the basis of the FI-CA.

Information on FI-CA (Financials and Contract Accounts)

Payment advice Processing

Payment advice Processing

Matching of customer open items

The lockbox program uses detailed information from the payment advice to automatically search and match customer open items. The document number on the payment advice is matched against the document number in the customer open item file. Therefore, accurate payment data is necessary for automatic clearing to take place.

Payment Advice Status

If the checks were applied or partially applied, the advice is deleted from the system after processing. If the check was unprocessed or placed on account of customer, the advice is kept on file for further processing.

Post Processing

The post process function entails reviewing the status of the checks applied through the lock box function. User must manually clear any checks that were on-account of customer or not applied to customer account.

The Lockbox overview screen details the number of checks in each category. Depending on the status of the check, the user determines what needs to occur to apply checks.

On account: If the bank keyed in the correct invoice number, the Lockbox Import Program posts the payment on account. In the post processing step, you access the payment advice and correct the document number and upon saving the changes, the post process function clears the open item, deletes the payment advice and sets the check status to applied.

Partially Applied: Checks that are partially applied may require further processing. Ex: Check may have paid 5 invoices, but one was in correctly keyed. The first 4 invoices would clear. The payment amount for the 5th invoice would be put on-account and would have to be post processed to clear.

Unprocessed: Any payment that could not be identified either by customer MICR number (check) or the document number would remain Unprocessed. Once the payment is researched and the customer and invoice is identified, it would be applied during post processing.

What configuration needs to be done?

Control Parameters: It determines the import format BAI, BAI2 & ANSI and the types of postings generated by the lockbox program. These control parameters are needed for importing lockbox file sent by bank.

Posting Data: Company code, Bank Information, G/L accounts for posting and clearing, document types and Posting keys.

RFEBLB30 or FLBP transaction

Lock Box data, Processing parameters (Procedure & Algorithm) Account assignment (Profit center), output control and Mode of call transaction.

Payment advice Processing

Difference between EDI 820 and 823:

Difference between EDI 820 and 823:

In general EDI 820 formats will be used to send information to Vendor furnishing details of payment for his supplies. From business standpoint, EDI 820 information comes from customer as the business is vendor to its customer. In fact EDI 820 is not a lockbox format but can be used in place of lockbox for customer open item processing. This information however is not a real payment but only a remittance advice.

Where as lockbox format is an exclusive format that comes from bank confirming the payments received from customer. This is real payment information which got credited in business account at Lockbox /Bank. Besides this basic difference between these two formats some other differences can be summarized as under.

EDI 820 will have one to one information. Each customer will send remittance information to the business. EDI 823 format will have several customer information in one format.
Customer can not use EDI 823 format where as Bank can use EDI 820 format.
EDI 820 is only an advice but 823 is a payment.
Technical settings viz., Partner profiles, Basic type, Message type, function modules used in SAP are different between these two.
Level of information will be different. EDI 823 will have Total number of checks involved, total payment amount involved, break up of checks and amount per batch, per customer etc will not be available in case of EDI 820.

BAI vs. EDI in Lockbox:

Both the formats are acceptable and can be used in SAP for processing customer open items. However the earlier one is (BAI) is file based and the later format is (EDI) is idoc based. File based is batch mode and EDI is real time information. BAI can not be made as real time process but EDI can be made as batch process.

EDI technology requires mapping tool. It creates intermediate document holding the information for further process. On the other side BAI format doesn’t require this.

As far as processing and of clearing customer open items in SAP is concerned, whether the format is BAI or EDI system will follow same transactions. FB01 > FBE1 > FB05. In either of the case if information is not sufficient to clear open items, it is available for manual process.

Some additional advantages of EDI are:

Data Accuracy
Reduce Technical Complexity.
Lowe Personnel needs.
Accelerates information exchange.
Avoid Data Entry Errors.

Lockbox Process - Data file to SAP open item clearing

What Bank will do?	Bank Receives the payments, create a data file of the customer remittance information and payment amounts, and deposit the checks into client bank account. On regular basis, Client company receives this data file for processing to update in their accounts.
What lockbox data file contain?	Depending upon the choice of services with the Bank, the lock box file will contain information viz., Customer name, Customer Number, Customer MICR number ( Bank routing and Account Number), Check amount, Invoice number, Payment date, Payment amounts and other information.
Lockbox Data Flow	As shown in the following picture, customers send their payments to a lockbox. Then bank collects the data and sends (either through EDI 820 and 823 formats) to R/3 users EDI server (standard Process). The server translates the message using as standard EDI interface into an IDOC (Intermediary documents) and sends it to the SAP Server.
What happens in SAP server	Once the message is received and stored in SAP table, a program is clicked (RFEBLB30 or FLBP transaction) to check the information stored in bank statement tables and create payment advices with Payment amount, invoice numbers and customer number.

Difference between EDI 820 and 823:

Understanding Lockbox

Submitted by Chandra Wipro

Objective of this document is to explain the meaning, purpose, advantages and disadvantages of the lockbox. This document also explains various types of formats that can be used to process the lockbox data.

What is a lockbox?

A company can create accounts called ‘lockbox’ accounts at its bank (or banks) that act as payment collection accounts for customer payments. The company then informs their customers that all open item payments for their accounts must be submitted to one of the established bank lockbox accounts. The bank collects these payments along with the customers’ remittance information that indicates what open items the customer payments intend to clear. Data entry clerks at the bank manually enter the information into an electronic file for transmission to the company to which the lockbox account belongs. These files are typically transferred nightly to the various lockbox owners (companies). The files adhere to one of two standard banking industry transmission formats: BAI, BAI2, EDI820 and EDI 823.

Advantages of Lockbox:

Lockbox process has several advantages. Some of them can be illustrated as under.

Avoid Manual handling of checks
Timely processing of Checks
Easy reconciliation
Reduction of manpower cost
Avoid clearing Errors

What is BAI?

The standards for lockbox transmission files are defined by the Bank Administration Institute (BAI). Founded in 1924, the BAI organization is a partnership composed of its own BAI membership, a Board of Directors, various banking industry advisory groups and a professional staff. The organizational mission is “to help bank administrators achieve high levels of professional effectiveness and to help solve significant banking problems.” Activities include the definition of industry file formats, such as lockbox transmissions. BAI and BAI2 are the two defined lockbox transmission formats, however, BAI is considered ‘outdated’ by the BAI organization and is no longer supported (ie. standards are no longer updated or improved). Nonetheless, many banks still offer transmissions in the old BAI format.

BAI vs. BAI2?

BAI and BAI2 formats differ in their level of information detail. BAI does not separate out the incoming check line items by invoice subtotal reference. Instead, one check total amount simply has all invoices listed underneath it. Thus, in BAI format files, the entire check amount must match perfectly (or within configured payment difference tolerances) the total amount for all invoices listed. Otherwise, the entire check will enter into SAP as:

an “On account” posting (if the payment and invoice totals don’t match), or
An “Unprocessed” posting (if no customer account and documents could be identified from the transmission).

In these scenarios, your Accounts Receivable cash application clerks will have to perform manual application to clear payments against open items on the proper accounts.

Conversely, BAI2 splits the check total into separate invoice references and associated payment amounts. Thus, within a large batch, BAI2 format files will allow a “Partially applied” status in which some identifiable payments within the check total will be matched and cleared, others will land on account. As a result, your ‘hit rate’ percentage of payment-invoice matching from each transmission is likely to be higher when using BAI2 rather than BAI formats.

Electronic Data Interchange:

Network transfer of structured electronic data from one computer application to another using standard message formats. EDI is described as the interchange of structured data according to agreed message standards between computer systems by electronic means. This standard format is nothing but a Set of rules, agreed upon, accepted, and voluntarily adhered to, by which data is structured into message formats for exchange of business and operational information. Lockbox related formats are Edi 820 and 823.

EDI 820:

The 820 Payment Order/Remittance Advice transactions can be used to make a payment, send a remittance advice, or make a payment and send a remittance advice. The 820 transaction can be an order to a financial institution to make a payment to a payee. It can also be a remittance advice identifying the detail needed to perform cash application to the payee’s accounts receivable system. The remittance advice can go directly from payer to payee, through a financial institution, or through a third party agent.

EDI 823

The 823 Lockbox formats are sent by bank as confirmation of payments received from customers of lockbox owner. EDI 823 format contains information like Bank details of lockbox service provider, total quantity of checks in each format transmission, total amount involved in total checks, number of batch involved ( batch represents maximum quantity of checks in each lot). Further break up like, customer name, customer bank routing number, customer bank account number, check number and amount, number of invoices paid, amount per invoice, discounts for each invoice, deductions if any involved and credit memos etc.

Information available in these formats are generally used for clearing customer open items in SAP depends upon the business requirement. Following EDI configuration is required to read the data from corresponding format and process customer open items.

Format

Idoc type

Message type

Process code

EDI 820

Pexer2002

REMADV

REMA

EDI 823

FINSTA01

LOCKBOX

LBX

SD Terms "Understanding Lockbox

Steps to configure Document text in Customer Invoice Entry (FB70) transaction

By Vijayendra Krishnamurthy Rao, Hewlett-Packard

This article shows how to configure document header text in FB70 transaction. It uses the same text determination techniques.

Problem Statement or Requirement Details:

In transaction FB70 which is used to post Customer invoice documents, the client needs a new text id to capture the Vessel Name.

Standard SAP does not provide a screen exit for this transaction which could be used to enhance the std screen to capture the additional data in FB70 transaction.

Solution provided was to create a new document text id which can be configured in the system. This text id can be used to store the Vessel name in the text which can then be used while printing the layout.

The following screen shot shows the FB70 transaction.

As seen above, there are only three text ids currently. We will configure the third fourth text id which will appear below the “Payment Advice Information” text.

The following steps below will show how to configure the text in SPRO.

Step 1 à Goto SPRO à Financial Accounting à Financial Accounting Global Settings à Document à Document Header à Define Text ID’s for Documents.

As seen from the above screen the 3 text id selected are the ones visible on the FB70 transaction. So if you want to have your own text to be displayed click on the Create button on the application tool bar and create your own text id’s.

In our case we will create a text id with the number 0005.

Select the check box so that this text id is made available in FB70 transaction. Click on the save once done.

Since this is a customizing the system will prompt to create a customizing request.

Now if you go back to the FB70 transaction you can find the new text visible under the Document header text

User can make a entry in this field and save the document.

Click on continue and save the document.

The vessel name is now captured in the Customer Invoice document.

SD Terms "Steps to configure Document text in Customer Invoice Entry (FB70) transaction

SD Terms "Sales Organization", "Distribution Channel", "Sales Office", "Sales area", "Division" and "Sales Group"

By Lakshmipathi

1) Sales Organization

An organizational unit subdividing an enterprise according to the requirements of Sales. It is responsible for selling materials and services.

2) Distribution Channel

The distribution channel represents the channel through which salable materials or services reach customers. Typical distribution channels include wholesale, retail and direct sales.

3) Sales Office

A sales office is an organizational unit in sales and distribution which is responsible for sales within a specific geographical area.

4) Sales Area

It is nothing but combination of Sales Organization, Distribution Channel and Division. Only based on the sales area, you will be able to create orders and make despatches.

5) Division
A division is an organizational unit based on responsibility for sales or profits from saleable materials or services.

Divisions have two main applications: They are organizational units for Sales and Distribution, and they are necessary for business area account assignment for logistics transactions in Financial Accounting. Divisions can be used to describe specific product groups and can form the basis for sales statistics, for example.

Divisions are not used for any functions developed specifically for SAP Retail. However, a single dummy division is provided where necessary.

6) Sales Group

A group of sales people who are responsible for processing sales of certain products or services.

By using sales groups you can designate different areas of responsibility within a sales office. When you generate sales statistics, you can use the sales group as one of the selection criteria.

For example, If sales office personnel service both retail and wholesale markets, you can assign a sales group to each market

SD Terms "Sales Organization", "Distribution Channel", "Sales Office", "Sales area", "Division" and "Sales Group"

Configuration of Pricing Procedure

By Santosh

In SD, the steps to configure Pricing procedure are as under:
Step 1:
Condition table: If existing condition table meets the requirement, we need not create a new condition table. Considering the requirement for new condition table, the configuration will be done in SPRO as follows: IMG --> Sales & Distribution --> Basic Function --> Pricing Control --> Condition Table (select the required fields combination, which will store condition record).
Step 2:
Access Sequence: If existing access sequence meets the requirement, we need not create a new access sequence. Considering the requirement for new sequence, the configuration will be done in SPRO as follows: IMG --> Sales & Distribution --> Basic Function --> Pricing Control --> Access Sequence (Access sequence is made up of Accesses (Tables) & the order of priority in which it is to be accessed. Here we assign the condition table to access sequence.
Step 3:
Condition Type: If existing condition type meets the requirement, we need not create a new condition type. Considering the requirement for new condition type, the configuration will be done in SPRO as follows: IMG --> Sales & Distribution --> Basic Function --> Pricing Control --> Condition Type. It is always recommended to copy an existing similar condition type & make the necessary changes. Here we assign Access sequence to Condition type.
Step 4:
a. Pricing Procedure: It is recommended to copy a similar pricing procedure & make the necessary changes in new pricing procedure. Pricing Procedure is a set of condition type & arranged in the sequence in which it has to perform the calculation. Considering the requirement for new Pricing Procedure, the configuration will be done in SPRO as follows: IMG --> Sales & Distribution --> Basic Function --> Pricing Control --> Pricing Procedure --> Maintain Pricing Procedure.
b. Pricing Procedure: After maintaining the pricing procedure the next step will be determination of pricing procedure. Configuration for determining pricing procedure in SPRO is as follows: IMG --> Sales & Distribution --> Basic Function --> Pricing Control --> Pricing Procedure --> Determine Pricing Procedure.
Step 5: Condition record: Condition record is a master data, which is required to be maintained by Core team / person responsible from the client. During new implementation, the condition records can be uploaded using tools like SCAT, LSMW, etc.

Configuration of Pricing Procedure

Configuring Availability Check

By Santosh

Availability check

Availability check is an integral part of the business process that determines if the required delivery quantity can be met on a required delivery date. For this purpose the system takes into account pre-delivery activities such as scheduling for picking or packing times and the time taken to produce or obtain the material. It also performs several background functions such as Backorder processing, rescheduling and ATP quantities.
Backorder processing: processing of a sales order that has not been fully confirmed or not confirmed at a certain delivery date.
Rescheduling: is a proposal of how – confirmed quantities already assigned to a sales order can be reassigned to other sales orders that have a higher priority.
Available to promise (ATP): is a process of checking the available quantities of a material. The ATP quantity consists of warehouse stock + planned receipts (incoming stock) – planned issues (outgoing stock). to examine stock on hand (CO09) proceed to logistics – sales & distribution – sales – environment – availability overview.
Replenishment lead time (RLT): is the time taken for the material to become available either internally (in house production) or externally (from a vendor). The most important things to consider during an external procurement are purchasing and MRP2 (procurement) views of MMR where the processing time for purchasing, planned delivery time and goods receipt processing time are taken into account. On the other hand internal procurement is based on in house production time (MRP 2 view) goods receipt processing time or alternatively RLT time, which is found on MRP 3 view.
RLT (Replenishment Lead Time) is the time taken for the material to become available. RLT is only used when doing an ATP check (Available To Promise). The value of RLT for a material is specified on material master record.
There are three types of availability checks –
- Check on basis of ATP quantities.
- Check against product allocation.
- Check against planning.

Configuring Availability check through Checking Groups

The checking group + checking rule determine how the availability check is to be performed.
The checking group determines whether and how the system checks the stock availability and generates requirements for material planning. The checking group defines what type of requirements will be passed on i.e. summarized requirements (daily/weekly) or individual requirements for each sales order.
The checking rule applies to how the availability check is to be carried out at the transaction level. Note that you must define checking rules for each individual application such as for production orders for example. In Sales and Distribution, the checking rule is specified internally within the system and cannot be changed.
The checking rule, in conjunction with the checking group, determines the scope of the availability check for every business operation; that is, which stocks, receipts and issues are to be included in the availability check and whether the check is to be carried out with or without the replenishment lead time.
Briefly explaining the above – checking group determines which type of requirement to be passed on to MRP whether it be individual or summarized and checking rule which is at the transaction level and can be configured independently for each application module, determines which stocks, receipts and issues to be taken into account. For performing an availability check checking group has to work in conjunction with checking rule.
Advantages of individual processing over summarized processing –
Backorder processing is possible.
You can access (MD04) order, line and schedule line individually which gives a greater control on available stock and requirements placed on stock.
The system automatically uses individual requirements in case of special stock items.
Required data for the Availability check to be carried out –
The Availability check must be switched on at the requirement class level.
The Availability check must be set at the schedule line level.
A requirements type must exist by which the requirements class can be found.
A plant must be defined in the sales order for each schedule line item (in other words plant must be defined for every material in MMR).
A checking group must be defined in the material master record in the MRP3 screen in the availability check field.
Configuring Availability check and defining Checking Groups –
Checking groups are introduced into the sales order based on the setting in the material master record.
SAP standard checking groups are 01 – summarized requirements and 02 – individual requirements or you can create your own by copying the standard ones.
Total sales and total deliveries columns are there to configure a checking rule to sum up requirements to post to MRP either individually or by day or week.
Block quantity required can be set if you want several users to be able to process the material simultaneously in different transactions without blocking each other.
The no check indicator is CHECKED when you DO NOT want the system to carry out ATP check.
Defining material block for other users – the block check box is an indicator that enables you to block material master records of a particular material during the availability check and restrict other users from accessing same master record and reserve the material. If the block is not set, two users can confirm the same material at the same time for two different orders, not knowing if the stock is available or not. If you select this field, the material is blocked during the availability check and other users cannot: a) Make changes in the material master record. b) Create purchase orders for the material. C) Create orders for the material.
Defining default values for checking groups - Checking groups are introduced into the sales order based on the setting in the material master record.
However if there is no entry present in the material master record for the checking group, a default value can be set here, depending on material type and plant.
This default value will be used by the system depending on the material type mentioned in MMR and plant in sales order.
If an entry exists, this default value is over written by MMR.
Controlling Availability Check – in this section, you tell the system what stock on hand and what inward and outward movements of stock it must take into account when performing the availability check in addition to whether or not to consider the replenishment lead time.
These settings are based on the checking group that is assigned to the material master record and the checking rule that is predefined and assigned to the sales and distribution transaction.
These settings carry out control both for sales order and delivery as well. This is due to the fact that you may want to include specific stock or incoming stock for the sales order, yet at the time of the delivery only include physical stock on hand waiting to be shipped.
It is possible to indicate to the system that you would like the availability check NOT TO CHECK the stock at the storage location level. This indicator is used to set the scope of the availability check.
It is used to switch off the check at storage location level. You create a reservation for a particular storage location. However, the scope of the availability check is set in such a way as to exclude the storage location. In this case, the system carries out the check at plant level only and does not take the storage location into account that is specified in the reservation.
Should you not want the system to automatically check RLT, you may indicate so here. RLT is the time taken for a material to become available. It is only used when doing an ATP check and is taken from MMR.
defining the elements in the availability check entirely depends on the business needs, but a few tips are given under –
When controlling the Availability check at the time of the sales order, a purchase requisition does not necessarily indicate by it is going to come into the plant.
A shipping notification on the other hand - a confirmed purchase order – is a good indicator of receiving stock on a specified date.
It is always recommended not to select the shipping notifications for the delivery requirements type as you may not actually receive the stock into plant or warehouse for which you are creating a delivery.

Configuring Availability Check

Multi-level Packaging in Delivery

By Santosh

Before creating the packaging material you have to go to:
IMG-Logistics Execution-Shipping -Packing.

Define packaging material types- it can be anything like boxes crates, etc. in this you have to maintain the output determination procedure, output type, plant determination, packaging material category, generate delivery items, number assignment. you can copy from standard also.
Then go to define material group for packaging materials - here you maintain the four digit code and the description. Actually, this group is nothing but similar products which require similar packing products. For Ex. Nokia Phones all types they are basically packed first into a polythene bag. So here nokia phones can become a material group for packaging materials and polythene bag can become the packaging material type which can include different sizes and types of polythene bags.
Define Allowed Packaging Materials - Here you assign the shipping group for packaging materials to the packaging material type. This is related to your material master data of the packaging material which you create.
Now go to MM01 to create a packaging material. use material type as Packaging material then inside the system will take the item category group as VERP. Then in the Basic Data1 screen you have the material group for packaging material (MGPM). Select the proper one. Now in the Sales:General/ Plant screen you have to maintain data regarding the packaging. you select the MGPM same as the basic data 1 screen, then select the packaging material type, the allowed pkh weight, allowed pkg volume. This is important because if the weight of your finished item is 2 KG and in the allowed pkg weight you enter only 1.5 KG, then while you carry out the packing process in delivery, the system will give you error," packaging weight exceeded." The assignment in the IMG creen for Define allowed packaging materials should be same as u mention in the material master. Then save your material master for packaging material.
VA01 create the order, save it.
VL01N enter shipping point, go to edit - pack- you will face a screen with 2 parts. In the top part you select your packaging material in which you want to pack your finished item, enter the system will assign a number to that material. Now select the Material in the top part and the finished one in the lower part and click on the Icon Pack. Here one thing has to be taken care of. Suppose if you want to pack only one finished item in one packaging material, then in the lower part of the screen you have a field for partial quantity here you change it to 1. system will prompt quantity changed. now you select the material in the top part and the one in the lower part and click on the PER PART. QTY ICON. In this way the system will pack only one finished item in a single packaging material. Packing is done go back, select the picking and do the PGI. save the delivery and create the invoice.

HANDLING UNITS. (Used for Multi level packing)
Basically handling units come into picture when you want to carry out multi level packing. suppose you want to pack Nokia phone first into a polythene bag, then this polythene bag is again packed in to box. like that. then this box will become a handling unit. For this go to :
IMG - Logistics General - Handling Unit Management - Basics.

First create all your packing materials using MM01 and type as packaging material. Maintain all the assignments in IMG in Logistics General.

In basics you do the same thing as you did in the packing in logistics execution. like you create the packaging material type, then MGPM and their assignment.
Then go to External Identification - and maintain the number ranges for the handling units that you want and assign the same to your packaging material type.
Now that you have done everything, create the order, save it, in VL01N, enter shipping point, go to edit - pack - do the same thing as i have told you in the step no. 6 (above). now after doing select the PACK HUs TAB . NOW IN THIS SCREEN IN THE TOP PART YOU WILL SEE THE ALREADY PACKED MATERIAL. In that same part again select your next packaging material that is BOX. enter the system will assign the number to the BOX.
Now select the material which you have just entered and the materials which were already packed in the lower part of the screen and click on the ICON PACK.
In the same way again in the top part of the screen you select your next level packaging material and press enter. the system will assign a number to it. now select the material you have just entered and the previously packed material in the lower part of the screen and click on the icon PACK.
In this way you can carry out multilevel packing. just take care of the allowed packing weight and the number of units you have to pack in the next packaging material.

Multi-level Packaging in Delivery

Enterprise Structure Configuration

By Santosh

Enterprise Structure:

Maintaining Sales Organization
Sales Organization is an organizational unit responsible for the sale of certain products or services.
IMG -> Enterprise Structure -> Definition -> Sales and Distribution -> Define, copy, delete, check Sales organization
Assigning Sales Organization to Company Code
This assignment ensures all the sales made through this Sales Organization are accounted for in the assigned Company Code (Company Code is created by FI Consultant).
IMG -> Enterprise Structure -> Assignment -> Sales and Distribution -> Assign Sales Organization to Company Code
Maintaining Distribution Channel
Distribution Channel is the way, in which Products or Services reach Customers.
IMG -> Enterprise Structure -> Definition -> Sales and Distribution -> Define, copy, delete, check distribution channel
Assigning Distribution Channel to Sales Organization
This assignment ensures, a Sales Organization can supply Materials to Customers through this Distribution Channel.
IMG -> Enterprise Structure -> Assignment -> Sales and Distribution > Assign distribution channel to sales organization
Maintaining Division
Division is a way of grouping materials, products, or services.
IMG -> Enterprise Structure -> Definition -> Logistics - General -> Define, copy, delete, check division
Assigning Division to Sales Organization
IMG -> Enterprise Structure -> Assignment -> Sales and Distribution -> Assign division to sales organization
Setting up Sales Area
All the sales are made from a particular sales Area. For creating a Sales Order Sales Area is compulsory.
IMG ->Enterprise Structure -> Assignment -> Sales and Distribution -> Set up sales area
Assigning Sales Organization- Distribution Channel- Plant
Plant is created by MM Consultant.
IMG -> Enterprise Structure -> Assignment -> Sales and Distribution -> Assign sales organization - distribution channel - plant
Define Shipping Points
Shipping Point is the Organizational element, which is responsible for shipping the Materials to the Customers.
IMG -> Enterprise Structure -> Definition -> Logistics Execution -> Define, copy, delete, check shipping point
Assigning Shipping Point to Plant
This assignment ensures that goods from different Plant can be dispatched from different Shipping Points.
IMG -> Enterprise Structure -> Assignment -> Logistics Execution -> Assign shipping point to plant
Note: Ensure to do the under mentioned configuration also though it is not in Customizing node of Enterprise Structure.
Defining Common Distribution Channels for Master Data Use
The purpose of this activity is to define distribution channels which have common master data..
Procedure
Access the activity using one of the following navigation options:
IMG Menu -> Sales and Distribution -> Master Data -> Define Common Distribution Channels
Transaction Code: VOR1
Defining Common Divisions for Master DataUse
The purpose of this activity is to define distribution channels which have common master data..
Procedure
Access the activity using one of the following navigation options:
IMG Menu -> Sales and Distribution -> Master Data -> Define Common Division
Transaction Code: VOR2

Enterprise Structure Configuration

Order to Cash Cycle

By Nageshwar

A customer orders some items from your company by creating a sales order (Tcodes: VA01, VA02, VA03, Tables: VBAK, VBAP etc).

Your company decides to deliver the items ordered by the customer. This is recorded by creating a outbound delivery document (TCodes:VL01N, VL02N, VL03N, Tables: LIKP, LIPS etc).

Once the items are available for sending to the customer, you post goods issue which reduces your inventory and puts the delivery in transit. This will create a material document. You will post goods issue using VL02N but the material document created will be stored in tables MKPF, MSEG.

You will then create shipment document to actually ship the items. (Tcodes: VT01N, VT02N, VT03N, Tables: VTTK, VTTP etc).

You finally create a sales billing document. (TCodes: VF01, VF02, VF03, Tables: VBRK, VBRP etc). This will have a corresponding accounting document created that will be in BKPF, BSEG tables.

When customer pays to your invoice, it will directly hit your AR account in FI.

You will have to remember that these are not a required sequence. Some times, you may configure your system to create a SD invoice as soon as you create a sales order or you may not create a shipping document at all. This is the position where Functional Consultant would come into picture and study the company's order to cash process and configure the SAP system to do so.

Order to Cash Cycle

Differences between Cash Sales and Rush Order

By Ayub

Cash Sales: In this type of order CS, as soon as you save the sales order the delivery is automatically created as same date and billing will also be generated at the same date as soon as you save the delivery document.

In a rush order, the customer picks up the goods immediately, or you deliver them on the same day as when the order was created. When you save the rush order, a delivery is automatically created in the standard system. Billing the rush order takes place as normal, after the delivery.
In the standard system, sales document type RO is saved for rush orders with immediate delivery type LF. Once the goods have been removed from storage, the goods are picked, and goods issue is posted. Once the billing documents are created (for example, in collective processing), invoice papers are printed and sent to the customer.

Rush Order: In this type of Order RO , The delivery will be created as soon as you save the sales order. But you bill the customer later.

In cash sales, you can process an order for when the customer orders the goods, picks them up, and pays for them immediately. The delivery is processed at the same time as when the order is created and a cash invoice is printed immediately: billing is therefore related to the order, unlike rush and standard orders. Receivables are not created for the customer, as they are for rush and standard orders because the amount in the invoice is immediately posted to a cash account.
In the standard system, sales document type BV (CS) is saved for cash sales with immediate delivery type BV.
When the sales employee creates a cash sale, the system automatically proposes the current date as the date for delivery and billing. Once the order has been posted, a delivery with type BV is created immediately in the background and the system prints a document that is used as an invoice for the customer. The invoice papers are controlled with output type RD03, contained in the output determination procedure for order type CS.

Differences between Cash Sales and Rush Order

Configuring credit card for the orders

By Genildo

To implement the credit card functionality in SAP, do the following:

Go to transaction VOV8.

Select the required order type and double-click on the same.

Scroll-down the window to find the following fields:

In the highlighted section above, we mention the payment type. In the "Paymt card plan type" select the value "03 (Payment card)" or use F4 functionality to select the same. Here are the F4 values:

In the checking group, enter the value "01(Standard)".

Configuring credit card for the orders

Differences between Credit Note, Credit Memo and Credit for returns

By Genildo

Credit Note, Credit Memo and Credit for returns are all the same and used interchangeably. In general, Credit Note and Credit Memo are used to pass the credit to the customer if they are charged too much.

"Credit for Returns" is used to return the amount to the customer when the defective products are returned, or a complaint is made about a service performed.

Differences between Credit Note, Credit Memo and Credit for returns

Extending/Reducing the credit limit for a specific period

By Subramanya

Go to transaction OVA8

Select the required record and click on “Change”. Following screen appears:

As noticed in the above screen, we can maintain the percentage by which the credit limit should be either extended/reduced and also can provide the period for which it is applicable. Following is the F1 help screenshot of the same:

Following is the screenshot after entering some values in the “Credit Limit Seasonal Factor”:

Extending/Reducing the credit limit for a specific period

Maintaining Shipping instructions

By Virender Varma

Shipment Instructions are used to instruct the carriers or forwarders or drivers anybody who actually would be shipping your goods from your warehouse to the customer's site. This instructions could be asking the driver to Handle the goods with care or might be instructing him to make sure the delivery is at the customer premises by so and so date and time or once the delivery is handed over to the customer taking a receipt signature from the customer.

Example if you order something from a store , after the goods are shipped to you the driver takes a signature on a receipt note or collects the check or cash form you or takes the inspection done signature, this is the shipping instructions for the driver.

Shipping instructions are maintained in the delivery document itself (Transaction VL01N).

In the delivery document, click on GOTO-->Header-->Text

Here we can maintain the shipping instructions.

Maintaining Shipping instructions

MRP: PR to PO Conversion

By Aparna

Go to Transaction SU3 and under Parameters Tab find the Parameter ID "EVO" and check if any value is assigned. If so, make a note of the value.

Now go to transaction SPRO

Click on SAP Reference IMG -> Material Management -> Consumption-Based Planning -> Procurement Proposals --> Define Conversion of Purchase Requisition into Purchase Order (as shown below)

Following screen appears:

Check for the value we have noted earlier (the value of the parameter EVO in SU3). Select the read and check the check boxes appropriately. We have to select at least one of the check boxes from RefPRs or A/P PR to have all all items copied to PO. Please use the F1 help for detailed information on the check boxes.

MRP: PR to PO Conversion

Understanding Material Determination

By Tejaswini

Material Determination is a technique to determine the material to be used in the Sales Order. For e.g.,

Substituting one Material to another in the Sales Order.
Special gift-wrapping of a material for a festive season.
Swapping customer’s material number to our own material number.

To configure the Material Determination:

Go to SPRO -> Reference IMG -> Sales and Distribution -> Basic Functions -> Material Determination -> Maintain Prerequisites for Material Determination (As shown in the screenshot below):

Following screen appears:

We would go by step-by-step for the Material determination.

The first step is “Maintain field catalog”. This screen can also be accessed from the transaction OV26.

Field catalog contains fields used by the system to determine substitution materials in the Material Determination procedure. Click on “Maintain field catalog” in the screenshot above. Following screen appears:

For our demo purpose, we would work on only MATNR (Material Number). Scroll down the list to find the field MATNR.

Click on Backspace and come back to the main screen:

Click on “Display Condition tables”

Use F4 help to select a table.

Select 001 from the list and press Enter.

Following list appears:

For our demo purpose, we would go ahead with this condition table.

Go back to the earlier screen.

Now click on “Maintain access sequences”. Access sequence is a sequence of steps SAP follows in order to obtain the condition record.

Select A001 and click on “Accesses”

In the above screenshot, the first field “No” is the access number. The access number is the order in which the system will read the access sequence. For e.g., if the access numbers are 5,10,12,15 and 20, then the system would start with the lowest entry (in this case it is 5). It would proceed further to 10 if it is not able to process 5. If no record found, then no material determination would be carried out.

Select the record and click on Fields.

Now let us check out the Condition Types available. Go back to the earlier screen and click on “Define condition types”. Following screen appears:

Now let us check out the procedures configured in the system:

Select a procedure and click on control data.

Assigning Procedures to Sales Document Types:

In this step, we would assign the above procedure to Sales Order document type.

Go to Transaction OV14 or go to Transaction SPRO -> Reference IMG -> Sales and Distribution -> Basic Functions -> Material Determination -> Assign Procedures to Sales Document Types (As shown in the screenshot below)