What is IDOC?

IDOC is simply a data container used to exchange information between any two processes that can understand the syntax and semantics of the data.

In simple words , an idoc is like a data file with a specified format which is exchanged between 2 systems which know how to interpret that data.

IDOC stands for ” Intermediate Document”

When we execute an outbound ALE or EDI Process, an IDOC is created.In an inbound ALE or EDI process, an IDOC serves as input to create an application document.In the SAP System, IDOCs are stored in database.Every IDOC has an unique number(within a client).

IDOCs are based on EDI standards, ANSI ASC X12 and EDIFACT. In case of any conflict in data size, it adopts one with greater length. IDOCs are independent of the direction of data exchange e.g. ORDERS01 : Purchasing module : Inbound and Outbound.IDOCs can be viewed in a text editor. Data is stored in character format instead of binary format.IDOCs are independent of the sending and receiving systems.(SAP-to-SAP as well as Non-SAP)

Different between ALE, IDOC and BAPI

ALE

ALE is SAP proprietary technology that enables data communications between two or more SAP R/3 systems and/or R/3 and external systems. When a new enterprise resource planning (ERP) solution such as R/3 is implemented, companies have to interface the ERP system with legacy systems or other ERP systems.

ALE provides intelligent mechanisms where by clients can achieve integration as well as distribution of applications and data.

ALE technology facilitates rapid application prototyping and application interface development, thus reducing implementation time.

The ALE components are inherently integrated with SAP applications and are robust, leading to a highly reliable system.

ALE comes with application distribution/integration scenarios as well as a set of tools, programs, data definitions, and methodologies that you can easily configure to get an interface up and running.

BAPI

BAPIs provide a stable, standardized method for third-party applications and components to integrate into the Business Framework. These interfaces are being specified as part of SAP's initiative with customers, partners and leading standards organizations. Also, SAP has implemented the emerging Object Application Group (OAG) specifications with BAPIs.

The interface concept of the classic R/3 is based on two different strategies: Remote Function Calls (RFC) and data exchange through IDoc message documents. RFC makes direct and synchronous calls of a program in the remote system. If the caller is an external program it will call an RFC-enabled function in R/3 and if the calling program is the R/3 system it will call an
RFC-function in another R/3-system or it will call a non-R/3 program through a gateway-proxy (usually rfcexec.exe). BAPIs are a subset of the RFC-enabled function modules, especially designed as Application Programming Interface (API) to the SAP business object, or in other words: are function modules officially released by SAP to be called from external programs.

IDocs are text encoded documents with a rigid structure that are used to exchange data between R/3 and a foreign system. Instead of calling a program in the destination system directly, the data is first packed into an IDoc and then sent to the receiving system, where it is analyzed and properly processed. Therefore an IDoc data exchange is always an
asynchronous process. The significant difference between simple RFC-calls and IDoc data exchange is the fact, that every action performed on IDocs are protocolled by R/3 and IDocs can be reprocessed if an error occurred in one of the message steps.

While IDocs have to be understood as a data exchange protocol, EDI and ALE are typical use cases for IDocs. R/3 uses IDocs for both EDI and ALE to deliver data to the receiving system. ALE is basically the scheduling mechanism that defines when and between which partners and what kind of data will be exchanged on a regular or event triggered basis. Such a set-up is called an ALE-scenario.

The philosophical difference between EDI and ALE can be pinned as follows: If we send data to an external partner, we generally speak of EDI, while ALE is a mechanism to reliable replicate data between trusting systems to store a redundant copy of the IDoc data. The difference is made clear, when we think of a purchase order that is sent as an IDoc. If we send the purchase order to a supplier then the supplier will store the purchase order as a sales order. However, if we send the purchase order via ALE to another R/3 system, then the receiving system will store the purchase order also as a purchase order

IDOC

IDoc (for intermediate document) is a standard data structure for electronic data interchange (EDI) between application programs written for the popular SAP business system or between an SAP application and an external program. IDocs serve as the vehicle for data transfer in SAP's Application Link Enabling (ALE) system.

IDocs are used for asynchronous transactions: Each IDoc generated exists as a self-contained text file that can then be transmitted to the requesting workstation without connecting to the central database.

Another SAP mechanism, the Business Application Programming Interface (BAPI) is used for synchronous transactions.
A large enterprise's networked computing environment is likely to connect many geographically distributed computers to the main database. These computers are likely to use different hardware and/or operating system platforms. An IDoc encapsulates data so that it can be exchanged between different systems without conversion from one format to another.

IDoc types define different categories of data, such as purchase orders or invoices, which may then be broken down into more specific categories called message types. Greater specificity means that an IDoc type is capable of storing only the data required for a particular transaction, which increases efficiency and decreases resource demands.

