Hello Everyone

I would like to share a small, but useful tip to make the COPA reporting more inclusive.

Cash Discount to Customers as per the Payment Terms (GL maintained in OBXI) and Customer write-off during Cash Application in F-28 (GL maintained in OBXL) is a common business process. Many clients charge off this Discount or Payment difference to a Cost Center, unaware that it can be tracked at Customer Level or Customer / Product Level, etc

This requires an enhancement using exit COPA0005. SAP note 137552 offers a sample code, in which the GL Account is hard coded. I would like to present a re-usable snippet of code using FI SETS

In the present example, the Cash Discount is identified at Customer Level in COPA. If you wish, you can post it to Customer / Product level by reading those characteristics from the associated invoice.

DATA: i_ce1 LIKE ce1XXXX .                "Replace XXXX with the Op. Concern name

 

 

DATA:   lt_setvalues  TYPE TABLE OF rgsb4,

        gt_setvalues  TYPE TABLE OF rsdsselopt,

        lt_setval     TYPE TABLE OF rgsb4,

        gt_setval     TYPE TABLE OF rsdsselopt,

        lwa_setvalues TYPE rgsb4,

        lwa_values    TYPE rsdsselopt,

        lwa_setval    TYPE rgsb4,

        lwa_val       TYPE rsdsselopt.

 

 

DATA: lo_salesorder TYPE vbelv,

      lo_delivery   TYPE vbelv,

      lo_kunnr      TYPE kunnr,

      lo_kunag      TYPE kunnr.

 

 

"FM to get the values from SET ZFI_CASHDED. Include the OBXI and OBXL GL accounts in this SET

 

CALL FUNCTION 'G_SET_GET_ALL_VALUES'

  EXPORTING

    client        = sy-mandt

    setnr         = 'ZFI_CASHDED'

    table         = 'BSEG'

    class         = '0000'

    fieldname     = 'HKONT'

  TABLES

    set_values    = lt_setvalues

  EXCEPTIONS

    set_not_found = 1

    OTHERS        = 2.

 

 

IF sy-subrc <> 0.

  MESSAGE ID sy-msgid TYPE sy-msgty NUMBER sy-msgno

          WITH sy-msgv1 sy-msgv2 sy-msgv3 sy-msgv4.

ELSE.

  LOOP AT lt_setvalues  INTO lwa_setvalues .

    lwa_values-sign   = 'I' .

    lwa_values-option = 'EQ' .

    lwa_values-low    = lwa_setvalues-from .

    lwa_values-high   = lwa_setvalues-to .

    APPEND lwa_values TO gt_setvalues .

  ENDLOOP.

ENDIF.

 

CASE i_erkrs .                            "of your operating concern

 

  WHEN 'XXXX' .                           "Replace XXXX with Op. Concern name 

    i_ce1 = i_item .

    IF t_accit-hkont IN   gt_setvalues .

      LOOP AT t_accit WHERE koart = 'D' . "look for the receivable

      ENDLOOP .

      IF sy-subrc = 0 AND NOT t_accit-kunnr IS INITIAL .

        i_ce1-kndnr = t_accit-kunnr .

      ENDIF.

      CLEAR i_ce1-paobjnr .

    ENDIF.

i_item = i_ce1 .

ENDCASE.

e_item = i_item .

Note

1) This Code will populate the Customer # in the COPA document. The Profitability Segment in FI Document will continue to have a Blank Customer

2) Once the Cash Discount, Bad Debts or Payment Differences are identified at Customer level, you can optionally perform Top Down Distribution to take it down to Product level

Hope you find this re-usable asset useful

Best Regards

Ajay Maheshwari

Variance Analysis in Manufacturing Process and Product Costing

Dear All, presenting below information aiming to simplify the concept of variances and their calculation bases so it will be easy to understand the different types of variance which occurs in manufacturing process.

Variance calculation provides the difference between “Actual Costs” and “Target Costs” posted on order.

There three types of commonly found variances in manufacturing process –

• Total Variance
• Production Variance
• Planning Variance

• Total Variance –

  
  

Total variance generally found on the order because of difference between “Actual Debit” and “Actual Credits” which is delivered to inventory. The important points to consider here “Total Variances” are the only variances which are “relevant for settlement”.

Total variances are calculated with help of target cost version “0”. 

• Production Variance –

  
  

Production variance is always the difference between the debit actual costs consumed on order and target cost which is based on the preliminary cost estimate and quantity delivered to inventory.

Production variance is calculated with the help of target cost version 1. These type variances are like “For Your Information” purpose only and are not relevant for settlement activity.

• Planning Variances –

Planning variance generally arises because of the difference between plan costs on an order and standard cost based on cost estimate. Planning variances are generally computed based on Target Cost Version “2”. Again these kinds of variance are not meant for settlement and for analysis purpose only.

Example can be used here is – BoM and Routing chosen for production and costing use are different and this results in planning variance.

  Variance are again broken down into following categories as below –

Let’s see all variance categories explanation one by one –

Input Variance –

Variances reported on the input side of manufacturing orders from business transaction like goods issue, general ledger and overhead calculation etc.

• Input Price Variance –

  Input price variance occurs because of changes in prices which is planned price and actual price.

Let’s say material is valued $20 at the time of costing run. Afterwards prices changes of material and at the time of goods issue for a production order material is valued at $30. The variance report will show input price variance as $10.  

