The standards already in the software (Releases 4.0x, 4.5x, and 4.6x) allow purchase orders (POs) typed in by someone at the U.S. site to act as the sales orders for our plant in Germany; there is no need to retype the data. In fact, the quantity ordered in the U.S. site’s POs automatically shows up on the “delivery due” list reports at the German site. As soon as a person in Germany records the goods as shipped and the nightly batch invoice job starts to run, our intercompany transfer price is automatically copied from the U.S. site’s PO into the German site’s intercompany sales billing document. The whole cycle ideally happens without a sales order and, for the most part, without much manual entry.

Of course, if everything had worked out perfectly, I would not be writing this article, which shows you what I learned the hard way. I want to warn you that the “how to” for setting up fully automated intercompany accounting in R/3 when the SD module is involved is very different than the “how to” for intercompany accounting in other modules, such as FI or MM.

In the standard system, the only automated accounting in response to an intercompany sales billing is on behalf of the selling company code in Germany (Dr. to I.Co A/R, and Cr. to I.Co Sales). The other half of the intercompany posting (Dr. GR/IR, and Cr. I.Co A/P) is not automated. This was my company’s situation before this year’s implementation. Bringing our R/3 system to our U.S. affiliate had not reduced the number of work steps.

In fact, my company was able to implement complete automation, but it was not as quick and easy as a “Yes/No” checkbox. If you want to know how to convince the system to automatically create both halves of your intercompany billings (see Figure 1), you need to learn how three different things in R/3 fit together — an output type, an IDoc, and the EDI method of data transfer. They create the second half, so to speak, of the accounting handoff between two affiliated, but legally separated, companies that buy and sell goods with each other.

I can summarize what you’ll be reading in the next few pages as: (1) how the “output type,” with its data transfer option set to “EDI,” acts as the start of the automatic accounting on behalf of the purchasing company code, and (2) how the “outbound” parameter portal versus the “inbound” parameter settings act as your instructions to R/3 on how to create, and then use, an IDoc to accomplish the end of the automatic accounting on behalf of the purchasing company code.

Let’s begin with the start of the automatic accounting flow — an output type.

Question 1: Hard Copy vs. Email vs. Fax vs. ... Intercompany EDI?

As some of you might already know, the sales billing transaction in R/3 looks for the form in which you want the invoice (hard copy versus email versus fax, etc.) through a series of “If ..., then ...” instructions known as conditions. Some examples include:

• “If the ship-to location is in the U.S., then print a hard copy.”
• “If the sold-to account belongs to customer group ‘Z,’ then send a copy by fax.”
• “If the distribution channel is 15 or 20, then send a soft copy by email.”

Each possible kind of “If ... then” result (i.e., a hard copy or an email or a fax, etc.) is represented in the SD module as an output type and does not need to be mutually exclusive. By that I mean that one sales invoice can be sent from the SD module as just one kind of output, or it can be sent as two kinds, three kinds, four kinds, etc.

Why should you care about this? Because one of these — a special kind of output type — acts as the starting step for creating the second half of the intercompany sales posting (i.e., the Dr. to GR/IR, and Cr. to I.Co A/P for the purchasing company code). It must be set up with the EDI transmission method.

Figure 2 is a screenprint of the SAP standard-delivered output type RD04. Of special importance is the Bill-to Party Partner function setting below the EDI setting. Without the bill-to party’s customer number, there would be no way to automatically trigger the creation of the IDoc you ultimately must have if you want some automatic accounting, as you’ll see in the next section.

Figure 2

Standard-delivered optout type RD04

Question 2: What Does an Outbound vs. an Inbound IDoc Parameter Have to Do with Automatic Accounting?

Just for fun, imagine if someone handed you a vendor’s invoice, and it was your responsibility to record it against one of your company’s R/3 purchase orders. What would you do first? You would probably want to make sure you had all the necessary codes and numbers, such as the vendor’s account number, the product codes, and the PO number. Once you had all that scribbled down somewhere handy, you might then sit in front of your R/3 system and call up the Logistics Invoice Verification (LIV) screen to enter your data.

Well, this is exactly what R/3 can do for you. The difference is it doesn’t need a pencil and paper. Instead, it creates an IDoc with the necessary reference codes and numbers, such as the vendor number it should post the invoice to. Then, it calls up a data entry transaction of your choice (such as LIV) and uses the data in that IDoc to record the invoice. The instructions you give to R/3 on how to create the IDoc are called the “outbound” parameters. The instructions you give to R/3 on what to do with that IDoc are called the “inbound” parameters.

Figure 3 shows a screenprint of transaction code WE20, which is the customization transaction in R/3 for making the inbound and outbound parameters. You need to make two entries in WE20 — one for the bill-to party’s customer number on when and how to create the IDoc (i.e., the outbound parameters), and one for the vendor number on what to do with that IDoc (i.e., the inbound parameters).

Figure 3

Example for outbound parameters for bill-to partner 14855

Notice in Figure 3 how important it is for the special output type RD04 to designate one particular customer role (e.g., bill-to party) in the sales billing. It is important because the “outbound” parameter instructions you give to R/3 on when and how to create an IDoc are specific to one particular role (referred to as a partner function in Figure 2) and one particular customer number. On the left side of the screenprint, this is customer number 14855, shown under Partner type KU. In my example, customer 14855 actually represents my firm’s U.S. site — i.e., the affiliate that is purchasing some goods from the German parent company.