An IDoc can be generated at any point in a transaction process. For example, during a shipping transaction process, an IDoc may be generated that includes the data fields required to print a shipping manifest. After a user performs an SAP transaction, one or more IDocs are generated in the sending database and passed to the ALE communication layer. The communication
layer performs a Remote Function Call (RFC), using the port definition and RFC destination specified by the customer model

SD User exits

Comment:

SAP creates customer exits for specific programs, screens and menus within standard SAP system. There four type of exits in SAP: Menu Exits, Screen Exits, Function Module Exits, and Field Exits.

There are mainly two reasons why we need to use user exits in SAP System:

1. We should use them because they do not affect the SAP source code but still allow us to change the functionality of SAP to suit user requirements. SAP has provides us with some standards user exits that we should modify by adding our own functionality to them. The code and screens we created are encapsulated as separated objects.
2. And since, they do not affect the source code and are named as per SAP naming conventions; they do affect future software upgrades. Hence we do not to save them and then reenter add-ons attached exits.

We can only use SAP customer exits if they already exist within the SAP R/3 system. In case we do not find a suitable exit for an area where we would want to make a change, then we should request SAP to develop a user exit.

A user exit is a place in a software program where a customer can arrange for their own tailor-made program to be called. In R/3, some user exits use Include statements to include customer program enhancements that are called from the program. Other user exits use tables that are accessed through customization.

User exits (Function module exits) are exits developed by SAP. The exit is implemented as a call to a function module. The code for the function module is written by the developer. You are not writing the code directly in the function module, but in the include that is implemented in the function module.

The naming standard of function modules for function module exits is:
EXIT_<3 digit suffix>

The call to a function module exit is implemented as:
CALL CUSTOMER.-FUNCTION <3 digit suffix>

Sales related exits

Customer exits (CMOD transaction)

Enhancement code	Description
SDAPO001	Activating Sourcing Sub item Quantity Propagation
SDTRM001	Reschedule schedule lines without a new ATP check
V45A0001	Determine alternative materials for product selection
V45A0002	Predefine sold-to party in sales document
V45A0003	Collector for customer function modulepool MV45A
V45A0004	Copy packing proposal
V45E0001	Update the purchase order from the sales order
V45E0002	Data transfer in procurement elements (PRreq., assembly)
V45L0001	SD component supplier processing (customer enhancements)
V45P0001	SD customer function for cross-company code sales
V45S0001	Update sales document from configuration
V45S0003	MRP-relevance for incomplete configuration
V45S0004	Effective type in sales order
V45W0001	SD Service Management: Forward Contract Data to Item
V46H0001	SD Customer functions for resource-related billing
V60F0001	SD Billing plan (customer enhancement) diff. to billing plan

Include routines reserved for customers (need a modification key)

Include	Description
MV45ATZZ	For entering metadata for sales document processing
MV45AOZZ	For entering additional installation-specific modules for sales document processing which are called up by the screen and run under PBO (Process Before Output) prior to output of the screen.
MV45AIZZ	For entering additional installation-specific modules for sales document processing. These are called up by the screen and run under PAI (Process After Input) after data input (for example, data validation).
MV45AFZZ and MV45EFZ1	For entering installation-specific FORM routines and for using user exits, which may be required and can be used if necessary.

SD Process Flow

1. Inquiry (VA11)

2. Quotation / Contracts / Scheduling Agreements (VA21)

3. Sales Order (VA01)

4. Delivery

a) Create Delivery (VL01N)

b) Picking (LT03)

c) Picking Confirmation (LT12)

d) Packing (Optional in VL02N)

e) Post Goods issue (VL02N)

5. Billing(=Invoice) (VF01)

6. Post Incoming Payment (F-28)

MRP Procedures

Material requirements planning

Master production scheduling

Consumption based planning

Material requirements planning

1.It uses current and future sales figures.

2.The system calculates the requirements based on the warehouse stock, receipts, etc.

3.If externally procured then procurement proposals; if internal production then it leads to creation of planned orders, and also dependent requirements are calculated.

4.The best thing about this is that it leads to minimization of inventory, which leads to reduction of costs involved.

Master production scheduling

1.It is for used specifically for critical resources.

2.A separate run occurs for the MPS items, they are not included in the MRP run.

3.Basically, it ensures the availability of the critical resources which should not hamper the production by maintaining the stock

4.It also provides the facility to work on the production plan interactiv

Consumption based planning

1.It uses the past consumption data to calculate the future requirements.

2.It has no relation with the independent or dependent requirement instead it is triggered when the stock falls below the reorder point or by forecast requirements.It has three types of MRP procedures:

•Re-order point planning.

•Forecast based planning.

•Time phased planning.

Re-order Point Planning

•Procurement is triggered when the sum of plant stock and firmed receipts fall below the reorder point.

•Reorder point covers the material requirements during replenishment lead time.

•The safety stock takes care of both excess material consumption within the replenishment lead time and any additional requirements that may occur due to delivery delays

Re-order Point Planning

Re-order point is defined by :-

•Safety stock

•Replenishment lead time.

•Average consumption.Safety stock is defined by :

•Past consumption data.

•Vendor/ production delivery timelines.

•Service level.

•Forecast error.

Re-order Point Planning

•Manual Reorder point planningFormula=(procurement processing time+planned delivery time+GR processing time) + Safety stock

•Automatic reorder point planning

Forecast based planning

•It is also based on historical data, or the past material consumption data.

•Here the forecast values form the basis of the planning run.

•Based on the consumption pattern the system changes the forecast requirements for future.

Time phased planning

1.This is used specially in case if the planning cycle is known.

2.The materials planned using this is given an MRP date in the planning file.

3.This date is set when creating the material

ATP (Available to Promise)

1.During ATP, the system checks that all issues are covered by existing receipts
2.Hence, if any quantities are left to cater new issues. This is ATPQuantity

ATP (Available to Promise)
It can be done at various stages, in the business:
At Sales and distributionWhen creating the Sales order, availability check is carried to know whether the delivery can be done at the required date.

Planned order processingWhen converting a planned order into a production order, to know the material availability to fulfill the production order.
Production order processingWhen processing production orders, to know the material availability.

Inventory ManagementWhen changing reservations, or doing goods issue, an availability check can be done to know whether it can fulfill the requirement and also whether it affects the availability of other elements

ATP calculation is as follows:The receipts (warehouse stock, planned orders, purchase requisitions) are dynamically allocated to the issues (customer requirements, PIR’s, reservations), which lie directly after them on the time axis. The calculation is carried out in such a way that the issue is allocated to the receipt that lies nearest to it and that still has a positive ATP quantity.If the ATP quantity of this receipt does not cover the issue then the system will search for and check the next nearest receipt (always in a backwards direction) for a positive ATP quantity, which will then also be allocated to the issue.If receipts do not cover the issue, you must then decide whether you reduce the requirements quantity as necessary or whether you move the requirements date so that requirements coverage can be reached again.


Availability Check at Plant Level
Availability Check at Storage Location Level
Availability Check at Batch Level
If only one batch is entered, the check is carried out on two levels, first against the batch and then against the plant stock.
If a batch and a storage location are entered, the check is carried out on four levels, first against the batch storage loc ation, then against the batch, the storage location and the plant stock.
Availability Check for Individual Customer Stocks and Project Stocks
Individual customer stocks and project stocks are maintained separately in the system and are not contained in plant stock. If an issue is made from individual customer stock or project stock, the availability is checked only for this particular customer stock.

SAP SD Returns Process and Settings

Comment:

RETURNS PROCESS IN SAP
Sales Returns: Sales Returns is a process where in a customer sends the material back to the supplier, generally when the material is found to be defective.
Returns Document: In SAP a Sales Returns Document is created either with respect to Invoice or the actual Sales Order.
Transaction Flow: Invoice / Sales Order ® Returns Order ® Returns Delivery ® Post Goods Receipt [PGR].
DOCUMENT TYPE SETTINGS - IMG
Path: IMG ® SD ® Sales ® Sales Documents ® Sales Document Header ® Define Sales Document Type
T-Code: VOV8
Standard Document Type: RE -Returns Sales Document
Table: TVAK : Document Type - AUART [Field]
RE document Settings
SD Document Category : H - Returns
Transaction Group : 0 - Order
Screen Sequence Group : RE - Returns
Incompletion Procedure : 14 - Credit Memo
Delivery Type : LR - Returns Delivery
Delivery Related Billing Type : RE - Credit for Returns
Order Related Billing Type: RE - Credit for Returns
Billing Block : 08 - Check Credit Memo
Propose Delivery Date : Activated
ITEM CATEGORY - IMG
Path: IMG ® SD ® Sales ® Sales Documents ® Sales Document Item ® Define Item Categories
Transaction Code: VOV7
Standard Item Category: REN - Returns Item Category
Table : TVAP : Item Category - PSTYV [Field]
REN item category settings:

Pricing : X - Pricing StandardBilling : B - Order related Billing, status according to order quantity.
Returns : Activated
Credit : De-activated
Schedule Lines : Activated
Wt/Vol : Activated
Determine Cost : Activated
Business Item : De-activated
SCHEDULE LINE CATEGORY - IMG
Path : IMG ® SD ® Sales ® Sales Documents ® Schedule Lines ® Define Schedule Line Categories
T-Code : VOV6
Standard Schedule Line Category : DN - Returns Item Category
Table : TVEP : Schedule Line Category - ETTYP [Field]
DN Settings
Movement Type : 651 - Goods Return Delivery. This will enable the stock value and quantity to go up in Inventory Accounting.
Item Rel. for Delivery : Activated

Incomplete. Procedure : 30 - Delivery Relevant Schedule Line.

Credit Memo: (Order Type: G2) (Item Category: G2N)

A credit memo request is a sales doc used in complaints processing to request a credit for a customer.
The credit proc generally follows 2 business procedures; the first being the scenario where the customer returns products previously purchased & requires a credit. The second general form of credit proc is when the customer is credit without ref to a return (goods not returned or customer overcharged).

You can also set a mandatory that the credit memo request can only be created with ref. You can create a credit or debit memo request with ref to an existing order, with ref to an existing order, with ref to an invoice, with ref to contracts, contract release orders, billing doc.
You may not wish to credit for every thing, such as the entire freight charge from one invoice. You can instead have a new pricing proc in the credit memo request that is similar to the standard pricing proc you use, but not have the freight condition type. Thus the standard values are copied over, excluding freigh

Returns:(Order Type: RE) (Item Category: REN)

A return is a sales document used in complaints processing for when a customer sends goods back. You can create the return in one of the following ways: without ref to an order, with ref to an invoice, with ref to contracts, contract release orders, billing doc.
It may be worthwhile ensuring the return order reason was entered on the sales doc. Thus, it may be necessary to add this in an incompletion proc.
It is advisable to indicate a shipping cond that is specifically used for returns. This is useful when running del due list.

Free of Charge Subsequent Delivery:

(Order Type: SDF) (Item Category: KLN)

To create a free of charge subsequent delivery, you have to refer to an existing sales doc, such as: sales orders, contracts, contracts release orders.
You do not have to use create with ref to free of charge subsequent deliveries, if you enter the order type & choose enter, a dialog box will appear where you can enter the no of the order to which you are referring. No invoice is created or necessary, as the items are free.

Free of Charge Delivery: (Doc Type: CD)

-VA01
-VL01N
-LT03
-VL02N
-When you create a free of charge delivery you must enter a value in the order reason field or the system informs you that the doc is incomplete.

Invoice Correction Request:

A sales doc used in complaints processing to correct the quantity or price of one or more items in an invoice.
Each invoice correction request that is made in ref to an invoice contains 2 items for each item in the invoice (you cannot create an invoice correction request in ref to a sales or delivery doc type), viz First- credit item & Second Debit item. These contains the same value and quantity. The first item is the copied value & quantity copied from the invoice, this item appears as credit item. The second item is the debit item, which represents the correct quantity &/ or the value.
If you want the system to generate a credit memo for a +ve amount, and a debit memo for a -ve amount, you need to set an additional sales document type in customizing, for e.g., ZRK1 (invoice correction request for debit memos). You can change these settings in customizing under Sales ® Sales Document ® Sales Document Header ® Define Sales Doc Types in the “Sales Catalog Field”.
If the invoice correction request is characterized as a credit memo request, that is, the doc type RK has the characteristic as ‘K’ in the sales doc catalog field & has order related billing assigned to it in the form of G2 or credit memo, the system creates a credit memo for +ve value. For debit memo the characteristic will be ‘L’ & has order related billing assigned to it in the form of L2, the system creates a debit memo for a -ve value.
-You create invoice correction request with ref to an invoice.
-Price 100
o 110: credit memo
o 90: debit memo
-VA01: (Order Type: RK) with ref to invoice
-VF01: automatic credit or debit memo.

Debit Memo Request:

(Order Type: L2) & (Item Category: L2N)

A debit memo request is a sales document used in complaints processing to request debit for a customer. You can create a debit memo request if the prices calculated for the customer were to low. Remove the Billing Block.
-VA01: debit memo request with reference to invoice or order
-VF01: debit memo

SD returns For Damaged Replacement:

-VA01: free of charge subsequent delivery (SDF) with ref to sales order
-VL01N
-LT03
-VL02N

Sd returns Customer Does Not Send the Goods Back

-If the customer wants a replacement product, you create a free of charge subsequent delivery with ref to sales order
-If the customer wants a refund, you enter a credit memo request, with ref to the sales order or invoice.
-VA01: credit memo request (G2) or free of charge subsequent delivery (SDF) with ref to sales order. For SDF there will be delivery, picking, goods issue.
-VF01: invoice