• Resource Usage Variance –

This kind of variance generally occurs when the substitute component is used instead of planned one.

When the planned material is not and alternate material is used in production process the resource usage variance is seen because of cost difference of both materials.

It was planned to use material X in production process at value of $35 and due to shortage of material X, material Y is issued for production order which is valued at $40. Now due to the issuing of material Y instead of X the resource usage variance will be $5.

• Input Quantity Variance –

  Input quantity variance occurs because of difference between the planned and actual quantity and activities consumed.

The activity of with the time of 20 minutes was planned and actual time confirm against production order operation is 30 minutes and activity rate for this is $10 per minute then input quantity variance is $100.   

• Remaining Input Variance –

When available variance on order is not possible to assign to any of the categories above mentioned system treats this as a remaining input variance.

The possible reason to get the remaining input variance is overheads rates are changed meanwhile.

A component is valued at $200, and associated material overhead is valued at $10 (10% of $200), during the initial costing. The material price subsequently changes, and during goods issue to a production order, it is valued at $220.

During period-end overhead calculation, actual overhead is posted as $22 (10% of $220). Variance analysis will report an input price variance of $20 due to the component price change, and it will report a remaining input variance of $2 due to the overhead change.

• Scrap Variance –

  A scrap variance is kind of variance which is calculated based on difference between the planned scrap and actual scrap.

Actual scrap posting occurs at the time confirming the activity and mostly if actual scrap quantity is as per the planned scrap quantity then there is no scrap variance.

Output Variance –

Output variance can be seen on the order because of less or high quantity is delivered on the order or the delivered quantity is valuated unlikely.

• Mixed Price Variance –

Mixed price variance occurs when material is valuated based on using mix cost estimate. The target cost of credit in this case is dependent on confirmed quantity of standard cost from procurement alternative and actual cost is depend on actual quantity confirmed on standard price.

Procurement Alternatives are stored in Table CKMLMV001

Generally this is the difference of planned credit of Actual Quantity X Standard Cost of procurement alternatives defined and Actual Credit of Actual Quantity X Standard Price.

Suppose if you have standard price based on production version X and production version Y.

Production Version X – 200

Production Version X – 300

The cost estimate is release with 50:50 ratios at 250

If the actual production happens based on production version X the mixed price variance will be 200 – 250 = -50

If the actual production happens based on production version Y the mixed price variance will be 300 – 250 = +50

• Output Price Variance –

  The output price variance occurs because if standard price is changed after the credit posted to stock and before calculation of variances on production order.

The standard price of the material is marked at $85 and system delivers to stock 20 quantities for a production order at a standard price. Now if new value is calculated at $100, the system calculates the target cost $2000 and in this situation the output price variance will be $300.

• Lot Size Variance –

  
  

The lot size variance arises due the difference between the lot size used in manufacturing order and lot size at the time of standard cost estimate.

Suppose user has setup cost $2000 for 20 HRS which is fixed in nature. Now while actual manufacturing process the lot size used is 200 and standard lot size is 150 then we may see lot size variance as a $1000.

• Remaining Variance –

  
  

Remaining variances occurs on order when system is not able to assign variance to any categories.

Remaining variance also considered when target cost of the material is not present in system as like when standard cost estimate does not available in system or goods receipt against a production order has not been performed.

Thanks all for reading this, I will appreciate your comments / guidance notes and suggestions on this.

Regards,

Pankaj Bhalerao.

     SCENARIO

The trade route is the flow of goods going from one object (the supplier) to another (the buyer).

In the multinational groups this is a frequent scenario: a plant supplies one or more companies in the same or different countries, with goods to be sold or used as component of another production line.

The two subjects, buyer and supplier, create each other as customer and / or vendor depending on the role played in the business trade (if they sell or buy).

Mostly, as I/C customers / vendors, a specific naming convention and data setting will be used in order to address correctly the postings and the final data consolidation.

Let's imagine, as example, that a company in France, by one plant, supplies several countries (example: Italy, Colombia, Malaysia and Pakistan), and that the group headquarter decides to replace this supplier with another one, always part of the group, based in Netherlands, as per below picture:

Before the replacement of France with Netherlands, the French company has all of the four countries companies created as customers, while the four countries have the French company created as Vendor.

Before Day 1, when the supplying process will start from Netherlands, Italy, Colombia, Malaysia and Pakistan need to create Netherlands company as Vendor, and Netherlands the four supplied countries as customers. Of course if not all the players stay in the same SAP environment, the task will be performed in its own system / client (that can also be outside SAP).

The activities to be performed for the trade exit are the following:

During the analysis phase, it is important to analyze the following aspects

In case of Carve out / Sale of a division by a group, it is possible that temporary some companies run on the system of the previous owner, waiting to be migrated to the buyer's system.

In this case maybe only part of the list of activities before mentioned has to be performed (only the Vendor or Customer part). In this case it can also make sense to not "touch" the logistic side (logistic Customer / Vendor, purchase info record, source list), and just create a new financial customer / vendor to be used to update the Sales Orders / Purchase Orders (in the "Payer" partner function) and migrate the financial open items.

This solution is based on the update of the partner functions within the SO / PO, as shown in the picture below for the PO:

