Billing IDOC

Hi All,
I have a requirement that :
Requires SD module to aupport the monthly billings of a system XYZ (it takes care of invoices of several subsystems)
requires customer, sales/transaction type, contract data and transactional data like applicable fee ,meter data etc as required by a billing interface to exist to the SAP SD module.
Can anybody conclude from the requirement that :
which transactiopn will be used to post the data into SAP? Which Idoctype and any other conclusions...? what exactly the contract data and transactional data signifies and how will it be related to billing document.
Plz help its urgent.
Thanks.

Hi,
IDoc type is <b>INVOIC01</b>
message type<b> INVOIC</b>
Regards
vijay

Similar Messages

ALE for Accounting (Billing- IDOC- Accounting(target sys))

Hi Gurus,
Here i have a situation,
source system: Up on creating a billing document it should generate a IDOC
Target system: The idoc Generated by the source system should be processed to create accounting document.
is this possible with ALE, Please help me. Most urgent.
****Points will be rewarded
Thanks in Advance.
Ak

hi ,
check one thing all the transactional data can be generated as idocs but not master data...billing document is a transactional data element so we can create it...and process it to the target system..
regards,
venkat.

Intercompany billing IDOc issue

Hi,
I am intercomapny purchase billing documents and intercomapny sales billing documents thropugh IDOC posting to generate automatic invocies.
All IDOCs for intercomapny purchase billing documents are going into error.
Error is : Enter a tax code in item 0000
while IDOCs for intercomapny sales are posting without any erro,
Can anyone help me with this..
Thansk

Are both the sales organizations involved in the inter-company transaction belongs to different countries ?
If so check your pricing procedures ..
Also check the pricing condition records for the billing doc thats missing the Tax code..
Regards,
Aj.

Intercompany Billing Idoc

Hi All,
We have been using idocs in order to process intercompany billing scenario.
SD Billing will be saved and automatic invoice verification should be posted on the other side.
Instead of posting, invoice verification document is getting parked.
Has anyone faced this problem before?
Thanks
Regards
Karan

Please check processing parameter used for EDI invoics (Txn (OLMR>EDI>Enter Program Parameters). Based on parameter used and difference in price or quantity, invoice is parked. If all invoices posted in EDI are posted as parked then please check the userexit EXIT_SAPLMRMH_014. Please check note 501524.

Intercompany billing IDoc error

while posting AP the IDoc was not processed and throws the below error:
"No reversal possible. Reverse value must be reset
Message no. M8283"
intercompany invoice was created previously for the same delivery no. and was posted successfully. there wasnt any issue in cancelling the invoice as well. but when trying to create an IV invoice again, its throwing this error.
please advice.

Check OSS Note 730853 - MRRL: M8283 Reverse value must be reset
Regards,

Idoc types & message types

hi friends, please can somebody post different kinds of Idoc types and message types used in sd , from sd's point of view. and also explain giving examples if you could. thanks
points will be awarded for sure . thanks
seema roy

Dear Seema,
concerning EDI concept in SD: the EDI concept is intended to realize the sales and distribution process completely automatically with the help of electronical documents. These documents are sent from one customer to another, are processed mostly on the background and give a possibility to realize the sales process extremely efficiently.
If MM-customer would like to purchase the goods then he creates the IDOC of type ORDERS and send it to SD-customer. On the SD-side the IDOC is processed via the function module IDOC_INPUT_ORDERS and creates the sales order. As confirmation the SD-side can send to MM-side the Order-Response IDOC (function IDOC_OUTPUT_ORDERS). The MM-customer can every thime send a change to the existiong order, then on SD side the ORDCHG IDOC will be processed. It can change the order like in VA02. The creation of the invoice can be made via IDOC of message type INVOIC (function IDOC_OUTPUT_INVOIC).
So, the process can be realized completely automatically between SD and MM partners with the help of IDOCs: ORDERS, ORDCHG, ORDRSP, INVOIC.
That's all concerning the SD-EDI.
Additional processes in SD, where EDI are used:
1) application of delivery schedules to the scheduling agreement: IDOC of type DELINS
2) creation of a delivery order to the scheduling agreement: IDOC of type DELORD
3) creation of external agent service delivery to scheduling agreement: IDOC of type EDLNOT
4) creation of credit advice / credit memo in the frames of self-billing: IDOCs of type GSVERF, SBWAP and for external invoice creation SBINV.
It is all processes which are realized in the SD module via EDI.
There is not so much Customizing for EDI. The most entries are required by EDI for the scheduling agreement processing (DELINS, EDLNOT, SBINV). The Customizing of these processes is located in the Customizing of scheduling agreements: SPRO => Sales and Distribution => Sales => Sales Documents => Scheduling agreements with delivery schedules => Control EDI Inbound processing.
General EDI Customizing in SD is available under: SPRO => Sales and Distribution => Electronic Data Interchange => EDI messages => ...
I hope this info helps.
Kind regards,
Akmal Vakhidov
Development Support SAP, Walldorf/Germany