SD returns Customer Wants Replacement

If the customer wants replacement product, enter a free of charge subsequent delivery with ref to the return.
-VA01: (Order Type: RE) with reference to Sales Order.
-VL01N: Return Delivery
-VL09: Goods Reversal
-VA01: Free of charge Subsequent Delivery (Order Type: SDF)
-VL01N: delivery
-LT03: picking
-VL02N: goods issue

SD returns Customer Wants Refund For the Amount:

-VA01: (Order Type: RE), (Item Category: REN), (with ref to sales order)
-VL01N: Return Delivery
-VL09: Goods Reversal
-VA01: Credit Memo Request (Order Type: G2), (Item Category: G2N), (with ref to Return Order, please remove billing block)
-VF01: Credit memo.
-If the customer wants refund for the amount, enter a credit memo with ref to the return

Customer Returns the Goods:

-VA01: Return Order (Order Type: RE) (Item Category: REN) & enter, Create Return Order with ref to Sales Order No. Give order no & click on Copy (F5) and change the order quantity say from 50 boxes to 20 boxes.
-VL01N: Return Delivery
-VL09: Goods Reversal.

Incompletness Procedure in SD

Comment:

In completion Log
You can define when a sales document or sales activities are incomplete in the system for following data and also define how system to react in each case.

Sales document header

Sales document Item

Sales document schedule line data

Sales activity

Partner data in sales & delivery documents and sales activities

Delivery header and delivery item data
1)Define status group:

(Menu Path : SPRO-IMG-SD-Basic function-Log of incomplete items-define status group-)

You can define status group for your requirement to define status of incomplete documents and it is to be assigned in incompleteness procedures. If possible copy existing status group and change according to your requirement. You may also define which function to be carried for incomplete documents and can make settings to block documents for pricing, delivery, Picking, PGI billing etc.
2) Define Incompleteness procedure
(Menu Path: SPRO- IMG- Sales and distribution-Basic function-Log of incomplete items -define incompleteness procedure) T code OVA2
Select a status group of your requirement -selects procedure for the status group-select field and double click on required document type-You can enter required data in T-code -OVA2
It is recommended that you copy standard incompleteness procedure and make necessary changes. You also make setting to for warning message on incomplete data of the system.
3) Assign Incompleteness procedures

(Menu Path: SPRO-IMG-SD-Basic function-Log of incomplete items-assign incomplete)

T-Code VUA2
Select the object you want to assign incompleteness procedure and assign appropriate incompleteness procedure in T-code VUA2.You can also indicate that system should save the incomplete document or not.

SD contract Transaction Code

[VA41] or [Sales and Distribution -> Sales -> Contract -> Create ]. Enter the contract type from the drop downs. The typical contract document types in a standard IDES system are

GK - Master Contract

QC - Quantity Contract

QP - Rental Contract

Wk1 - Value Contract

WK2 - Material relevant value contract

SC - Service and Maintenance Contract etc

SD contracts Types

Quantity Contract

A quantity contract is an agreement to supply a fixed quantity over a period of time. Since the customer promises to buy the fixed quantity of goods/services, they will get a discounted price.

The document type in SAP for quantity contract is QC. For example, in this example, the quantity contract is for quantity 100 of say material M-01. Release orders are orders created with reference to the contract to consume the quantities in the contract. So the first release order is for quantity 20 which consumes 20 % of the quantity in the contract. Similarly, the rest of the release orders consume the remaining quantity in the contract. Document flows should exist between the contract and the release order types. There are 2 primary reasons why quantity contracts are used.

1. When Quantity is Limited - When the production quantities are limited in numbers, then customers are allocated a specific quantity by time -period ( say a month, or a quarter ) . And customers cannot place ad-hoc orders, but have to first sign a contract for a fixed quantity and always order via release orders that specifically refer to the contract.
2. When Vendors want to Lock-in Customer quantities - Some times to give deep discounts, sales folks require that customers commit to buying a fixed quantity over a time-period. This satisfies the sales figures .

Service Contract

A service contract is normally created for service-oriented items - examples are annual service contracts, annual maintenance contracts.

For example, when you buy an internet connection from comcast, they are providing services to you for a fixed period - say 1 year or 6 months. And for providing those services, they charge you monthly. In this case, there are no release orders because in case of service since there are no logistics operations, directly the customers are invoiced with reference to the contract. In this case, the customer is charged $100 a month for 12 months with a total of $1200. The items in these types of contracts follow billing-plan. Repairs also follow service contract methodology.

Master Contract