In this case the Logistic Vendor (C03841) has not been changed / replaced with a new logistic vendor, and so no new Purchase Info records and Source Lists have been created. But a new financial Vendor (GK38_G2_11) has been created for the same subject and used to address the financial invoices (IR) to the correct vendor / reconciliation account. This choice has been motivated by the next migration of the divested division to the buyers platform. Changing all the logistic settings just for a short period of time during which the business keeps on running on the seller's platform was not worth. The buyer accepted to have discrepancy between the logistic vendor name (the old hub - France, in the example) and the financial vendor name (the new hub - Netherlands, in the example).

SCENARIO

In the Pharmaceutical companies, as well as in other industries, the profit center object is used to represent the "division" in the accounting process.

All the values, analysis and targets can be measured at profit center level, This means all the financial postings need to be addressed at profit center level, and the profit center reports are the real tool to measure the performance of the Division,
.

All the postings coming from Finance and Controlling, as well as from Purchasing, Sales and Production, are collected by the profit centers, and there, during the month end / quarter / year end closing, all the assessments are posted without necessarily "touching" the financial accounting books.

If, as it usually happens, it is necessary to consolidate at group level the data coming from several systems, both SAP and NON SAP type, a legacy tool is used to collect, integrate and harmonize all the "numbers". In this case the data available at profit center level are then transferred, according to a defined procedure, to the external / legacy official reporting system:

PROFIT CENTER AND PROFIT CENTER HIERARCHY

The Profit Center hierarchy is based on a top level formed by profit center hierarchy nodes representing the medical areas of activity (Pharmaceutical, Oncology, Research, Vaccines, Generics, etc.), plus one node related to the Corporate area:

A dummy profit center is also created.

The code of the profit Center node is also the "code" of the division. So division "15" is the "Vaccines" division, division "16" is the "research" division, etc.

Below the top node there is a breakdown of the areas of activity of the main medical area. For example, the "Vaccines and Diagnostic division" manages two areas, "Vaccines" and "Diagnostic".

The Vaccines subdivision manages two areas: the single product areas (Brands), and the services connected to them (for example "Marketing"):

The lower level of the hierarchy, meaning the leaves, is formed by the real profit centers and is used to represent the single activity (a service, for example) or a single kind of product (for example the "pain killers"). The profit center is not the product itself. Indeed the product is represented by the material master, to which the profit center is connected.

PROFIT CENTER AND MATERIAL MASTER

As mentioned before, the material master record (transaction MM03) represents the single product.

Under the tab. "Plan data / stor. 2" it's possible to find the profit center:

In the table MARC it's available the link between Material and Profit Center;

SCENARIO

You run the CKMDUVMAT transaction and doubled the releases.

Transaction: CKMDUVMAT

It is used to inventory difference distribution

SOLUTION

Run the program MLHELP_CANCEL_DUV_DOCUMENTS the transaction SE38 and inform the selection data

NOTE

The MLHELP_FIND_DUV_POSTING_ERRORS program allows you to analyze errors in posts held.

SAP Note: 1756761 - CKMDUVMAT: Cancel duplicated DUV postings

Transaction:CKMI_RUN

The CKMI_RUN transaction is intended to perform 'release closure for execution' costing for the desired period

SCENARIO

I was trying to run the CKMI_RUN transaction ownership costs and displayed the message of C + 831 error

REASON

Be allowed to carry out settlement for the period and the desired plant.

SOLUTION

Run CKMC transaction for the period and plant displays in the error message to solve.

Transaction:CKMC

The CKMC transaction report which plant / material should be finalized by CKMI_RUN transaction so you can start the next period with the releases.

Dear All,

Thanks for given opportunity to upload this document, which will help FICO consultants during the working on TDD – COPA.

This document prepared based on my knowledge and experience, working on many TDD issue and some issue raised with SAP expert via OSS message. So I thought why not create such document which collect all information related to TDD. So I prepared this document and sharing with you.

Thank you

Akesh Agrawal

=================================================================================================================

SAP - Controlling

CO-PA – Profitability Analysis

Top-Down Distribution

(TDD)

Transaction Code:

Transaction Code: KEBC (Set Operating Concern)

Transaction Code: KE28 (Create/Execute Top-Down Distribution)

Transaction Code: KE29N (Top-Down Distribution Log Overview)

Purpose of the Document:

To know what is the Top-Down Distribution (TDD) in SAP.

To know how TDD works in COPA

Target Audience:

Consultants in SAP FI-CO Financial Accounting and Controlling module.

Disclaimer:

1. Some of the discussion is taken from the SAP Documentation.
2. Some of the data is hidden to adhere to data security policy

Business Purpose of Top-Down Distribution

In Profitability Analysis, sales revenues, sales deductions, and costs of goods manufactured are generally stored at the customer/product level. However, many business transactions - such as freight invoices, insurance expenses, or advertising - cannot easily be assigned to such a detailed level in CO-PA. Consequently, these need to be posted at a summarized level, such as the division, sales organization, or company code level.

Top-down distribution of actual data is a periodic function that lets you distribute this aggregated data to more detailed levels in CO-PA on the basis of reference information (such as the data from the previous year/previous month).

The data is distributed according to existing "reference data". You can use either planning or actual data as a reference. You can also distribute period by period, or aggregate the period values to smooth out variances.

The system distributes the data by value field or according to how the values in the selected value field are distributed.