Intercompany Billing through the EDI

Hi Experts,
I have configured the Intercompany Billing and it is working fine. But, I have to do it through EDI so that the Posting in the Delivering company is made automatically through EDI.
I guess this can be done but I don't know the Steps of Configuration for Intercompany Billing through EDI.
Regards,
Jans

Hi,
detailed guide on edi intercompany billing:
http://www.scribd.com/doc/5024013/InterCompany-Billing-IDoc
Best regards,
Zuzana

IDOC and ALE Configuration with cross application with SD

Hi Sap Gurus,
Please send me some document on IDOC and ALE Configuration with cross application with SD.
Please send me the material on my mail id [email protected]
Regards
shekhar

Dear Shekhar,
concerning EDI concept in SD: the EDI concept is intended to realize the sales and distribution process completely automatically with the help of electronical documents. These documents are sent from one customer to another, are processed mostly on the background and give a possibility to realize the sales process extremely efficiently.
If MM-customer would like to purchase the goods then he creates the IDOC of type ORDERS and send it to SD-customer. On the SD-side the IDOC is processed via the function module IDOC_INPUT_ORDERS and creates the sales order. As confirmation the SD-side can send to MM-side the Order-Response IDOC (function IDOC_OUTPUT_ORDERS). The MM-customer can every thime send a change to the existiong order, then on SD side the ORDCHG IDOC will be processed. It can change the order like in VA02. The creation of the invoice can be made via IDOC of message type INVOIC (function IDOC_OUTPUT_INVOIC).
So, the process can be realized completely automatically between SD and MM partners with the help of IDOCs: ORDERS, ORDCHG, ORDRSP, INVOIC.
That's all concerning the SD-EDI.
Additional processes in SD, where EDI are used:
1) application of delivery schedules to the scheduling agreement: IDOC of type DELINS
2) creation of a delivery order to the scheduling agreement: IDOC of type DELORD
3) creation of external agent service delivery to scheduling agreement: IDOC of type EDLNOT
4) creation of credit advice / credit memo in the frames of self-billing: IDOCs of type GSVERF, SBWAP and for external invoice creation SBINV.
It is all processes which are realized in the SD module via EDI.
I hope this info helps.
Kind regards,
Akmal Vakhidov
Development Support SAP, Walldorf/Germany

EDI/ IDOC

Gurus
Can somebody answer my querries
1. What exactly is gapping and mapping in EDI/IDOC
2. Can anybody send me the functional specifications and test development for EDI! Meaning any specs as a functional consultant we provide EDI team for mapping .
My email ID is [email protected]
Thanks

