IDOC

[Former Member]

Hi Friends,

Kindly explain about the processing of invoice to various company codes (inter company billing) through IDOC.

How exactly this happend and what help one need to take from ABAP if want to get done.

thanks.

[Former Member]

Hello Shiv,

Process in intercomapny through IDOC is as follows:

Consider two company codes CC1(receiving) & CC2(supplying)

CC1 CC2

Purchase Order ---> Create sales order

(850) (850)I

I

Existing Report/ <---- PO Acknowledgement(855)

Functionality I

I

Goods Receipt<----- Delivery Acknowledgement(856)

I

I

Invoice Receipt<------ Invoice(810)

Now we need to implement above scenario. So we need to configure partner in WE20. We need to set ports for sending and receiving IDOC in WE21. We need to configure background processes for processing these IDOC so we need to take teh help of ABAPer.

Hope it helps. Reward points if so.

Regards,

Priyanka

[Former Member]

Friends thanks for information.

Thanks.

[Former Member]

Priyanka,

Please explain what one need to configure as a Functional consultant? Kindly give details about the job done by ABAP Consultant.

Thanks.

[Former Member]

Hello Shiv,

As an EDI consultant we need to configure partner profile in WE20. It includes partner function, output parameters, inbound parameters. Again in inbound and outbound parameters we need to assign the process code which in turn triggers yours function module which creates IDOC. Also we configure whether that IDOC should trigger immidiately or through background.

Port is configured by BASIS team. Ports are mapped i.e sender port and receiver port. It is done in WE21. Address should be properly mapped.

ABAPer role comes when we need to assign background jobs or we need to modify some program as per the requirement.

Also, all the data segments should be mapped properly.

Reward points if helpful.

Regards,

Priyanka

[Former Member]

Priyanka,

Lets say I have two company code. Both company codes are having same client. Do you think IDOC is required to process intercompany Invoice in this case?

What my understanding is if we want to process invoice through IDOC for various company codes, we must have different clients for different company codes (i.e.one system sends & another receives) please correct me if I am wrong.

Thanks.

[Former Member]

Hello shiv,

Intercompany means sales between two different company codes of same client.

Suppoes TATA is client then sales between TATA automobiles and TATA indicom.

Hope it helps.

Priyanka

[Former Member]

Priyanka,

Thanks for guidance.

That's exactly I want to know, if we have two c code in same client then, is there any sense to use IDOC to process invoice?

My question is simple Priyanks, Should we use IDOC if we have both company code in same client?

ple guide me.

Thanks

[Former Member]

Shiv,

It all depends on your requirement if you want to process it through IDOC then yes you can acheive this functionality through IDOC even if company codes belong to same client. I have told the example using CC1 & CC2 in my first reply. That is how entire process works.

Consider two company codes CC1(receiving) & CC2(supplying)

Purchase Order from CC1 (850) ---> Create sales order from CC2(850)

Existing Report/ <---- PO Acknowledgement from CC2(855)

Functionality in CC1

Goods Receipt in CC1<----Delivery Acknowledgement from CC2(856)

Invoice Receipt in CC1<------ Invoice from CC2(810)

Reward points ih helpful.

Reagrds,

Priyanka

[Former Member]

Priyanka,

Thanks for your valuable guidance & help.

Since your explanation is good, I understood what you said .

what I am thinking is, if both company codes are in same client then there itself we would get inter company invoice, then why should we use IDOC to process invoice?

Thanks.

[Former Member]

Lakshmipathi, Praveen kumar, Priyanka

Thanks to everybody, Ple tell me whether it is advisable to process intercompany invoice to several company codes if all company codes are in same client.

OR

We need to have different client for different company code in order to process invoice through IDOC.

Thanks

Shiv

[Former Member]

Hello Shiv,

Intercompany process itself means sales between two company codes under same client, so when we are selling goods across two different company codes then we need to bill the customer company code irrespective of the fact that they belong to same client.

Basic reason for maintaining different company codes for same client is that either client want to maintain different finanicial account for his various comapnies or companies are located in different countries and financial structure of countries differs.

Hope it answers your query.

Don't forget to reward points if so.

Regards,

Priyanka

[Former Member]

Thanks Priyanka,

I reward point to you. Please guide me in future also.

Priyanka, where you based at? Do you work in Pune?.

Hope our discussion would continue so that we could share our findings.

Thanks

Shiv

[Former Member]

IDOC:-

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 Creation - Manual:

If a batch job is not running. First thing is go into to code of the batch job and find out what type of IDOC's it is processing.

Let's assume, it is creating / processing DELINS type IDOC's, then follow the below steps:

Go to T-code WE02, input DELINS in the logical message, give date range of say 10 days or so and Direction = 2 and execute it. You will get a list of IDOC's

Then select any one of those IDOC"s in status 53 and go to T-code WE19 and input the same and execute.

Later in the same T-code you can change the sender and receiver parameters including the plant.

In the header level you need to change the delivery schedule number and release number. Put the same PO number as in the scheduling agreement. Enter values of sold to, ship to, partner description and customer material along with the desired quantity.

Then on the application tool bar you will find "Standard Inbound", click on this and check for the green light against the partner profile and click OK / Enter.

You will be processing the IDOC manually. Then once you get the IDOC number, input the new number in WE02 and execute to check the status. If it is not 53 status, then go to T-code BD87 and input that number and execute. Inside select the last line of status and click on "Process" icon to finally get the IDOC in Status 53 "Successfully Processed"

This is the standard process followed for processing IDOC's manually.

IDOC'S CONFIGURATION FOR SD

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. The IDoc is transmitted to the receiver, which may be an R/3, R/2, or some external system.

You can Create IDoc in this process: and transfer master data from one system to another.

You can transfer Master data in Bulk through SMD (Share master data tool) Tool.

The main SMD tools in SAP are BD10 for Material Master

BD12- customer

BD14- Vendor

suppose u want to transfer material in bulk.

U have configure the systems:

TA: SALE for ale customization -

---

create logical system here.

Steps:

1) Create port(WE21) and logical system and RFC destination(SM59)

1) Create Distribution Model in BD64.

2) Create Partner Profile (WE20) in both systems and distribute the model and in receiver system the model will be created itself after distribution.

3) Go to TA: BD10 (SMD for material)

4) message type will be MATMASand specify the logical system and press execute.

it will generate the master IDoc and communication IDoc in sender system

now u can check the receiver system the Inbound IDOC must be there with all the materials

TA for IDOC CHK :WE02,WE05.

Go through This link too: PDF Index.IDoc

Batch Jobs:-

Batch usually refers to programs that work on a massive quantity (batch) of data.

Backgound job is a way to process a program (even a batch program) so that the system does not use dialog processes that are resource consuming and prone to time-out errors but background processes that the system optimizes so that the system load is balanced and no time-out occurs.

We can run a set up spools as a batch to take printouts. But we can schedule this as a background job may be during off peak hours. Normally such batch jobs are created with SM35 and background jobs are defined via SM36.

SM35: Batch Input

SM36: Define Background Jobs

BACKGROUND JOB PROCESS

If its a custom program, your should talk to the programmer who wrote the program by finding out what is the program running behing the job.

Aslo, if you want to find out on your own, you can try to run the SQL trace on it using ST05 and then analyze the trace for the expensive statements. Check the trace wherevere it shows the fetch time marked in RED and then, you can try to analyze the SQL statement running in the backgroung, to see if the programmer is doing an unnecessary select/fetch, reading too many records etc.

Hope that helps..

You can try the following:

go to SM36 and create background job by giving

job name,job class and job steps (JOB SCHEDULING)

BATCH

If the user forgets to opt for keep session then the session will be automatically removed from the session queue(log remains). However if session is processed we may delete it manually.

ii)if session processing fails data will not be transferred to SAP database table.

Direct Input.

Without calling the screens but all the validations should be done and only for master datas upload.

Direct Input method:

1. Only for error free datas and also master data

updation.

2. It will directly updates the database table. No

screens involved.

3. Transaction BMVO or Program RBMVSHOW has been

used.

BDC(Batch Input Session):

1. Screens will be called programmatically.

2. First sessions will be created then we'll run the seesions in SM35 transaction.

3. Synchronous database update. After the processing the session only database update will occur.

Batch Data Communication (BDC) is the process of transferring data from one SAP System to another SAP system or from a

non-SAP system to SAP System.

Features:

BDC is an automatic procedure.

This method is used to transfer large amount of data that is available in electronic medium.

BDC can be used primarily when installing the SAP system and when transferring data from a legacy system (external

system).

BDC uses normal transaction codes to transfer data.

Types of BDC:

CLASSICAL BATCH INPUT (Session Method)

CALL TRANSACTION

BATCH INPUT METHOD:

This method is also called as ‘CLASSICAL METHOD’.

Features:

Asynchronous processing.

Synchronous Processing in database update.

Transfer data for more than one transaction.

Batch input processing log will be generated.

During processing, no transaction is started until the previous transaction has been written to the database.

CALL TRANSACTION METHOD :

This is another method to transfer data from the legacy system.

Features:

Synchronous processing. The system performs a database commit immediately before and after the CALL TRANSACTION USING

statement.

Updating the database can be either synchronous or asynchronous. The program specifies the update type.