When top-down distribution is executed, values that are not assigned at the higher level (#) are distributed. Characteristic derivation occurs but only for those characteristics that were used in summarization (in other words, those values for which the summarized field in the processing instructions screen was selected).

You can perform distribution in any of the following ways:

• You can select values posted to any profitability segments and in any value fields, and then distribute this data to a specified distribution level.
• You can use existing actual or planning data as the basis for this distribution. The basis can be the values in a single value field (such as revenue) or a calculated value (such as contribution margin 1) or occur by value fields.

  You can also distribute period by period, or aggregate the period values to smooth out variances.

Using top-down distribution of actual data can lead to quite large data volumes, since the data is distributed to a large number of profitability segments.

Activities

You execute the top-down distribution of actual data by choosing Controlling >Profitability Analysis >Actual postings > Period-end closing > Periodic adjustments > KE28 - Top-Down Distribution from the application menu.

Entries for the actual data

1. The posting periods or -- if you are using the alternative period type -- the weeks that you want to distribute
2. The record type of the data you want to distribute

Entries for the reference data

1. Enter the periods from which the reference data should be selected.
2. Specify whether you want to reference actual data or planning data. If you reference planning data, enter the plan version from which the data should be selected.
3. Enter the record type of the data you want to reference.
4. Select the Aggregate period’s field if you want to add together the period values of the reference data rather than distributing them directly. This gives you the same value in each period for each segment, to smooth out incidental differences which occurred from period to period (see also Example: Period Aggregation).

Entries for the reference base

1. Select the Single value field if you want to distribute all the value fields in proportion to the values contain in one value field. You can use any value field or key figure (formula defined using value fields). The key figures you can use here need to be defined in Customizing.
2. If you have selected the Single value field, enter the value field that you want to use as the distribution factor.
3. Select the By value fields field if you want to use each single value field as the basis for how that value field is distributed. This means that the value field Revenue would serve as the basis for how the revenues are distributed.

Entries under Extras

1. Select the Test run field if you want to distribute your data without making any changes to the database for (only testing the correctness).
2. Select the Background processing field if you are distributing for a large number of segments. The system will execute the function in the background so that your system is not loaded down unnecessarily.

Processing Instructions push-button

Here you can specify how each characteristic should be processed in top-down distribution:

• Distribution level:
• Retain/Cpy:
• Summarize:
• Ref: The characteristic values of the selected characteristic are transferred directly from the source data. However, the system uses different characteristic values of the characteristic as reference data when determining the distribution key. (Refer attached excel) 

Selection Criteria push button

Here you can restrict the amount of profitability segments that you want to delete. You can enter one or more single values or an interval for each characteristic. All the values of that characteristic are distributed if you enter an asterisk (*).

With ref to Processing instruction screenshot here:

1. In Distribution level we have selected ‘Local Level 01’ and ‘ConsumpOccassClass03’ in “DLvl” characteristics we want to distribute to.

1. In Retain/Cpy here we have selected all characteristics you already have in COPA records you want to keep as it is in above screenshot we have ‘Product’, ‘Company Code’, ‘CO Area’, ‘Business Area’ and ‘Sales Org’

1. In Sum we have select all other characteristics that should be derived during TDD Like ‘Distr. channel’ and ‘Division’ etc.

Actual Data before TDD

With ref to above selection what doses the systems technically do:

Retain/Cpy

• The TDD selects all lines in COPA that have a characteristic ‘company code’ and ‘Local Level 01’ and ‘ConsumpOccassClass03’ not assigned
• Summarizes this records by ‘company code’, ‘Product’, ‘CO Area’, ‘Business Area’ and ‘Sales Org’
• Creates a ‘cancellation’ line by ‘company code’, ‘Product’, ‘CO Area’, ‘Business Area’ and ‘Sales Org’
• This value will not be changed during TDD!

Distribute:

• The TDD will look for the total “Picking Time” by ‘Local Level 01’ and ‘ConsumpOccassClass03’ posted in a specific period for a specific record type.
• Distribute the amount posted on higher level of characteristic according to the “Picking Time”  from the reference data  (e.g. from cost center allocation)

Summarize:

• On the cancellation line the TDD will set all characteristics where you selected ‘summarize’ to ‘blank’. (In our example ‘Distr. channel’ and ‘Division’ etc.)
• After TDD: for the cancellation line item the field which is blank in original line item will remain as it is. The derived characteristics in the cancellation line item will also be in line with the derivation of original line item.
• After TDD: for distribution characteristic field which is blank in original line item will be derived from the characteristic derivation rule for the distribute line item.
• For those characteristics that are neither selected as distributed nor retained, you should leave the default values “*”for this characteristics.

Value Fields push-button

Here we have to specify the value fields of the operating concern that we want to distribute those value field you need to select. In our case we have selected value field for distribution is (Media Trd., Other Adv ).

Note:

• ‘Company code’, ‘Product’, ‘CO Area’, ‘Business Area’ and ‘Sales Org’ will be unchanged (No derivation!)
• Amount will only be distributed to Company Code-CC01, Product-PD1, CO Area-COA1, Business Area -Blank and Sales Org-SO01.
• Distribution amount for the ‘Local Level 01’ and ‘ConsumpOccassClass03’ is calculated based on “Picking Time” by ‘Local Level 01’ and ‘ConsumpOccassClass03’.
• ‘Distr. channel’ and ‘Division’ is derived based on derivation rules during the TDD

Actual Data after execution TDD

Top down Distribution KE28 Actual work as per details given above.

Important Notes:

1. The error message KG323 is issued for top-down distribution for the actual data (Transaction KE28): 'Value could not be distributed” In most of Top-Down Distribution cases system give the above error message “Value Could not be distribute”

Basically for the system to find reference data for the selection criteria given in the variant there need to be line items in the reference data which have the same characteristic combination as those in the source data for the characteristics selected in the 'CPY' column of the processing instructions.

You must consider important fact that error message is always raised for concrete segment (given by characteristics with processing option copy)

In this case the error message KG323 which is raised by system you have to check the first log and verified that this characteristic combination does exist in the reference data?.

For Example:  In below TDD case Controlling Area characteristics selected in “CPY” column of the processing instruction. 

In below source data and reference data is not same therefore system will give the error message KG323.

Refer below table screenshot where you can see that Controlling Area = 'CO01' in the Source (Actual) data with record type “B,C & D” while the system searches for the char combination with Controlling Area initial (Refer below screenshot 2)

In reference data Record type “X” Controlling Area is blank. (Refer below screenshot 1).

Actual/Source Data:

Reference Data:

When any characteristics selected in the 'CPY' column of the processing instructions that characteristic value should be same in Source/Actual data and Reference data. For example Business area in Source data is “Blank” and in reference also it is “Blank” so system will not give any error because in both side Business area is blank.

But as seen above case that in reference data controlling area is blank and in source data controlling area is available “COA1” both side data is not same so system will issue the error message KG323 “Value could not be distributed”

2. In Some case Top-Down Distribution log shows that TDD executed successfully but when we see the details result TDD not allocated any value, receiver not updated.

In the TDD the characteristics 'local level 1' and 'consumpOccassClass03' is selected in “DLvl” (Refer screenshot)

In variant you have selected value field for distribution is (Media Trd., MedCst-NTr, Other Adv, Ch.Ag. Fee, PE-Cons.,PE-Trade, AdvPrd C.T, Adv.PC NTr, Adv.Ag.Com,Adv-Trade ).(Refer screenshot)

1. For the values to distribute to the two characteristics , the following conditions should be satisfied:

    a.    The two characteristics 'local level 01 and 'consumpOccassClass03' should be initial (should have no characteristics values-i.e should be blank or null) 

    b.    With the null characteristics values, the value field totals of the value fields selected for distribution should not be zero. If it is zero, there will not be any distribution.

(e.g. When you checked the report KE24 for record type  B, C, D, company code CO01, Period  003.2012 and filter for two characteristics 'local level 01 and 'consumpOccassClass03' with blank values, the value fields total is Zero (0), that means there is nothing to distribute in TDD.

So basically there is nothing to distribute and hence there is no top down.

3. In Some case you use transaction code KE28. After execution, system issues error message KG323 "Value could not be distributed" (The percentages of the reference data were all zero.) in the log, even though you are sure that the reference data exists. Note that the mentioned error message is usually correct and the reference data are in fact missing. For this purpose consider notes 77476 or 110164.

Problem solved by this message is related only to situation if following conditions are fulfilled:

• selection used for periods in source and reference data is the same
• reference data are actual data
• selection used for reference data is defined with several record types
• record type used for selection of source data is also included in selection used for reference data

If above situation fulfilled then this is program error then you need to apply the attached program correction or implement appropriate

Support package (for further details check SAP Note 763720 – Released on 09.11.2011)

4. You use the top-down distribution in CO-PA and read the necessary CO-PA data from summarization levels. If many line items are created with several runs, they must each be read with subsequent accesses at summarization level, which means that the runtimes of consecutive distributions may grow disproportionately to the data volumes.

If all summarization levels used are up-to-date and the results of the sequential top-down distributions DO NOT influence each other, that means you do not have to use current data. The status of the data from the last setup of the summarization levels would be sufficient. In this case the line items would not have to be read.

NOTE: As a result of this MODIFICATION, the system no longer reads the current data, but only the data as of the last update run of the summarization levels. Note that the summarization levels must be updated before the allocation is executed, if the data for the sender and/or the reference data of the consecutive top-down distributions has changed. To ensure the data of the summarization levels is consistent, records posted 30 minutes before the update are not included in the summarization levels (security delta). This means that half an hour must pass after posting CO-PA data, before you may update the summarization levels.

If you want to import the reference data ONLY without reading the line items, implement correction 1.

If you want to import the sender (Source Data) AND reference data without reading the line items, implement correction 2. (For more details refer SAP Note 1039567)

5. Transaction KE28, option 'Cumulate Record Type' is selected: user can enter the same value of record type in selection for source (actual) data or for reference data more than once. Such selection isn't logical (especially in case of source data) and it leads into unexpected and unclear results. Program error, which occurs only in case that option 'Cumulate Record Type ‘is selected.

In above case when we used cumulative record type (duplicate entry possible for record type), some time system behavior is different and thru the unexpected result of TDD, for solution prospective read the OSS note 1608281 which is release for the this issue.

During a top-down distribution, one of the following problems occurs with unit of measure fields:

1. You execute a top-down distribution and notice that the units of measure fields have been filled incorrectly in some receiver line items (for example, are initial, even though they should have been filled).
2. You want to select the setting for summarizing the value for a unit of measure field in the processing rules during a top-down distribution but you cannot do this because the "Transfer Value" setting specified by default is grayed out and can no longer be changed.
3. In the definition of a top-down distribution on the "Selection criteria" screen, you cannot enter any characteristic values for unit of measure fields.

There is program error for correction you use at least package “SAPKH60507”

Call transaction SE91, enter the message class KG and create message 880 with the following text: "Distribution level option is not allowed for unit of measure fields". Then you need to apply attached source code correction. For more details refer OSS note 1634827.

7. In some case transaction KE28, top down distribution for actual data. Correction provided by this note is applicable only in case of option 'Cumulate Record Type' is enabled. During check of the result of the top down distribution run it's recognized that source data in addition to the 'real' reference data is used as a reference base for distribution of data.

This is program error SAP has release OSS note 1635792 on this issue

8. In most of case Top down distribution actual KE28 “processing options” for characteristic “Business area - GSBER” there is a need to be keep in “CPY” option even we are not using “Business area – GSBER” in our system. 

If we try to set the “Business area – GSBER” in summarize option system doesn’t allowed you to change it. Because characteristic “Business area – GSBER” is an important Organizational element. But in some cases after upgrade from older released it is possible to change the from “CPY” to “Summarize” there is OSS note 604523 way how to enable the options and remove such restriction for “Business area – GSBER”. Please note this is not SAP Standard functionality. 

9. You use transaction KE29N. You select a log that belongs to transaction KE28. You want to display the detail log, but it takes too long. “There are too many senders in the top-down distribution”

Create the following text symbol manually in the program SAPLKEPROT: 001 Create list of sender? (May take a few minutes)The number of senders is evaluated. The list of senders is only created if the number of senders is not large or if the user permits this in the dialog displayed (For more details refer SAP Note 1272897, 1555387 & 1483037).

Thank you..

1. 1. Parallel Accounting

Parallel Accounting: The ‘Parallel Accounting’ in SAP is achieved by storing and posting data in various ‘accounting principal’ in separate ledgers, with the data for one accounting principle stored in the G/L (leading ledger) as the ‘leading’ valuation view. Additional ledgers (non-leading ledgers) are used for each of the (parallel) accounting principles.

                The advantages are:

• No additional G/L account are required
• Each accounting principle is maintained in a separate ledger
• Different fiscal year variant can be used
• Ability to make use of the standard reporting functionality for bringing out financial statements under this customizing step, the following activities are carried out:
• Define accounting principles: The required accounting principles, as decided by the local and group statutory reporting, are defined
• Assign ‘ledger groups’ to accounting principles

1. 1.1 Define Accounting Principles

How to configure

Create new entries by clicking on New Entries. On the ‘New Entries: Overview of Added Entries’ screen creates the required accounting principles.

1. Accounting Principles: Enter an identifier for the accounting principles. We will use ‘IAS’, ‘GAAP’ and ‘LOGA’ to denote the various accounting principles.
2. Name/ Description of Accounting Principles: An appropriate description is entered in this field against the accounting principle identifier entered in above.

Save the configuration once it is completed.

1. 1.2 Assign accounting principles to Ledger Group

How to configure

• On the ‘Change View “Assignment of Accounting Principles to Target Ledger Group”: Overview’ screen, create new entries by clicking on New Entries.

1. Accounting Principle: Select the accounting principle from the drop-down list.
2. Target Ledger Group: Select the appropriate ledger group to be tagged to the accounting printiple selected in (1) above.
3. Description: The system brings up the description of the ledger group.

• (ii) Save the entries.

SUMMARY

The following document describes the usage of SAP Customer master data to manage the intercompany relationships between the several players within the same group.

The different companies, belonging to different divisions within the same group, to trade between them create each other as customers and / or vendors. Naming conventions and actual settings are described with the goal of providing a possible approach for implementations / re-engineering of intercompany processes.

The following document reflects an implementation in the Pharma industry, but it's easy replicable in other business industries.

NAMING CONVENTIONS

The naming convention of the financial Customers is used for the following reasons:

1) To identify the intercompany nature of the customer;

2) To identify the country of the company;