For a bit more detail on what an outbound parameters entry accomplishes, notice in Figure 4 that some of the specific instructions regarding when it is OK to create an IDoc include not just the customer number (14855) and the customer’s partner function (bill-to), but also the source application of V3 (Billing) and output type (also referred to in some SAP screens as Message type) of RD04.

Figure 4

Example for detailed settings for when it is OK to create an "outbound" IDoc

In other words, you are telling R/3 to create an IDoc only for those billing documents in the SD module that have at least one output type, that specifically have an output type of RD04, and that have the bill-to customer number 14855. If this were my one and only outbound parameter entry, then the part of the system that creates IDocs would ignore all other billing documents created in the SD module that do not have an exact match with those criteria (i.e., those parameters).

That is great if all I want to do is create an IDoc whenever an intercompany sales billing goes to my firm’s U.S. site (i.e., bill-to customer number 14855). However, I don’t think the accounting people in the U.S. would be too happy if I had stopped there. Merely creating an IDoc that has lots of reference data that could be used for the data entry into a transaction such as LIV does not help reduce anyone’s workload. The final step is to tell R/3 what to do with the data in the IDoc. You don’t have to go with LIV, for example, since it is appropriate only when you have an intercompany PO. If the intercompany transaction is due to a drop-ship sales order instead (i.e., the U.S. site makes the sale to a U.S. customer, but asks the German site to ship the product directly to the U.S. customer), then you could post the data using transaction code FB01 (i.e., FI module’s journal entry).

As shown in Figure 5, you do not make an inbound parameters entry in transaction code WE20 for the bill-to party customer, because it makes no sense to post a vendor invoice to a customer. Instead, the inbound parameters become your instructions on the A/P vendor account number that you want the data in the IDoc to be posted to. In my example, this is vendor number 103328. This represents my firm’s German site — the site that has sold some inventory to its U.S. affiliate.

Figure 5

Example of inbound parameters for vendor number 103328

Note two things in Figure 5:

• First, how does R/3 know that the IDoc it created earlier for customer number 14855 has anything to do with vendor number 103328 and, therefore, will act upon these inbound parameters that I have made?
• Second, why do I have three rows of inbound parameters here — one for message variant FI, one for message variant FI + message function FI, and one for message variant MM?

I discussed the answer to my first question in the introduction section. Specifically, this entire cycle begins with an intercompany PO from our U.S. site to our German site. There is never a sales order; the PO acts as the sales order. And, of course, every PO always has a vendor number, such as vendor number 103328. This vendor number, as well as all other data in the PO, is visible to the sales billing transaction and, therefore, can copy into the IDoc that is created whenever a sales billing to bill-to customer number 14855 occurs.

Figure 8

Linking to the IDoc field

Figure 7

Assigning the name in the invoice

Perhaps you can answer the second question on your own once you look at the detailed inbound parameters screenprint shown in Figure 9, plus a related screenprint shown in Figure 10. Notice in Figure 9 that one of the inbound parameters is something called a Process code — in this case, Process code INVL.

Figure 9

Example of detailed settings for the inbound parameters entry for vendor number 103328 and Message code (message variant) MM

Figure 10

Screenprint from customizing code WE42

Then, notice in Figure 10 that the customizing transaction code WE42 lists several process codes: INVF (FI Invoice receipt), INVL (MM Logistics Invoice verification), and INVM (MM Invoice Verification) — i.e., three different ways to post a vendor’s invoice. If the inbound parameters in transaction code WE20 did not have two extra fields called Message variant and Message function, then each vendor number (such as number 103328) would have to use just one vendor invoice data entry transaction no matter what kind of intercompany sales invoice prompted the creation of the IDoc.

For example, in my company, the U.S. site sometimes asks the German site to drop-ship the goods directly to the U.S. customer. In this case, there is a third-party sales order, but not an intercompany PO. Therefore, it is not appropriate to use LIV (which requires a PO number) to post the German site’s (i.e., the vendor’s) invoice. Yet, the bill-to party customer number and the vendor number in the sales billing document will be exactly the same as in the case in which the U.S. site purchased goods via an intercompany PO. Therefore, by using a unique output type in each kind of sales billing and then a unique message variant code in the outbound and inbound parameters, you can have both kinds of accounting data entry performed automatically.

In my example, the difference-maker became that MM message code that I used in my outbound parameters in Figure 4. Once again, notice how those outbound parameters (including my instruction to use message code MM) are only going to be looked at when the activity is billing (application V3) and the message type (also known as output type) is RD04. The final result becomes what’s shown on the right side of Figure 2 — an automatic journal entry on behalf of the purchasing company code, posted via the data entry transaction LIV.

A few pages is not enough space to show or demonstrate every detail involved in setting up automatic accounting for the purchasing company code in an intercompany sales cycle. For example, the EDI processing method via IDocs has additional customization steps that I did not mention. This is because it is used for a great many other purposes in addition to automated intercompany accounting. If you are looking for more detail on customizing this kind of automatic accounting functionality, download this document.

Christian Eckhardt

Christian Eckhardt has worked in the area of SAP Business Competence (Logistics) in the chemical industry for five years. He studied business administration with a major in business information systems at the University of Applied Sciences in Mainz, Germany.

If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.