Dear Brendon,
what you map in IDOC depends on the IDOC message type.
ORDERS - creation of a sales order
ORDCHG - change of an existing sales order
ORDRSP - confirmation/replication of the sales order
DELINS - creation of a delivery schedule in scheduling agreement
DELORD - creation of a delivery order to the scheduling agreement
EDLNOT - creation of an external agent delivery to the scheduling agreement
GSVERF - creation of a credit advice
SBINV - creation of the invoice
SBWAP - creation of debit/credit memo(requests)
INVOIC - sending the invoice
In the transaction WE60 you can see the fields to every basic IDOC type. Not all fields which could be mapped via IDOC will be transfered automatically (only some ones). All other fields can be mapped to the application with the help of numerous user-exits provided.
The most important transactions:
BD87 - to apply the incoming IDOC
WE19 - to copy / to edit the IDOC and apply this copy
WE02 - to display the IDOC
WE05 - to select IDOCs
WE60 - to see the declared IDOC fields
And here is a general information about IDOC concept in SD:
The EDI concept is intended to realize the sales and distribution process completely automatically with the help of electronical documents. These documents are sent from one customer to another, are processed mostly on the background and give a possibility to realize the sales process extremely efficiently.
If MM-customer would like to purchase the goods then he creates the IDOC of type ORDERS and send it to SD-customer. On the SD-side the IDOC is processed via the function module IDOC_INPUT_ORDERS and creates the sales order. As confirmation the SD-side can send to MM-side the Order-Response IDOC (function IDOC_OUTPUT_ORDERS). The MM-customer can every thime send a change to the existiong order, then on SD side the ORDCHG IDOC will be processed. It can change the order like in VA02. The creation of the invoice can be made via IDOC of message type INVOIC (function IDOC_OUTPUT_INVOIC).
So, the process can be realized completely automatically between SD and MM partners with the help of IDOCs: ORDERS, ORDCHG, ORDRSP, INVOIC.
That's all concerning the SD-EDI.
Additional processes in SD, where EDI are used:
1) application of delivery schedules to the scheduling agreement: IDOC of type DELINS
2) creation of a delivery order to the scheduling agreement: IDOC of type DELORD
3) creation of external agent service delivery to scheduling agreement: IDOC of type EDLNOT
4) creation of credit advice / credit memo in the frames of self-billing: IDOCs of type GSVERF, SBWAP and for external invoice creation SBINV.
It is all processes which are realized in the SD module via EDI.
There is not so much Customizing for EDI. The most entries are required by EDI for the scheduling agreement processing (DELINS, EDLNOT, SBINV). The Customizing of these processes is located in the Customizing of scheduling agreements: SPRO => Sales and Distribution => Sales => Sales Documents => Scheduling agreements with delivery schedules => Control EDI Inbound processing.
General EDI Customizing in SD is available under: SPRO => Sales and Distribution => Electronic Data Interchange => EDI messages => ...
I hope this info helps.
Kind regards,
Akmal Vakhidov
Development Support SAP, Walldorf/Germany

Need help in Credit memo IDOC !

I am trying to create a idoc when the credit memo is generated !
How to create it !

Hi,
concerning EDI concept in SD: the EDI concept is intended to realize the sales and distribution process completely automatically with the help of electronical documents. These documents are sent from one customer to another, are processed mostly on the background and give a possibility to realize the sales process extremely efficiently.
If MM-customer would like to purchase the goods then he creates the IDOC of type ORDERS and send it to SD-customer. On the SD-side the IDOC is processed via the function module IDOC_INPUT_ORDERS and creates the sales order. As confirmation the SD-side can send to MM-side the Order-Response IDOC (function IDOC_OUTPUT_ORDERS). The MM-customer can every thime send a change to the existiong order, then on SD side the ORDCHG IDOC will be processed. It can change the order like in VA02. The creation of the invoice can be made via IDOC of message type INVOIC (function IDOC_OUTPUT_INVOIC).
So, the process can be realized completely automatically between SD and MM partners with the help of IDOCs: ORDERS, ORDCHG, ORDRSP, INVOIC.
That's all concerning the SD-EDI.
Additional processes in SD, where EDI are used:
1) application of delivery schedules to the scheduling agreement: IDOC of type DELINS
2) creation of a delivery order to the scheduling agreement: IDOC of type DELORD
3) creation of external agent service delivery to scheduling agreement: IDOC of type EDLNOT
***4) creation of credit advice / credit memo in the frames of self-billing: IDOCs of type GSVERF, SBWAP and for external invoice creation SBINV.**
It is all processes which are realized in the SD module via EDI.
I hope this info helps.
Regards.

IDoc for PSM Earmarked Funds

Hi @ll,
We are currently connecting two SAP-Systems.
One of them uses PSM (Public Sector Management) the other doesn't.
The PSM is used for billing with FI, the other is the central purchasing system.
The purchasing system needs to check earmarked funds in the PSM.
So far I did find the message type /ISDFPS/FMHHM, but no IDoc is assigned in our initial SAP System.
Anyone a clue what the name of the Idoc is and why it's not assigned?
Bonus question:
Pure curiosity: During my research on FI-Billing IDocs I came across three different types:
INVOIC03, ACC_INVOICE_RECEIPT_03 and FIDCCP02. Does anyone know the difference and when to use what IDoc?
Thanks in advance.
Cheers,
Aglaia

