Hi Lara, Thanks for your question. I’ve decided to turn it into an "Ask the Expert" article because I believe that a lot of people besides yourself might be getting into trouble with unnecessarily complex design choices in FI/CO in general. Your case involving tax code defaults (Figure 1) is a good example of that. Based on your question, I believe that you are up against some tricky purchase-related tax settings that either came delivered with your R/3 system, or that a prior consultant created for your site several years ago. Often, new support team members such as yourself react this way to text description labels such as “taxable” and “non-taxable” within the R/3 table settings, although, in reality, what’s being looked at has no power whatsoever—by itself—to accomplish such things as defaults. And, I agree. It is very confusing. As an example, Figure 2 is a screenprint of one of the customization tables you mentioned (transaction code OMKN) from my company’s 4.6B development client. Notice how the two choices in the pop-up selection window imply that by choosing the 0 code or the 1 code, I can establish a default setting of Non-Taxable or Taxable for my plants. This can be extremely misleading to a person who was not on the original implementation team, prompting decisions much more complex than necessary. The truth is that although seeing descriptions like that naturally leads you to believe you are setting up tax defaults, in actual fact, the texts for these codes/indicators cannot be interpreted by R/3. Instead, the texts were put there merely to help us humans remember why we created the codes back in 1998 or 1999. Fast forward to the year 2003—with a new person placed in the role of FI/CO support—and your next train stop might be Miscommunication City. Not only are these old texts sometimes misleading, but the texts in the IMG menu tree can also fool someone new to the job. An example that includes IMG rows for two of the customization tables you said you made entries into is shown in Figure 3. Notice how everything there implies that you need to do something. In reality, these settings act merely as the less important out of three potential variables that you’ll need to create a tax code default in the purchase order. In fact, if your end users’ requirements are quite simple, you might not need to make any entries here at all. I’ll take the rest of this article to show you how the other two (and more important) tax code default variables interact to generate the opportunity to implement a simple tax code default. These two variables are the condition type’s access sequence and the condition type’s condition class. Within the next five or 10 minutes, you should have a lot more clarity on why it is sometimes possible to leave blank some or all of the standard R/3 customization settings related to a purchase order’s tax status. This can help you to keep your designs so basic that you (and others) have no trouble in calendar years 2004 or 2005 figuring out how it’s all working.

Access Sequence: An "If ..., Then ..." Search Instruction

Suppose that the name of one of your plants is USA1 and that all of the purchase orders for it, in general, are not relevant for tax. There is just one exception to this general rule. For purchases made on behalf of one particular material (R456) by one particular cost center (CC123), you should include a 5 percent tax in the price. In that case, if R/3 could understand English, you might send it an email with the following message: "If the cost center = CC123 and the material = R456, then go with tax code E5. Otherwise, if it is any other kind of purchase for Plant USA1 or for any other cost center in Plant USA1, go with tax code E0." To give this same instruction in language that R/3 can understand, you need: (A) two instances of a form of master data called a condition record, with the E5 tax code default instruction in one and the E0 tax code default instruction in the second; (B) two database tables to store the two instructions in. The reason you need two of the "B" category is because the who/what/where variables in each instruction are different. In one case, the variables you want R/3 to focus on when deciding which tax code to default is the value in the purchase order line item's Material field and Cost Center field. In the other case, it is the value in the purchase order line item's Plant field. Notice in Figure 4 the difference between the instruction on which database table to search (table name) and the instruction on which to search first vs. second (access number). Both of these instructions, combined, form what is known as the access sequence. The way this access sequence interacts with each new purchase order is shown in Figure 5.      

Beware of the Condition Class Setting

As discussed in the prior section, and as shown in Figure 4, the only way to link an access sequence to each new purchase order line item is through a price calculation variable in the purchase order’s pricing procedure that is known as a condition type. However, you must be careful when creating your condition type — not just with the link to an access sequence, but also with what you type into the condition type’s condition class field. The screenprints in Figures 6 and 7 show you why. In the left side of Figure 6, notice how the condition type that I created, called ZTCD, has a setting of B (for Prices) in its Cond. class field. The impact of this is shown in the right side of Figure 7 (note that the ZTAX Access Seq. is linked to only one table that, in turn, has only the Purch. Org. field active). When I create my master data instruction (using transaction code MEK1) for this condition type, there is no place for me to type in the tax code that I want R/3 to default into purchase orders when the plant is USA1, for example. I can type in a purchasing organization and I can type in a rate, but I have no data entry field for typing in a tax code. However, notice two things about Figure 8. First, every setting in the condition type is exactly the same as in Figure 6 except for the condition class field. In this case, I have now set this value to D, for taxes. Second, when I use transaction code MEK1 to create my master data instruction (Figure 9), I now magically have a field (column header reads Tax code) where I can type in the tax code that I want R/3 to use as a default when end users create new purchase order line items for any particular purchasing organization. Notice that I have been able to do this without troubling myself with any of the IMG transactions from Figure 3 that have text descriptions relating to tax. In general, a design that uses fewer settings is better than one with more settings, because it is easier to find, remember, and debug months and years after the implementation. Many of the IMG customization transactions relating to tax code defaults in the purchase order are there to support complicated business requirements. However, if your requirements are simple, it’s both better and possible to ignore those settings completely. In your specific case, I believe that you could get by with just a single condition type that has two settings: (1) condition class D and (2) an access sequence that is linked to just one table that, in turn, has only the Plant field active. This condition type would, of course, need to be somewhere in the purchasing pricing schema you use in your particular system. At that point, you would be able to create master data (using transaction code MEK1) that instructs R/3 which tax code to default into purchase order line items, based on the plant that the person who is creating the purchase order chooses in those line items.