A thorough knowledge of how to manage signs (plus and minus) can prevent inconsistencies in the CO-PA module. The author tells you why you should avoid using a discount condition with different signs and provides a transferring method to use if the same condition must have different signs. Did you know that it's possible for the same posting from two different modules to have different values in CO-PA? It has to do with signs. By "signs," I mean the "+" (plus) or "-" (minus) signs assigned to amounts. I'm going to explain why you can get incorrect results in the CO-PA module when a similar transaction is posted from two different modules. I'll then describe a method — R/3's transfer +/- indicator — that allows you to correct this problem by transferring the balance of positive and negative values. Although this indicator is helpful in certain situations — for example, when you are providing volume rebates to customers — you'll see why you may want to restrict its use. At the end of the article, you should be able to manage signs so that CO-PA provides consistent results.

Signs in CO-PA

What is so special about signs in the CO-PA module? Didn't the R/3 system take care of signs for debits and credits in the Financial Accounting application? Yes, it did. To check whether the accounting document is balanced, the FI module assigns the plus sign to debit entries and a minus sign to the credit entries. However, CO-PA uses a different method. Let's look at how revenues are handled in the FI and SD modules for a typical revenue posting (Dr customer A/R and Cr revenues). In this case, revenues are negative in FI. However, for the same transaction, revenues are stored as positive conditions in the SD module. Similarly, sales deductions/discounts or costs are stored as positive in FI and negative in SD, as shown in Figure 1.

Typical revenue posting in FI Typical posting in SD Dr Customer A/R 70 PR00 Revenues 100 Cr Revenues -100 K007 Deductions/discounts -30 Dr Discounts 30 Figure 1 Typical postings and signs in FI and SD modules

Revenues can be posted to the CO-PA module from both FI (record type B) and SD (record type F) modules. So what sign should CO-PA assign to revenues? If CO-PA also stored revenues as negative and positive, major inconsistencies would result. For example, if CO-PA were to assign the signs the same as FI and SD, then the two revenue postings shown in Figure 1 would result in zero dollars in CO-PA. Obviously, that would be incorrect. To avoid this inconsistency, the basic CO-PA sign rule is that all amounts (revenues, discounts, costs) for invoice transactions are stored as positive. For reverse transactions such as returns and credit memos, all signs are reversed, i.e., all amounts (revenues, discounts, and costs) are stored as negative in CO-PA. This design ensures that even if the same values are stored with different signs in source modules, consistency is assured in CO-PA. The following are sign rules for FI and SD postings: FI postings: Figure 2 shows the sign rules for FI postings to CO-PA. Note that CO-PA uses cost element types to differentiate between revenue and deductions or cost accounts.   SD postings: Figure 3 shows the sign rules for SD postings to CO-PA through invoices or credit memos.  

Sign Design Problem

Now let's look at the potential problem that can be caused by this design. What if the same discount condition type exists in a billing document more than once but with different signs? Although it is not common, it can happen if you have multiple condition records with opposite signs. Let me give you a specific example, as shown in Figure 4.   An invoice shows revenue (condition PR00) for $100 and a net discount of - $35. However, the discount condition (e.g., K007) exists twice, once with - $40 and another with + $5. Let's see what happens in CO-PA. Applying the rules described above, the same posting from two different modules will have different answers in CO-PA. You know that the discount of $35 was given to the customer. However, when this invoice was posted, it posted as $45 to CO-PA, as shown in Figure 5.   The problem is that although the discount is actually for $35, the amount is posted as $45, because all postings in CO-PA are positive. The discount conditions are added, instead of being balanced. Try to avoid a situation in which the same discount con-dition can have different signs. You do this by creating two separate condition types: one for a positive condition value and another for a negative value. Review your business requirements and check whether you can create two separate conditions — for example, in Figure 5, K007 for 40 and K008 for -5.

Transfer with +/- Sign

Now, if you cannot avoid having the same condition with different signs, R/3 provides a method of transferring with +/- signs to transfer balanced SD conditions to CO-PA. For example, many companies offer discounts in the form of rebates to customers, depending upon the total volume of business over a specific period of time. For such rebate agreements, if and when the sales transactions occur, rebate accruals are generated based on rebate conditions. At the end of the rebate period, during rebate settlement, the rebate conditions are calculated with the opposite sign to balance the final rebate amount. In this scenario, rebate conditions have both positive and negative signs and therefore you should use the transfer +/- indicator. You use the indicator Transfer +/- in the configuration step Assign SD condition types to Value fields, as shown in Figure 6. The CO-PA IMG menu path is Flow of Actual values>Transfer of billing documents>Assign value fields, or use transaction code KE4I. The check box Transfer +/- ensures that the SD condition is transferred to CO-PA along with its plus or minus sign.   When you set the Transfer +/- flag for this condition type, the amounts are balanced before the SD module transfers them to CO-PA. As shown in Figure 7, the discount amount is correctly transferred.  

Problem with Transfer +/-

Although transferring with the +/- indicator has solved the issue of transferring the correct SD values to CO-PA, it causes an inconsistency for discounts with the FI-to-CO-PA transfer rule. In this example, the deduction amount is stored as -$35 in CO-PA from the SD side. However, the same posting from FI posted as +$35, as shown in Figure 5. Because of this issue, you should minimize use of the indicator. If you cannot avoid use of this indicator, you can resolve the problem by posting to two separate value fields, one for SD-to-CO-PA and another for FI-to-CO-PA posting, as shown in Figure 8. It shows two separate value fields, SDDedn and FIDedn for transferring the deductions.   Figure 9 shows an overview of the rules for postings from SD and FI. Note the possible conflict of signs for deduction postings made from different modules.