A master contract is used when a particular type of contract is created regularly for a customer and you want all the header data to be consistent across all of the contracts. Normally, the header data of a sales document contains data from the Customer master.

For example, if a contract is created for a customer say 1400, key data like inco-terms, payment terms, delivery preferences, taxability etc flow from the customer master data for that sales area for customer 1400. However, if you consistently change the data in the contract to a fixed value, say the inco-terms should always be FOB Destination for all contracts, while regular sales order have CIP Philadelphia, you can create a master contract for customer 1400 and change the inco-terms in the master contract to FOB Destination. All subsequent contracts that refer to this master contract will have the inco terms as FOB Destination.

Value Contract

A value contract is very similar to a quantity contract - except that instead of a fixed quantity, the value of the contract is fixed ( ie the dollar amount of the contract is fixed ) while the materials that the customers procure could come from either a fixed basket of materials or a single material only.

For example, in the example shown above, the type of contract is a value contract for a specific material - 'WK2'. Essentially, this contract is limiting the value of the contract to a fixed dollar value and the customer can release multiple release-orders referring to the value contract for that specific material. If the customer wants to create contracts for specific value and not limit them to a particular material, then an assortment module can be used. The type of value contract that refers to an assortment module is 'WK1'.

An assortment module is a basket of materials ( a fixed set of materials ) without any specific quantities or prices. When some of the materials in the assortment module needs to be used in the value contract, the assortment module is searched for ( by name or number ) and the materials in the assortment module are selected and quantities specified. Price can be either manually specified or automatically done. We will discuss more on this during the configuration section.

SD contracts

Contracts are agreements between the Customer and Vendor to supply materials/services for a specific price between a fixed period of time. Many possible types of contracts exists based on the types of contracts. For example, there are maintenance contracts, service contracts, quantity contracts, value contracts all of which we will be discussing over the course of this article. The bottom line however remains the same - A contract is an agreement between the Customer and vendor to supply goods/materials/services of specific quantity/value for a specific price over a specified period. Let's discuss the different types of contracts.

Consignment order steps

In consignment orders you are allowing the stock to sit in your customer location. Once he informs that he used the stock you will invoice him. If he returns the stock you will accept the stock to take it back.

It is defined in 4 steps.

Step 1:

Consignment fill up:
Sales document type is KB
Item category KBN
schedule line category E1

In this step, you are not invoicing the customer. document flow is sales order ---- delivery item category. It will not be relevant for billing and pricing because you are not charging money for these goods in this step.

In schedule line category, you will set movement type 631 & set for availability check and TOR.

Step 2:

Consignment Issue.
Once the customer informed you that he used all the goods or partial goods then you will create consignment issue for used goods.

Sales document: KE
Item category: KEN
schedule line category: C0 or C1

Here you are invoicing the customer(because he used the goods). you are assigning the delivery document and billing document to the sales document.

In item category, you are setting relevant for billing, pricing, special stock.

In schedule line category, your setting is 633 movement type, relevant for availability check & TOR.

Step 3:

Consignment Return:
Customer found that some goods are damaged or he not able to sold the goods he want to send it back. that you are creating this document.

Sales document type: KR
Item category: KRN
Schedule line category: D0

You will assign delivery document and billing to sales document. you will create return order, return delivery, return billing.
Your setting item category relevant for billing, returns, pricing, special stock.
Your setting schedule line item category: 634 movement type, NO availability NO TOR.

Step 4:

Consignment Pick up:
Even if you create the consignment return the goods are not come to direct to your plant. For that you need to create consignment pick up. here the owner ship is not changing so you do not need to create billing.
Assign return delivery to sales document type.

Sales document: KA
Item category: KAN
schedule line category: F0 & F1

Your setting item category relevant for returns. any schedule line category relevant for 632 movement type, MRP, availability check, delivery.

Consignment Sales Process in SAP

Consignment fillup (send materials to customer consignment).
Here you have a consignment fillup order and a consignment fillup delivery.

Consignment issue (issue materials from customer consignment to the customer).
Here you have a consignment issue order, consignment issue delivery and a consignment issue invoice. (the flow is very similar to a normal OR flow, but the materials are issued from the consignment stock instead of plant stock unrestricted).

Consignment return (return materials from customer ownership to customer consignment).
Here you have a consignment return order, consignment return delivery and a consignment return invoice. (the flow is very similar to a normal RE flow, but the materials are returned to the consignment stock instead of plant stock returns).

Consignment pickup (pickup consignment stock and move it to plant stock).
Here you have a consignment pickup order and a consignment pickup delivery.

Note that in consignment fillup and consignment pickup there are no invoices since there is no change of ownership for the materials.

New GL Concepts and advantages