Hi,
The idoc types mentioned by you pertains to the following message types.
ACC_INVOICE_RECEIPT              Accounting: Post invoice receipt (OAG: LOAD PAYABLE)
FIDCC1                                       Send entire FI documents (user exit 003/4)
FIDCC2                                       Send entire FI documents (user exit 005/6)
INVOIC                                        Invoice/Billing Document
Depends on your requirement you choose the correct idoc type and the message type.
Cheers,
Hakim

Idoc Retrigger

Hi,
I have one billing idoc with status 03 which is not having UOM picked up and thus failed in recepient's system. I want this Idoc to retrigger after adding an existing segment having relevent UOM. Kindly advice how to do that.

Hi,
If the status of the IDOC is "03" and if you want to make changes to the existing IDOC,double click on the segment that you want to change.
Click on Data Record(In menu bar)-->(Display->Change).
Enter the values that you want to change.
Save.
Status will be chnaged to "32".
Goto the T.Code SE38.Enter the program name as "RC1_IDOC_SET_STATUS".Press F8 or click on execute.
Enter this IDOC number.
Enter the current status as "32".Enter the new status as "30".
Remove the tick mark for test run.
Execute.
Reprocess this IDOC by using the T.Code BD87.
If you want to new entry to the existing segment,goto the T.Code WE20.
Enter the required values.
Save.
Regards,
Krishna.

ALE, EDI, WAS, BSP, BAPI

HI ALL,
CAN YOU TELL ME A BRIEF ABOUT ALE, EDI, WAS, BSP, BAPI AS IT IS VERY COMMON IN EVERY INTERVIEW ?
REGARDS
RAJARSHI