3) To identify the division of the customer;

4) To report and consolidate the data for the division the customer belongs to.

There can be two cases:

1) The Customer belongs to the same division of the company where the vendor is created (subject A supplies subject B - A and B belong to the same division - A creates B as customer)

The customer C105_42 belongs to the country C (C= Switzerland or Colombia, BE = Belgium, etc.) and to the division "42". The division is indicated by the code after the "_". Both buyer and seller belong to division "42".

2) The Customer belongs to a different division of the company where the vendor is created (subject A supplies subject B - A and B belongs to different divisions,  - A creates B as customer)

The Customer C028_11_15 (of country C=Switzerland) belongs to the division "11", while the buyer, meaning the company where  the customer is created, belongs to the division "15".

PARTNER FUNCTIONS

Depending on the role played in the business process (supplier or demander), the companies are created as Customers in the companies they deal with.

For the following reasons, the same company is created as Customer twice, once as "Logistic Customer" and once as "Financial Customer":

1) All the logistic data are referred to the logistic customer so, in case of any change of the financial customer, it is not necessary to recreate them;

2) Maybe the trade route can change. using the business partner functions available at Sales Organization level, it is possible to replace one or more of the master data involved as "Bill-to-party", "Ship-to-Party" or "Payer" without touching the logistic settings.