New GL Concepts

Leading and Non-Leading Leger maintenance
Document Splitting
Segments and Segment Reporting
Parallel Valuation
Migration from Classic GL to New GL

Advantages

1. The new General Ledger in mySAP ERP 2004 has the following advantages over the classic General Ledger in R/3 Enterprise:

a) In the new General Ledger, you can display the parallel accounting using parallel accounts (as in R/3) or using parallel ledgers. The FI standard functions and reports are available for all parallel ledgers.
b) The ‘Segment’ entity and the relevant reporting that are required for segment reporting according to IAS and U.S. GAAP are available in the new General Ledger.
c) In addition, you can enhance the new General Ledger flexibly, that is, you can enter user-defined fields and update the relevant totals. Many standard reports can evaluate the information from the user-defined fields.
d) When you use the new ‘Document Splitting’ function (online split), you can create financial statements at company code level and, if required, for entities, such as the segment. For each document, the system then creates a zero balance for the relevant entity, for example, for the segment.
e) As a result, you no longer have to carry out time-consuming reconciliation tasks between FI and CO for the end of period since cross-entity processes are transferred in real-time to the new General Ledger in Controlling. Furthermore, you can, for example, navigate from the financial statements report results or the profit and loss statement report results to the relevant CO report.
f) The new General Ledger uses the same interfaces as the General Ledger in R/3. As a result, users do not require any additional training.
g) Due to the new ‘multi-dimensional’ aspect in the General Ledger, all data that is relevant for the General Ledger is stored in one environment. As a result, reconciliation tasks, for example, between the general ledger and Profit Center Accounting or the consolidation staging ledger, and processing steps that have to be carried out repeatedly in the individual applications (for example, balance carryforward) are no longer required. When you use the new General Ledger, you may not have to use the special ledger anymore.

2. Default delivery

In new installations, the new General Ledger Accounting is activated by default in mySAP ERP. We do not recommend that new customers use the classic general ledger accounting since using the classic general ledger accounting requires additional migrations at a later stage. As a result, new customers require explicit authorization from SAP to use the classic general ledger accounting. If you want to use the classic general ledger accounting. create and send a CSS message to SAP before you start using the system.
When you upgrade an R/3 system to mySAP ERP, the classic General Ledger remains active at first. If you want to convert your system to the new General Ledger, you can do so within a project after you have completed the upgrade. For more information about this topic, see point 3.

3. Migration support

To ensure maximum security, SAP supports each migration project with a migration service. This basic technical service is based on standard migration scenarios and is provided in the form of migration packages for a fixed price. This service is provided by a NewGL migration back office, which was set up for this purpose. After you commission the service, you are provided with a license key. This releases the migration functions.

Set up recurring entrie Run Frequency

Receive a requirement from user to set up recurring entries on weekly and fortnightly basis, do we have the option to set up Run Frequency on week and fortnight, as I could see only monthly.

Yes, there is a solution. You will have to perform three steps:

Step 1. Use transaction OBC1 and define the run schedule for e.g. TEST.

Step 2. Use transaction OBC2 and maintain run dates you want for the scedule defined above.

Step 3. Use transaction FBD1 to create recurring document and enter the Run Schedule you defined in step 1

Order to post the Recurring entry

In order to post the Recurring entry you can follow the following steps:

Step1. Tcode FKMT --> here you can create a Assignment model by Debiting your Expenses and Crediting your prepaid Account. (this is just a Templet so for and positing has not taken place)

step 2. Tcode FBD1 --> here you could recall the assignment model, specify the respective period of posting Example Start with 1st Nov XX end with 30 Nov XX for a period and specify the batch name.

Step 3. Tcode SM35 --> here you look for the batch name which you saved while you did step 2 and run the batch.

Step 4. Tcode FB03 --> see the postings if that has posted correctly by debiting the expenses account ( actual monthly figure not the yearly figure and credited the Prepaid account)

If you follow these steps, it should work as there is no configurations for Recurring entry, but for Manual Accruals there is config.

Create our own COA

The procedure is:

IMG side
1) Create Chart of acount (OB13)
2) Create account groups as per ur own list of GL's and give no range (OBD4)
3) Asign Chart of account to ur company code (OB62)
4) Define retained earning account (OB53)

After, for creation in Chart of account segment FSP0
- for Company code segment FSS0
- for central creation FS00

Group COA

A group chart of account is way to group your primary accounts. For example from an operation perspective you can have several cash accounts but from a group reporting perspective you might want to group all cash activity under one account. These are usually used for Consolidation reporting.

Alternative chart of accounts