Hi Rajarshi,
IDOCS:
IDOCS are intermediary documents which are like CARRIERS of the data
IDOCs are safe to transfer data, but less volume of data. User is not allowed to access (modify) the data like PSA. IDOCs have 3 parts.
1. Control Record - SOURCE & TARGET details,
2. Data Record - Here comes your query....
Info IDOC - It contains all the technical details related to the data load i.e. Request NO, No of Data Packages, USER, DATE, TIME, LOGICAL SYSTEM, etc. Info IDOC is also ONE segment, the 1 sr segment.
Here data will not be there.
Data IDOC - These are the ones which hold the data. The total no of records are made into Data IDOCs i.e. if 99 records are there then 99 Data IDOCs will be there and all these will be divided into 99 segments.
Hence the total number of Segments in IDOC is 100.
Info IDOC + Data IDOCs = Total no of Segments
1 + 99 = 100.
3. Status Record - Here the status of the data transfer will be available.
ALE:
ALE is Application linking & Enabling which enables to interface SAP with other modules
Pl go through below links as they provide all the required info on ALE & IDOC's:
ALE / IDOC:
Please check this online document for ALE and IDoc.
http://help.sap.com/printdocu/core/Print46c/en/data/pdf/BCMIDALEIO/BCMIDALEIO.pdf
http://help.sap.com/printdocu/core/Print46c/en/data/pdf/BCMIDALEPRO/BCMIDALEPRO.pdf
http://help.sap.com/printdocu/core/Print46c/en/data/pdf/CABFAALEQS/CABFAALEQS.pdf
http://help.sap.com/printdocu/core/Print46c/en/data/pdf/BCSRVEDISC/CAEDISCAP_STC.pdf
http://help.sap.com/printdocu/core/Print46c/en/data/pdf/BCSRVEDI/CAEDI.pdf
Also check this links for additional information.
http://help.sap.com/saphelp_erp2004/helpdata/en/dc/6b835943d711d1893e0000e8323c4f/content.htm
http://www.sapgenie.com/sapgenie/docs/ale_scenario_development_procedure.doc
http://edocs.bea.com/elink/adapter/r3/userhtm/ale.htm#1008419
http://www.netweaverguru.com/EDI/HTML/IDocBook.htm
http://www.sapgenie.com/sapedi/index.htm
u will have enough material from above .....
Mostly SD consultant doesnt deal with EDI, Idocs but its always good to have knowledge,
EDI
EDI concept in SD: the EDI concept is intended to realize the sales and distribution process completely automatically with the help of electronical documents. These documents are sent from one customer to another, are processed mostly on the background and give a possibility to realize the sales process extremely efficiently.
If MM-customer would like to purchase the goods then he creates the IDOC of type ORDERS and send it to SD-customer. On the SD-side the IDOC is processed via the function module IDOC_INPUT_ORDERS and creates the sales order. As confirmation the SD-side can send to MM-side the Order-Response IDOC (function IDOC_OUTPUT_ORDERS). The MM-customer can every time send a change to the existing order, then on SD side the ORDCHG IDOC will be processed. It can change the order like in VA02. The creation of the invoice can be made via IDOC of message type INVOIC (function IDOC_OUTPUT_INVOIC).
So, the process can be realized completely automatically between SD and MM partners with the help of IDOCs: ORDERS, ORDCHG, ORDRSP, and INVOIC.
That's all concerning the SD-EDI.
Additional processes in SD, where EDI are used:
1) application of delivery schedules to the scheduling agreement: IDOC of type DELINS
2) creation of a delivery order to the scheduling agreement: IDOC of type DELORD
3) creation of external agent service delivery to scheduling agreement: IDOC of type EDLNOT
4) creation of credit advice / credit memo in the frames of self-billing: IDOCs of type GSVERF, SBWAP and for external invoice creation SBINV.
It is all processes which are realized in the SD module via EDI.
Go through this, You will get better idea on EDI,ALE,IDOCS
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.
BAPI:
BAPI (Business Application Programming Interface) is a set of interfaces to object-oriented programming methods that enable a programmer to integrate third-party software into the proprietary R/3 product from SAP. For specific business tasks such as uploading transactional data, BAPIs are implemented and stored in the R/3 system as remote function call (RFC) modules.
BAPIs (Business Application Programming Interfaces) are the
standard SAP interfaces. They play an important role in the
technical integration and in the exchange of business data
between SAP components, and between SAP and non-SAP
components. BAPIs enable you to integrate these components
and are therefore an important part of developing
integration scenarios where multiple components are
connected to each other, either on a local network or on the Internet.
BAPIs allow integration at the business level, not the
technical level. This provides for greater stability of the
linkage and independence from the underlying communication
technology
http://www.erpgenie.com/sap/abap/bapi/example.htm
http://www.sap-img.com/bapi.htm
http://help.sap.com/saphelp_nw04/helpdata/en/e0/9eb2370f9cbe68e10000009b38f8cf/frameset.htm
http://help.sap.com/saphelp_nw04/helpdata/en/43/b46c1e53c111d395fa00a0c94260a5/content.htm
http://www.sappoint.com/abap/bapiintro.pdf#search=%22BAPI(SAP)%22
http://www.erpgenie.com/sap/abap/bapi/index.htm
http://www.erpgenie.com/sap/abap/bapi/conventions.htm
http://www.erpgenie.com/sapgenie/docs/BAPI%20Programming.doc
http://64.233.167.104/custom?q=cache:eyMZ5qPOH-0J:www.erpgenie.com/sapgenie/docs/BAPI%2520Intro.doc+bapi&hl=en&ct=clnk&cd=6&ie=UTF-8&client=pub-2723892367221695
http://64.233.167.104/custom?q=cache:c7cwsXMxq-UJ:www.sapdevelopment.co.uk/java/jco/bapi_jco.pdf+bapi&hl=en&ct=clnk&cd=1&ie=UTF-8&client=pub-6389415953938571
List of all bapis
http://www.planetsap.com/LIST_ALL_BAPIs.htm
FOR BAPI's
http://www.sappoint.com/abap/bapiintro.pdf
Please Reward If Really Helpful,
Thanks and Regards,
Sateesh.Kandula

Interfaces thru EDI

anybody helps about the interfaces..through EDI

Sudhir,
The EDI concept is intended to realize the sales and distribution process completely automatically with the help of electronically documents. These documents are sent from one customer to another, are processed mostly on the background and give a possibility to realize the sales process extremely efficiently.
If MM-customer would like to purchase the goods then he creates the IDOC of type ORDERS and send it to SD-customer. On the SD-side the IDOC is processed via the function module IDOC_INPUT_ORDERS and creates the sales order. As confirmation the SD-side can send to MM-side the Order-Response IDOC (function IDOC_OUTPUT_ORDERS). The MM-customer can every time send a change to the existing order, then on SD side the ORDCHG IDOC will be processed. It can change the order like in VA02. The creation of the invoice can be made via IDOC of message type INVOIC (function IDOC_OUTPUT_INVOIC).
So, the process can be realized completely automatically between SD and MM partners with the help of IDOCs: ORDERS, ORDCHG, ORDRSP, and INVOICE.
That's all concerning the SD-EDI.
Additional processes in SD, where EDI are used:
1) application of delivery schedules to the scheduling agreement: IDOC of type DELINS
2) creation of a delivery order to the scheduling agreement: IDOC of type DELORD
3) creation of external agent service delivery to scheduling agreement: IDOC of type EDLNOT
4) creation of credit advice / credit memo in the frames of self-billing: IDOCs of type GSVERF, SBWAP and for external invoice creation SBINV.
It is all processes which are realized in the SD module via EDI.
There is not so much Customizing for EDI. The most entries are required by EDI for the scheduling agreement processing (DELINS, EDLNOT, and SBINV). The Customizing of these processes is located in the Customizing of scheduling agreements: SPRO => Sales and Distribution => Sales => Sales Documents => Scheduling agreements with delivery schedules => Control EDI Inbound processing.
General EDI Customizing in SD is available under: SPRO => Sales and Distribution => Electronic Data Interchange => EDI messages =>...
Reward points pls.
Regards,
Govind.