The same subject is so maybe created twice. It is advisable to use two different account groups, in order to be able to manage both the different  information needs (different layout of the master data, different mandatory / hidden fields to fill / display) and to clearly recognize and distinguish the role played.

Below an example:

1) Logistic customer

The code of the customer is CH105 - CH is the country of residence of the customer, while the rest of the digits is a progressive number:

The account group is Inter-Company Plant

2) Financial customer

The financial customer code is XXXX_42

The account group is Intercompany - Finance

To display the customer master data, run transaction XD03:

Fill "Customer" and "Company code" and click "Customer's sales area":

Select the Sales Organization by double-clicking it:

Press "Enter":

The logistic customer (CH105 - Account group Intercompany Plant) plays the logistic role but the financial payer (PI) is played by customer C105_42 - Account group Intercompany Finance). This means when a Sales Order (shortly SO) is created against the logistic Customer CH105, automatically all the partner functions are populated within the partners tab of the SO itself with the settings available in the CH105 master data, as in the picture below:

All the logistic objects are created with reference to the vendor CH105.

Since Vendor C105_42 is used for the partner function PI - Payer, the invoice created for this SO will be directly addressed to this customer, meaning the financial document will use C105_42 as customer:

Since C105_42 is indicated in CH105 master data as "Payer", will be defaulted as PI in the Sales Order partner function tab. It is however possible to replace it with another one that will work as financial customer for the specific SO case.