Transfer data for a single transaction.

Transfers data for a sequence of dialog screens.

No batch input processing log is generated.

Differences between Call Transaction and Sessions Method:

Session method.

1) Synchronous processing.

2) Can transfer large amount of data.

3) Processing is slower.

4) Error log is created

5) data is not updated until session is processed.

6) Generally used for back ground jobs.

7) At a time we can update to more than one screens.

Call transaction.

1) Asynchronous processing

2) can transfer small amount of data

3) processing is faster.

4) Errors need to be handled explicitly

5) data is updated automatically

6) for background n fore ground jobs.

7) At a time we can update to a single screen.

Direct Input method:

Without calling the screens but all the validations should be done and only for master datas upload.

1. Only for error free datas and also master data updation.

2. It will directly updates the database table. No screens involved.

3. Transaction BMVO or Program RBMVSHOW has been used.

For BDC:

http://myweb.dal.ca/hchinni/sap/bdc_home.htm

https://www.sdn.sap.com/irj/sdn/wiki?path=/display/home/bdc&;

http://www.sap-img.com/abap/learning-bdc-programming.htm

http://www.sapdevelopment.co.uk/bdc/bdchome.htm

http://www.sap-img.com/abap/difference-between-batch-input-and-call-transaction-in-bdc.htm

http://help.sap.com/saphelp_47x200/helpdata/en/69/c250684ba111d189750000e8322d00/frameset.htm

http://www.sapbrain.com/TUTORIALS/TECHNICAL/BDC_tutorial.html

Check these link:

http://www.sap-img.com/abap/difference-between-batch-input-and-call-transaction-in-bdc.htm

http://www.sap-img.com/abap/question-about-bdc-program.htm

http://www.itcserver.com/blog/2006/06/30/batch-input-vs-call-transaction/

http://www.planetsap.com/bdc_main_page.htm

USER EXITS:-

. Introduction:

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_<program name><3 digit suffix>

The call to a function module exit is implemented as:

CALL CUSTOMER.-FUNCTION ❤️ digit suffix>

Example:

The program for transaction VA01 Create sales order is SAPMV45A

If you search for CALL CUSTOMER-FUNCTION i program

SAPMV45A you will find ( Among other user exits):

CALL CUSTOMER-FUNCTION '003'

exporting

xvbak = vbak

xvbuk = vbuk

xkomk = tkomk

importing

lvf_subrc = lvf_subrc

tables

xvbfa = xvbfa

xvbap = xvbap

xvbup = xvbup.

The exit calls function module EXIT_SAPMV45A_003

How to find user exits

Display the program where you are searching for and exit and search for CALL CUSTOMER-EXIT

If you know the Exit name, go to transaction CMOD.

Choose menu Utilities->SAP Enhancements. Enter the exit name and press enter.

You will now come to a screen that shows the function module exits for the exit.

3. Using Project management of SAP Enhancements, we want to create a project to enhance transaction A01.

- Go to transaction CMOD

- Create a project called ZVA01

- Choose the Enhancement assign radio button and press the Change button

In the first column enter V45A0002 Predefine sold-to party in sales document.

Note that an enhancement can only be used in 1 project. If the enhancement is already in use, and error message will be displayed

Press Save

Press Components. You can now see that enhancement uses user exit EXIT_SAPMV45A_002. Double click on the exit.

Now the function module is displayed. Double click on include ZXVVAU04 in the function module

Insert the following code into the include: E_KUNNR = '2155'.

Activate the include program. Go back to CMOD and activate the project.

Goto transaction VA01 and create a sales order.

Note that Sold-to-party now automatically is "2155"

TYPES OF EXITS

1) MENU EXITS

2) FUNCTION EXITS

3) TABLE EXITS

4) SCREEN EXITS

5) KEYWORD EXITS

6) FIELD EXITS

We use SAP transactions CMOD and SMOD to manage exits. Before implementing an exit, it is required to create the project by using CMOD

selecting the enhancement e.g. V45A0002 and selecting the component

(one which fulfills our need) i.e. the exit which will be implemented in SMOD and after coding has been done the project has to be activated.

An exit can be coded only once.

User Exits Related to Sales Orders:

MV45ATZZ

MV45AOZZ

MV45AIZZ

MV45ATZZ

MV45AOZZ

MV45AIZZ

MV45AFZZ and MV45EFZ1

Hope this will helps you and Reward If Helpful,

Thanks and Regards,

Praveen Kumar.D

[Lakshmipathi]

Hi Shiv

Go through the link

http://help.sap.com/saphelp_47x200/helpdata/en/4b/ad4ecb17fd11d28a360000e829fbbd/frameset.htm

Thanks

G. Lakshmipathi