SD Flow Overview

Hi
i'm ABAP consultant.i want to know the flow of SD and integration of SD with other modules.help me to know about SD.

Hi Michael,
INTERGRATION BETWEEN SD AND MM AND SD & FICO
The link between SD and MM: -
1. When you create sales order in SD, all the details of the items are copied from Material master of MM.
2. MRP and availability check related data is also taken from MM although you control this data in SD also.
3. While you create inbound/outbound delivery with reference to a sales order, the shipping point determination takes place with the help of the loading group, plant data, shipping conditions etc. This also refers to Material Master.
4. The material which you are entering in a sales order must be extended to the sales area of your sales order/customer otherwise you cannot transact with this material.
There are many such links between SD and MM.
SD AND MM INTGRATON
1a. Looking at MM and SD interaction first, take the scenario of a third party order process. This process uses a purchase order (which is sent to your vendor). Also invoice verification is used further along the process to check that the invoice you send to your customer is the same material and quantity as that which the vendor sends to you (but obviously shipped
directly to your customer).
1b. Billing is an SD function. But SAP needs to know, when processing a customer's payment, to which GL account the payment has to be processed. For instance payment of a UK based material would be placed in a different GL account to that of a non-UK based material. Furthermore, a UK based customer may have a different GL account to that of an Export customer. This is configured in Account Determination.
2. ABAPers are there to essential do some bespoke development. Your integration, or interaction, with them would be when specifying the tables, fields, input fields, a simple process explanation, data mapping (if doing an interface from one system to another) etc. *-- Shahee
The link between SD and MM :-
1. When you create sales order in SD, all the details of the items are copied from Material master of MM.
2. MRP and availability check related data is also taken from MM although you control this data in SD also.
3. While you create inbound/outbound delivery with reference to a sales order, the shipping point determination takes place with the help of the loading group, plant data, shipping conditions etc. This also refers to Material Master.
4. The material which you are entering in a sales order must be extended to the sales area of your sales order/customer otherwise you cannot transact with this material.
There are many such links between SD and MM
In Pricing we would want to determine the cost of the product
thru VPRS Condition Type. This cost of the material is
picked from the Material Master. How this happens is, if
we would want to determine this cost VPRS in the Sales Order
for Profitability purpose then , all those Item categories
that can appear in a sales order must be activated for
Determine Cost Check box in customizing. Thats one of the SD
MM Integration.
Now the link between SD and FI: -
1. Whenever you create a delivery with reference to a sales order, goods movement takes place in the background. E.g. In case of standard sales order, you create an outbound goods delivery to the customer.
Here movement 601 takes place. This movement is configured in MM. Also, this movement hits some G/L account in FI. Every such movement of good s hits some G/L account.
2. The accounts posting in FI is done with reference to the billing documents (invoice, debit note, credit note etc) created in SD. Thus this is a link between SD and FI
3. Tax determination: In case of a tax determination also, there is a direct link between SD and MM
SD Integration points with other modules
SD module is highly integrated with the other modules in SAP.
Sales Order
Integration Points Module
Availability Check - MM
Credit Check - FI
Costing - CO/ MM
Tax Determination - FI
Transfer of Requirements - PP/ MM
Delivery & Goods Issue
Integration Points Module
Availability Check - MM
Credit Check - FI
Reduces stock - MM
Reduces Inventory $ - FI/ CO
Requirement Eliminated - PP/ MM
Billing -
Integration Points Module
Debit A/R - FI/ CO
Credit Revenue - FI/ CO
Updates G/ L - FI/ CO
(Tax, discounts, surcharges, etc.)
Milestone Billing - PS
Return Delivery & Credit Memo -
Integration Points Module
Increases Inventory - MM
Updates G/ L - FI
Credit Memo - FI
Adjustment to A/R - FI
Reduces Revenue - FI
SD Transaction Code Flow:
Inquiry / Document type IN
Tcode for creation VA11, VA12, VA13. Tables VBAK, VBAP
Quotation / QT
Tcode for creation VA21, VA22, VA23. Tables VBAK, VBAP
Purchase Order PO
Tcode for creation ME21, ME22, and ME23. Tables EKKO, EKPO.
Sales Order OR
Tcode for creation VA01, VA02, VA03. Tables VBAK, VBAP
Delivery LF
Tcode for creation VL01, VL02, and VL03. Tables LIKP, LIPS
Billing MN
Tcode for creation VF01, VF02, and VF03. Tables VBRK, VBRP
To create a sales order we need purchase order number and customer number. Before that, to create a purchase order we need to have material no, vendor no.
To create vendor tcode is
xk01 (create), xk02 (change), xk03 (display)
Tables are lfa1.
To create customer tcode is xd01, xd02, xd03.
Table is kna1.
SD Module is integrated with various modules during transaction processing ...
Sales Order Integration Points Module
Availability Check MM Credit Check FI Costing CO/ MM Tax Determination FI Transfer of Requirements PP/ MM
Delivery & Goods Issue Integration Points Module
Availability Check MM Credit Check FI Reduces stock MM Reduces Inventory $ FI/ CO Requirement Eliminated PP/ MM
Billing - Integration Points Module
Debit A/R FI/ CO Credit Revenue FI/ CO Updates G/ L FI/ CO (Tax, discounts, surcharges, etc.) Milestone Billing PS
Return Delivery & Credit Memo - Integration Points Module
Increases Inventory MM Updates G/ L
FI Credit Memo FI Adjustment to A/R FI Reduces Revenue FI
check following link also
http://sap-img.com/sap-sd/link-between-sap-sd-mm-and-fi.htm
If you work in SD area, then the most important process where you really need to know MM area is the third-party process. In this case from SD sales order automatically the purchase requisition will be created on MM side. From this purchase requisition on MM side you create the purchase order on MM side. This purchase order updates the sales order on SD side, if you create the confirmation of the purchase order. This process takes place for the pure third-party as well as for individual purchase order process. Later the invoice will be sent from MM to SD (transaction MIRO) and will update the status of the SD order. If you work with this process then you need really know MM transactions quite well, because it is the same SD and MM system.
Another area where you have SD of one system integrated with MM of another system is the EDI process. Here several remarks concerning EDI concept of SD:
EDI concept is intended to realize the sales and distribution process completely automatically with the help of electronically documents. These documents are sent from one customer to another, are processed mostly on the background and give a possibility to realize the sales process extremely efficiently.
If MM-customer would like to purchase the goods then he creates the IDOC of type ORDERS and send it to SD-customer. On the SD-side the IDOC is processed via the function module IDOC_INPUT_ORDERS and creates the sales order. As confirmation the SD-side can send to MM-side the Order-Response IDOC (function IDOC_OUTPUT_ORDERS). The MM-customer can every time send a change to the existing order, then on SD side the ORDCHG IDOC will be processed. It can change the order like in VA02. The creation of the invoice can be made via IDOC of message type INVOIC (function IDOC_OUTPUT_INVOIC).
So, the process can be realized completely automatically between SD and MM partners with the help of IDOCs: ORDERS, ORDCHG, ORDRSP, INVOICE.
Additional processes in SD, where EDI are used in communication with MM are:
1) sending (from MM side) and application (on SD side) of delivery schedules to the scheduling agreement: IDOC of type DELINS. In this case we have practically automatically communication between SD and MM scheduling agreements via IDOCs;
2) creation of credit advice / credit memo in the frames of self-billing: IDOCs of type GSVERF, SBWAP and for external invoice creation SBINV are sent from MM customer to SD customer. So, the output function module belongs to MM area and the inbound function module - to SD area.
Please Reward If Really Helpful,
Thanks and Regards,
Sateesh.Kandula

Billing IDOC

Similar Messages

Maybe you are looking for