What indicated in the logistic master data as partner function is just a default for the Sales Order, so it can be updated directly there without touching the customer master data.

It is important to remember the reconciliation account of the intercompany customer must be appropriate:

In case of Vendor XXXX_DD (where DD is the division), the reconciliation account will be 220061 - Intercompany own sector, while in case of Vendor XXXX_DD_YY (where DD is a division different from YY), the reconciliation account will be 220100 - Intercompany other sector.

The Customer partner functions per Sales Order are available in the table VBPA, as shown below:

it is important to remember that the partner functions here have a different code from those displayed in the user transactions.

For example RS corresponds to PI (Invoice presented by), as shown below:

Hi

As you know with t.code MLCCSPD can see cost component per material.

Sometimes you need see Multiple Materials in SAP Standard there is no this report .

with Join table CKMLHD, CKMLPRKEKO , CKMLPRKEPH in SQVI you can create multiple material cost component report.

1- Go SQVI and create on the quick viewer.

Note:  Data source -Table join

Insert table: CKMLHD, ,CKMLPRKEPH,CKMLPRKEKO

from ckmlhd select Material Number , Price determination

from CKMLPRKEKO select base unit , Lot size

Lot size show you  per how many material cost component calculated

from CKMLPRKEPH select  posting date yyyy,posting period, type of perice ( this field show you : standard,periodic unit price , ....)

Currency type and valuation view, Currency key and cost filed 1 to 40 ( this difficult steps because you don't no cost component header and in result you must create correct layout)   

Execute

Note:  in field Type of price you can choise Period unit price ( this actual perice if M.L run) standard price , ...)

Indicator lower level must null like picture. 

Material Price determination = 3

Execute one material  for  proving

Now Execute for on period

Result

Hello all,

The following example shows you how to construct the cost center report to create a report with Report Painter, choose the following path.

Spro~Controlling~Cost Center accounting ~Information System~User defined reports~Define Libraries: In Sort Cut t code-GR21

Create Library initial screen will display like below. Give Library Name "XXX" and copy library from "1VK"  then press enter and save.

Then Go for report painter  creation screen

Spro~Controlling~Cost Center accounting ~Information System~User defined reports~Create report : In Sort Cut t code- GRR1

then click on create report give library name which you create in asap screen ex: "Z17" ,report name with transaction code like "ZCCAREP"

Then it will shown below screen which you given in asap.

Then double click on that report ex: "CCAREP" you will see the report format on right side.

Click on first Column and change the column name as "Previous Month" text like below screen.

After the confirming the next button press enter or right option below elements  screen will display.

Give Basic Key Figure as" COST "

Then Select the Characteristics which is required for your report for ex :

Period from: " 1 PERVP"

Value period : "4"

Fiscal  Year : "1CGJAHE"

Version : "0"

Like that we have to create for next column  also .

Give Column name as Current month same like above process and give some fields which is required for current month example see the below screen short .

Click on next Column For year to date process like below screen  here the values will show like full year 1 to 12 months

Then Chang the text and give below screen short parameters like what we required.

Period: "1 " , To period "1 PERIK"

Value Type : "4"

Fiscal Year : "1CGJAHE"

Version : "0"

Next we have to create the report Group.

SAP Easy Access ~ Accounting ~ Controlling ~ Cost Center Accounting ~ Information System ~ Tools ~ Report Painter ~Report Writer ~ Report Group:In Sort Cut t code - "GR51".

A report group contains one or more reports from the same library. When reports contain the same characteristics and share the same data, then they should be attached to the same Report Group so as to improve the processing time.

Create report group name " Z08M or 'xxxx' ",Library " Z17 " which you create on first snap short.

Give the Report group “Z08M” give the library “Z17” the enter Assign the report to that report field “ZINCR001” then save.Generate twice in the screen press enter again Again Generate the red button then save.

  We assign group  in that report,name which you create on top of the screen ex : "CCAREP"