Alternative chart of accounts is secondary grouping of account that is generally used for statuary reporting. For example you might have a company chart of account but due to statutory nature (for countries like Russia and China to name a few), you have to report your account activity in an account range that has been provided by the company stature. In this case you have a primary chart of account as explained above and alternative chart of account. Postings should always be made in the primary chart of account and in the GL account setup these primary accounts should be associated to alternative chart of accounts. This way updates can be made to both primary and alternative chart simultaneously.

Chart of Account Types

There can be only one primary chart of account per company code in SAP. You can have a different set of chart of account that can be used for Group Account and one for Alternative accounts.

Three types of Chart of Account .

1.Operative Chart of account
It is the COA you are opening for COA defines the Ledger account.

2.Country Chart of Account
You can use this COA for the legal requirement for the country specific.

3.Group of Chart of Account
Supposes for the same company , which uses different COA for their purposes, they can be grouped into Group of Chart of Accounts

Chart of accounts

Chart of accounts is a grouping of GL accounts that used to post transaction from cross modules and FI modules. These can be further used for reporting like Balance Sheet, P&L, and Trial Balance etc...Chart of accounts are usually very specific to an organization and you will not find the same chart of account across two different companies. SAP does give you standard set of accounts that can be used as template but it usually requires detail discussion with accounts so a list can be finalized.

Documeny Types and Number Ranges Config Tcodes

Documeny Types and Number Ranges                                    OBA7
System Lock                                                         SM12
Maintain field Staus Variant                                        OBC4
 Assign Company code to field status Variant                         OBC5
 Define Tollarance Group for Employees                               OBA4
 Tax Calculation Procedure ( Sales Tax Or VAT)                       OBBG
Global Paremeters                                                   OBY6
Creation of GL Masters                                              FS00
Genral Ledger Posting                                               F-02
 To View the Document                                                FB03
 Change Document                                                     FB02
To View the Ledger                                                  FS10N
How to make default Lay Out                                         FB00
Display changes to Master                                           FS04
Creation of Parked Document                                         F-65
Display Parked Documents pending for Approval and Release           FBVO
Display Changes to Parked Documents                                 FBV5
Define No Range internal for No Ranges                              FBN1
View the Samle Document                                             FBM3
Creation of Accural/Deffral Document                                FBS1
Reversal of Accral/Defferal Document                                F.81
Check the exchange rate type                                        OYO3
View Genral Ledger Account                                         FBL3N
Out Going Payment with Line Item                                    F-07
Individual Revesal                                                  FBO8
Mass Reversal`                                                      F.80
Cleared item Reversal                                               FBRA
Define interst Calculation Procedure                                OB46
Preparation Account balance interset calculation                    OBAA
Creation Vendor Master Centraley                                    XK01
Change Vendor Master                                                XK02
FI vedor Creation Master                                            Fk01
Creation of vendor account Group                                    OBk3
Create No. Ranges for Vendor Accounts                               XKN1
Define Tolerance Group for Vendors                                  OBA3
Define House Banks                                                  FI12
Creation Check Lots                                                 F11O,
FCH1 Purchase Invoice posting                                       F-43
 Out going payment clearing party Account                            F-53
Manuval Cheque Creation                                             FCH5
 Display Cheque Register                                             FCHN
Cheque encashment date updation                                     FCH6
Un issued Cheque Cancellation                                       FCH3
Create Cheque Void Reason Code                                      FCHV
Delation of Cheque encashment date                                  FCHG
Cancel Payment                                                      FCH8
View the Vendor line item Document                                  FBL1N
Link between Sundry Creditors and Advance to Vendors                OBYR
Assign Payment Programm to Company Code                             TO42
(Down) Advance Payment Posting (Special GL)                         F-48
Purchase Invoice posting                                            F-43
Clear the (Down) Payment Clearing (Special GL)                      F-54
Clear the Normal Items                                              F-44
Clear the Vendor Invoicess (Out going Payment)                      F-53
(Cash Discount Received) Define accounts for Cash Discount taken    OBXU

Profit center Accounting

Profit center Accounting
Maintain controling area settings                                   OK65
Creation of dumy profit center                                      KE59
Set control parameters for Actuval data                             1KEF
Define no ranges for local document                                 GB02
Creation of center                                                  KE51
Assign profit center in cost center                                 KS02
Maintain automatic Account assignment of revenue elements           OKB9
Choose additional balance sheet and Profit and loss account         3KEN
Planing profit center wise for profit and loss items                7KE1
Planing profit center wise for balance sheet account                7KE3
To view the profit center wise variance report for profit and loss iS_ALR_87013326
To view report for balace sheet accounts profit center wise         S_ALR_87012336
Transfer of sales from profit center to another profit center       9KE0