Category Archives: CO-PA

CO-PA derivation from VBKD using table lookup

CO-PA derivation using table lookup is usually a single derivation step defined in transaction KEDR. For example to derive country, city and postal code of customer from table KNA1, we define a single step as shown below.

In case of derivation from table VBKD, we need to define two steps. If you take a look at the line items in table VBKD, some of the items have “POSNR” – line item number from sales order and some of the line items doesn’t have. If the line item information differ to that of header in the order, then line item number is populated and if it is similar to the information on header, then line item number is “blank”. So line item number information in table VBKD is inconsistent. Values in CO-PA could be missing or wrong in some cases if only one single derivation rule is defined.

First step:

Table lookup from VBKD when line item number exists. POSNR exists only if the line item is different from the sales order header information. If you are deriving from table VBKD, I expect that you need line item information in CO-PA. So make sure that this is your first step in the derivation rules. In this step define rule as shown below.

Source field POSNR is mapped to KDPOS. This rule works only if VBKD-POSNR has the line item information.

Second Step:

Table lookup from VBKD when line item number doesn’t exist.

POSNR is mapped to USERTEMP field which is “blank”. USERTEMP fields are generally used as value carriers from one rule to another, so make sure that the USERTEMP field used in this step is not used in any prior steps or user exits. Also you might want to make sure that the second step does not overwrite the values if derived from the first step.

Post cash discounts @ incoming payment to CO-PA & PCA

Cash discount based of payment terms is realized at the time of incoming payment and could apply to multiple line items in the invoice. So company might expect SAP to distribute these discounts to multiple profitability segments based of the invoice line items. In such requirement, use program SAPF181 to distribute discounts to profitability segments and profit centers derived from invoice. The following are the pre-requisites:

1. Discount account should have a cost element with cost element category “1”.

2. At incoming posting the discount has to be posted to a cost object such as cost center or internal order. You can use OKB9 to determine the object. Do not activate/check profitability segment in OKB9. (This value is distributed to PA and PC based of the invoice using program SAPF181)

3. Maintain PA transfer structure for the discount cost element pointing to the right value field.

At month end run program SAPF181. All costs are cleared from the cost objects and distributed to profitability segments and profit centers proportionately based of the invoice the cash discount belongs to.

Post value to two Value fields in CO-PA

A CO-PA value field is updated through several transactions across modules such as billing, manual FI postings, production variances through order settlement etc. To post values from SD, condition types are mapped to value fields and from FI, PA transfer structure is maintained where in which we map cost elements to the value fields. One of my friend has asked me if we can post to two value fields for the transactions originating from FI. The answer is “yes”. In PA transfer structure we can only map a cost element to one value field. So with PA transfer structure system throws a message and does not permit to assign a cost element to two different value fields in different assignment lines,but it can be done through an user exit “COPA0002″.

Before writing the code, first let’s look in the configuration steps. Create new valuation strategy in transaction code ” ” and assign a exit no for the valuation strategy. Second step is to assign this valuation strategy to the record type “B” in transaction ” “. This restricts function of exit or valuation strategy only for the postings from FI. Now write the code in exit COPA0002. Remember this arises inconsistencies between FI and CO-PA and apply right restrictions for the value flow to meet your needs.

KE21 vs KE21N for a CO-PA load

To load sales history in to profitability analysis, we post CO-PA only line items using transaction KE21N or KE21. If planning to load using LSMW, then I suggest using transaction KE21 instead of KE21N. In KE21N at recording using batch input, exact field names are not displayed and there is difference between the layout from the batch to actual recording. This would cause to load values to incorrect value fields or not load at all. It is not same with transaction KE21 and hence I recommend to use transaction KE21 to load CO-PA only line items using LSMW.