If you want cost center  group like a tree then click on this on report and design screen . with tick mark

Click on edit general data selection and give the below fields. It will applier in the selection screen in the report

If you want any interface with cost center report.

Use the Transaction code  "GR52 " change screen you can see the screen like which you create in above and assign report interface to report

It will display like below screen

Then click on

it will display another screen like below give the report group "Z020" which you create in asap for selecting the report type to assign the interface.

Click on

It will display types of report transaction.

You Can see above screen then click on TR Transaction.

then assign or interface the transaction code : "KSB1"

It will display which report you assign on right  side  then enter and save.

You can see the above screen is assign then selection, then chick the report “XXXXXX” select the report click on respective layout then execute.

Click on line item of above it will call up " ksb1" transcation code detail line item wise report.

For creation of variable From standard table 

SAP Easy Access ~Accounting ~ Controlling ~ Cost Center Accounting ~ Information System ~ Tools ~ Report Painter ~ Report Writer ~ Standard Layout ~ GR11 - Create

Give Variable name : XXXX

Table : GLFUNCT

Field name : R BUKRS

Variable type:

Put the radio button as "Value"

Copy from : " 0FRBUKR" .

then press enter.

if you want to put any default value you can mention : "XXXX" .

R bukrs which is related to Company code here we make default value is Ex:- “3961” same thing it will show on report default value as “3961”

Before that you have to change the “rbukrs” in genral data selection in grr2 t code .

Check and save.

Then post some values in FB50 with cost center assignment it will be update on respective cost center wise.

Then use your Z transaction cost center report code then check.

"                                    "

Hope Asap will be help full

Thanks and Enjoy SAP

Introduction

The Material Ledger is the responsible to collect all material movements and valuate the inventory in the actual cost. This definition makes the Material Ledger a Sub-Ledger of SAP Finance Accounting.

This document will provide a definition of the Main Material Ledger Transaction Keys defined in OBYC (Material Management Postings).

Transaction Keys

BSX - Inventory posting

The BSX is the most important transaction keys and it appears in all Material Movement Type definition (OMJJ) defining the Stock Balance Sheet account.

All materials movements will request this transaction key.

PRD - Price Differences

The PRD transaction key is used for materials that are valuated at Standard Price (Price Control S) also be used for materials that are valuated at Moving average price (Price Control V) for Goods Movements and Invoices with a price that differs from the standard price.

The PRD Transaction Key is spitted in 3 business process(defined as general modification in OBYC):

- PRA: Price differences caused by purchasing process. PO and Invoices prices when different from the Standard Price.

- PRF: Price differences caused by variances in the manufacturing orders posted during the settlement

- PRU: Price differences caused by goods issues (when an external amount is entered making some difference with the standard cost)

If the general modification is left blank, the same account will be used for all process above.

LKW - Accruals and Deferrals Accounts

If you prefer to not reevaluate the original inventory account (BSX) to actual costs, then the material ledger allows you to post the variances to a separete account defined in this transaction key.

LKW is the offset for PRY, PRV, KDM and KDV.

PRY - Price differences for material ledger

The system uses this transaction key during the material ledger closing entry, as well as, the roll-up of single-level price difference to multi-levels.

During the material ledger closing:

Debit / Credit  -  LKW (if active)// BSX For materials which remain in the stock

Credit / Debit  -  PRY

PRV - Price Differences from Lower Levels

This transaction key is used to account the material which is consumed by a upper level in a production process

Debit / Credit  -  PRV

Credit / Debit  -  PRY

KDV - Exchange Rate Differences from Lower Levels

The KDV transaction key works for the exchange rate in the same way as the PRV transaction key but accounting only the ExRate differences.

Debit / Credit  -  KDV

Credit / Debit  -  PRY

Note that the differences from Lower Levels are divided in Price Differences (PRV) and ExRate Differences (KDV)both accounting having the offsetting account in PRY.

UMB - Revenue / Expense from Revaluation

This transaction key is used when the material price is changed from some revaluation such as CKMLCP Post Closing, MR22, CLCLMCCC, etc.

Actually, the account set here will be used as the offsetting of LKW (if active) or BSX.

COC - Revaluation of Other Consumption

The COC Transaction Key is required for the Revaluation of Consumption in actual cost process.

Find below some important OSS Notes to explain some specific SAP posting rules involved these transaction keys:

128          - Exchange rate differences between GR/invoice

116250    - MR08/MR8M:Cancellation+exchange rate diffrnces(KDM)

46564      - Cancelling/reversing an invoice/credit memo: Posting logic

331910    - MR1M, MIRO: Postings in foreign currency/local currency

This function describes the Costing Key assignment with Product for those Materials which have “do not cost” indicator in Material Master i.e. for which costing run is not required.

Access the Transaction code using one of the following options:

Enter the following details

1. 1.    Point of Valuation
2. 2.    Record Type
3. 3.    Material
4. 4.    Valid to

Keeping the “C.key 1” field empty, we set priority in the system that it should consider blank costing key for these defined material and for rest all the material it will consider the costing key defined in transaction KE4J (Assign costing key to material types) as below,

So, it gives priority to blank entries mentained in T.code KE4H against individual Materials and if system will not find respective material in KE4H then it will consider the costing key maintained in T.code KE4J against Material Types and will ask for Costing configuration.