Hi Paula,

  Thanks for your question. I think we can diagnose your problem! The first place to look, however, is actually not in your SAPScript form. Yes, it is logical to put instructions in there regarding which information to print from the Vendor Master (such as country code), and under what conditions (such as "foreign vendors only"). In reality, however, your SAP system already comes delivered with that logic as an optional feature! If we want it turned on, we just need to know how to activate it. To help you understand the role played by this optional feature, let’s first compare two alternative ways you can set up the formatting instructions — the final step in the address printing process:

• Giving R/3 the formatting instructions via a formatting program. The easiest way to give R/3 instructions on printing your vendor’s address on your hard copy checks is to ask R/3 to use the standard SAP formatting function called "ADDRESS."For example, the scary-looking code in Figure 1 (next page) is what we SAPScript folks would put into part of the Layout Set (or "Form") called a "Page Window." Here, I am merely asking R/3 to use the ADDRESS function, and I am passing the function some needed data values — for example, the country of the vendor (the "COUNTRY" variable) and the country code of "Paying Company Code" (the "FROMCOUNTRY" variable).
• Giving R/3 the formatting instructions directly. As an alternative approach to giving R/3 the "Page Window" instructions via the ADDRESS function, I could write the logic instructions directly into the SAPScript form (Figure 2). This would definitely produce the desired results. But, I’d have to be very proactive with my logic.For example, I’d need to make sure that I ask R/3 to print the value of the "NAME2" field of the vendor master only if the field is not blank — otherwise, a blank line would be printed.

Similarly, my instructions would also need to find out if the vendor’s country code is different from the "Paying Company Code" country code. If that condition is true (i.e., if the country codes are different), only then do I ask R/3 to print the vendor’s country (ZLAND) on the address section of the check.

Although they may look rather similar, the difference between the instructions in Figure 1 and Figure 2 is actually very important. In the typical approach shown in Figure 1, I am passing the data values (such as vendor name, vendor country, etc.) to the ADDRESS formatting function; whereas in Figure 2, I am actually giving the formatting instructions directly to R/3. Giving the instructions directly to R/3 not only creates a lot more work for me, but when you consider how many different formatting rules exist in the world (i.e., what to put on which line, for which countries, and under what circumstances), this approach has the potential for all kinds of unpleasant surprises for you in check printing! For this reason, I recommend using the ADDRESS function.    

&REGUH-ZANRE& "(Title) &REGUH-ZNME1& "(Name 1 field from the vendor master) If &REGUH-ZNME2  >   ' '. &REGUH-ZNME2& "(Name 2 field from the vendor master) Endif. … … If &REGUH-ZLAND& not equal &T001-LAND1&. &REGUH-ZLAND& "(Country code from the vendor master)

Figure 2

Giving Address Printing Instructions to R/3 Directly

Two "Global Data" IMG Settings Must Be in Place

The trick with using the ADDRESS function is that there are two relevant "Global Data" IMG settings that need to be in place for the function to work correctly. Since the role played by these settings is often not very well known, one or both of these settings may get ignored during a first-time implementation, or even a roll-out. And that is my strong suspicion as to the reason the check printing for your non-US vendors does not behave as you would expect it to. Take a look at the "Country Global Parameters" for country code US in Figure 3. The two settings you’ll want to verify are at the bottom of the screen:

• "Print country name" checkbox — This setting (on the bottom, right-hand side of Figure 3) indicates whether or not you want the vendor’s country to be included in the address.The first thing to do is discover whether this setting has been inadvertently left blank (i.e., not checked). For example, if it’s not checked for country code US, then you’ve discovered the cause of your check printing address mystery. If it is checked, then you’ll want to review the other relevant setting, the "Address layout key" field.
• "Address layout key" field — This setting gives R/3 instructions on how many rows are needed to address a letter to the country, what data needs to go onto each row, and in what sequence.For each of your vendors’ countries, make sure that the country code definition screen hasn’t somehow ended up with a blank or invalid "Address layout key."

   

Diagnosing Problems Related to Addressing in R/3

In general, a good rule of thumb when you have any kind of confusion related to addressing in R/3 is to ask yourself two simple questions:  How will R/3 know where to get the data from (data such as name, city, region, country, etc.)?  How will R/3 know how much of that data to print, and in what sequence? At the very least, these questions can usually help you discover what information you may be missing in terms of being able to diagnose the problem. So, in the case of your check printing mystery, you might answer the two questions as I have done in Figure 4. As you can see, the explanation of how the ADDRESS function formats the address data (second column, second row) could also help you to see your problem. If you’d like more information about the ADDRESS function, you can download the 4.0 system’s online Help explanation from the bottom of this article. Thanks again for your question. I hope I’ve managed to help you to get those country names printing on your checks — you must have gotten writer’s cramp doing it manually! I’ve enjoyed acting as the guest consultant for this issue. If any additional printing questions come up, feel free to contact me at the e-mail address below. Take care!

Where R/3 Gets the Data (Name, Street, City, etc.)	How R/3 Knows Which Data Values to Print and in Which Sequence
Prior to the “Print Checks” step, there is a step that merely saves the data for this particular “Check Run” into a table called REGUH. (This allows the end user to perform and save some of the work steps involved in executing the Automatic Payment Program, then stop and do something else, and finish the remaining work steps later.) Part of what gets stored in table REGUH is the address information from the vendor masters of each vendor to be paid in this “Check Run” — this address information includes all the field values from the “Address” view of the vendor master, whether or not all the values will actually be used.	The SAPScript (Layout Set) instructions for any given printed page will be contained in something called “Page Windows.” One of the “Page Windows” of your SAPScript will represent the address section of your check form. If you’re lucky, it will be clearly labeled. If you’re not, you’ll have to take a few guesses. Anyway, double-click on a likely “Page Window” to make it the active row. Then, choose from the menubar: “Edit > Text Elements.” You should then see a screen that looks similar to the one shown back in Figure 1. (Most likely, you can expect to see the ADDRESS function being called, as in Figure 1, as opposed to the direct coding option, as in Figure 2.)
When the end user eventually asks the Automatic Payment Program to go forward with the Check Printing step, R/3 calls the program that was listed in the “Print Program Parameters” screen. Although, in theory, this program can have any logic and rule imaginable, it will typically be told to get Name, Street, City (and so forth) from the REGUH table.	The ADDRESS function relies on the data passed to it from the SAPScript form (such as Name, Street, City, and so forth), and on one setting in the “Country Global Parameters” master — the country of the Sending Company Code being used by the end user in his or her “Check Run.” This setting is a checkbox called “Print country name” that tells the function whether or not it should include the country in the address of any correspondence going to a foreign location. The function also relies on a second setting in the “Country Global Parameters” master called “Address layout key.” In this case, this value relates to the country of the vendor we are paying, and the setting there gives R/3 instructions on how many address lines to print for mail to that country, and what data to put on which line. Note that there are only 15 unique sets of addressing rules in the world — use the “down arrow” on that field to see what they are!

Figure 4

How R/3 Knows Where to Get Check Printing Address Data and How to Format It for the Automatic Payment Program (Transaction Code "F110")

---