SAP CO Understanding Results Analysis for WIP
Short Description
SAP CO Understanding Results Analysis for WIP...
Description
Understanding Results Analysis for WIP
Skip to end of metadata Page restrictions apply Added by Sridhar Vasudevan, last edited by Brendan O'Brien on Apr 21, 2010 (view change) show comment Go to start of metadata
Understanding Results Analysis Key for Calculating WIP
Introduction and Configuration Guide Work in process (WIP) inventory forms a part of the working capital or current assets of a firm appearing in their balance sheet. Work in process or progress are partially completed goods, parts, or subassemblies that are no longer part of the raw materials inventory and not yet part of the finished products inventory. Fundamental Principle of International Accounting Standard 2 states that Inventories are required to be stated at the lower of cost and net realisable value (NRV). The guidance on measurement of cost of inventories is that, cost should include all: a)
costs of purchase (including taxes, transport, and handling) net of trade discounts received
b)
costs of conversion (including fixed and variable manufacturing overheads) and
c)
other costs incurred in bringing the inventories to their present location and condition
With SAP, the raw materials gets transferred to finished goods via production orders or process order. In this process, typically, the production order is created to which raw materials are issued, all activities performed in the process are charged along with any overheads that is apporopriate the production order. Production is ongoing, and it is quite natural that at month end, we end up with some open production orders. SAP in its product costing functionality, provides the feature to calculate the value of WIP. This will be derived based on the careful definition of Line IDs in line with the cost components. The WIP shall be the total debits cost in the order as reduced by the credits for goods receipt.
Key elements of WIP Results Analysis Configuration.
Step 1
Define Results Analysis Key OKG1.
Here you just give a name, four letter key with its description.
Step 2
Create cost elements of type 31 the following minimum
1. a. i. 1.
Valuated Actual cost, say for eg. 990001.
2.
Calculated Costs, say 990002.
3.
WIP account 990003
4.
WIP Reserve 990004
5.
WIP Reserve 990005
Step 3
Define RA version, OKG9, Enable Transfer to Financial Accounting (checkbox)
Under extended control, you may enable checkboxes relating to
Generate line items
Assignment/RAkey
Update / RAkeyEnter the cutoff period for actual RA/WIP, the effective date before which any WIP data if existed, will not be altered.
Step 4
In OKGC, define the valuation method for WIP.
Here, you specify that WIP calculation mode is one when the order has the staus REL. The calculated WIP shall be cancelled when the order status changes to DLV or TECO. You maintain this data for CO area, RA version and RA key combination.
Step 5 SPRO>Controlling>Product Cost Controlling>Cost Object Controlling>Product cost by order>Period End Closing>Work in process>Define Line IDs. The line IDs are similar to cost component, that you create during cost estimates like a) 010 for Material b) 020 for Labor and c) 030 for Overhead to say the least. Besides these, create one more line ID say 999 for the Settled Cost, which appear as credit when you make a goods receipt. Create additional WIP type 31 cost elements and their corresponding Reserve account for the above#### WIP Material 990006 1. a. i. 1.
WIP Material Reserve 990007
2.
WIP Labor 990008
3.
WIP Labor Reserve 990009
4.
WIP Overhead 990010
5.
WIP Overhead Reserve 990011
Step 6 Now you assign the source cost elements OKGB, that are expected in the production order to various line ID as created above. You maintain this data for CO area, RA version and RA key combination. You use masking when you mention which cost element to be assigned to various IDs. You can also direct various cost element, if it comes with a combination of particular cost center and activity type to a particular Line ID. If you need to keep it simple, just enter +++++++ for cost centers, activity types and Business processes. Cost elements can be masked as follows; for eg. All cost primray cost elements for materials, if they start from 210001 to 219999, the you can mask them like 00021+++++. Give the line ID in the column Required to Capitailze.
Step 7 Define the update. OKGA You maintain this data for CO area, RA version and RA key combination. Here you specify which line IDs are to be grouped under which cost elements and their reserve account. You connect the cost elements created in step 5 to the line IDs. The category for the line IDs for material, labor and overhead shall be K, that stand for cost. The line ID 999 settled cost shall be maintained as category A, (settled cost). When you assign A, you won't have to maintain any cost elements for WIP and reserve creation.
Step 8
Define posting rules for WIP calculation OKG8
You do this for Controlling area, company code, RA version. Maintain this for RA category WIPR (WIP cost, Required to be capitalized) and RUCR (Reserve for unrealized cost). You maintain the P& L account (changes to stock) and the balance sheet (WIP)account.These G/L accounts are posted in Financial Accounting.
Step 9 Ensure number range assignment for the WIP transactions under appropriate head OKG6: KABG Automat. WIP/results analysis KABM Manual WIP/results analysis KSWP Prim. Target Cost Calc. (WIP) KSWS Sec. Target Cost Calc. (WIP)
Period end WIP calculation Process The process of running WIP is the t-code KKAX for individual order processing and KKAO for collective order processing. The system debits the WIP account and credits Inventory Change account. This entire WIP is reversed and a new entry is passed the following month. When the order is fully delivered no additional WIP entries are passed.
Note: The RA Key shall be entered in the production order, under the control tab. This can be defaulted through order type
Period end closing-- product costing: https://www.sdn.sap.com/irj/sdn/thread?messageID=1969478&
When Do You Use Product Cost by Order? 1. General Product Cost by Order enables you to analyze costs at production lot level. You can use it for make-to-stock production and sales order-related production. In sales order-related production, you can use Product Cost by Order for sales order-related mass production and as a supplement to Product Cost by Sales Order. In Product Cost by Sales Order, you use manufacturing orders (production orders or process orders) as cost objects. The costs that are updated on the manufacturing order are analyzed by lot and then settled. This means that variances of the cost analysis are only determined once the whole quantity that was planned for production has been delivered to the warehouse. You can do the following with Product Cost by Sales Order:
Determine and analyze plan, target and actual costs for production orders and process orders
Update or determine the inventory of unfinished products (work in process) and finished products
Determine and analyze variances
Transfer work in process and production variances to Financial Accounting (FI)
Transfer production variances to Profitability Analysis (CO-PA)
Transfer work in process and production variances to Profit Center Accounting (EC-PCA)
Transfer production variances to actual costing / Material Ledger (CO-PC-ACT)
2. The Different Contexts
Settlement type In the plant settings for the order type, you need to select settlement type PP1. This means that all production orders for this order type and this plant have the settlement rule with the FUL settlement type. In the order, the settlement type determines
in which of the following scenarios the production order is processed: Product Cost by Order (FUL) or in Product Cost by Period (PER).
Status control The status of the production order is very important in this scenario. The delivered (DEL) or technically completed (TECO) status control the WIP determination (creation or breakdown), the variance determination and the order settlement
Work in process (WIP) This is calculated at actual costs. WIP is only created for orders that have been released (REL). If the order has been technically completed (TECO) or delivered (DEL), then WIP is not created, but is broken down if it exists. However, WIP is only posted to FI when the order is settled. WIP cannot be calculated at target costs. It is only possible to calculate WIP in Product Cost by Period.
Variance determination Variances can only be determined once the order has been delivered (DEL) or technically completed (TECO), as the quantity actually delivered is fixed. This quantity determines the target costs of the production order and thus the variances per piece. This means that WIP and variances cannot be calculated at the same time. WIP is only calculated for released orders (REL) and variances for orders that have been technically completed (TECO) or delivered (DEL) If you are using Product Cost by Sales Order with the unvaluated sales order stock, you cannot reliably determine any variances for the assigned production orders and process orders. Therefore, in this case, the system does not support the variance determination, and you need to use the valuated sales order stock instead.
Order settlement The status of a production order in this scenario determines whether that production order is settled and thus credited or not. The actual costs of the production order are only settled if the order has been technically completed (TECO) or delivered (DEL). For orders that have been released (REL), settlement only posts the WIP to FI (if any WIP was determined).
Lot-size-independent costs These are determined and calculated once (only) in this scenario. In Product Costing by Period it is not possible to allocate these costs.
3. When Should You Use Product Cost by Order?
For individual or lot-related production. It is typically used for order-related production or for batch-related process manufacturing. Production is based on orders for which production and the cost analysis of a certain lot size are the priority.
For test production/start-up production (for planned repetitive manufacturing) for the exact determination of planning data (for example, variance analysis)
When you want to calculate WIP at actual costs
When you want to allocate your lot-size-independent costs
When you want to schedule your orders accurately.
4. When Should You Not Use Product Cost by Order?
For repetitive manufacturing (stable and continuous production), since the production of one material is the main priority over a long period of time
When you want to calculate WIP at target costs
When you want to calculate WIP (at target costs) and variances at the same time.
5. Period-End Closing Sequence for production orders during period-end closing: 1. Process cost allocation 2. Revaluation at actual prices 3. Overhead calculation 4. WIP determination 5. Variance determination 6. Order settlement.
Product Cost Collector and Repetitive Manufacturing/ Product Cost by Period General You use repetitive manufacturing in the R/3 System if you are producing a material over a longer period of time in larger quantities. Unlike production using production orders or process orders, there is no predefined lot size in repetitive manufacturing. Repetitive manufacturing is continually analyzed on a periodic basis. Processing is supported by run schedule headers up to Release 4.5B. These are normally linked to Product Cost Collectors. From Release 4.6A, backflushing is done via the production version for the product cost collector. Since there is no defined lot size in repetitive manufacturing, there are also no plan costs. The preliminary costing of the product cost collector uses the costing lot size from the production process. This is only an operand and does not correspond to the quantity actually produced or planned.
As repetitive manufacturing is analyzed on a period basis, work in process (WIP) and scrap are always valuated at target costs. WIP and variances can always be calculated at the same time, without the order status of the product cost collector (unlike production orders in full settlement). The following scenarios are not possible in repetitive manufacturing: - Manufacturing of co-products - Collective orders - Rework - Order splitting - Reporting points in alternative or parallel plan sequences. This document makes extensive use of the term "product cost collector". This term is correct from Release 4.5A onwards. It is also used (regardless of the release) when talking about cost collectors. "Production cost collector" is the term that was used before Release 4.0B, and is only used if the context relates solely to a release before 4.5A.
Prerequisites for Repetitive Manufacturing Material for Repetitive Manufacturing To produce a material in repetitive manufacturing, you need to meet the following requirements:
You need to switch on the indicator for repetitive manufacturing in the MRP 4 view (caution: If you want to use standard cost estimate for back flushing of production activity in repetitive manufacturing, then the switch must be set before the standard cost is estimated. If this is not done, then the error message RM175 "Existing standard cost estimate cannot be used" is displayed during backflushing.
You need to enter a repetitive manufacturing profile in the MRP 4 view. You need to create at least one production version for the material (MRP 4 view, costing view, from Release 4.6 also transaction C223). You need to set the indicator for the planned repetitive manufacturing of production versions.
Production Version In the production version, the quantity structure (BOM, routing) is entered that is used in repetitive manufacturing. You can enter three different routings in the production version for the following:
Detailed scheduling
Rate-based planning
Rough-cut capacity planning. If a routing is entered under detailed scheduling, then the system uses this for repetitive manufacturing. If it is not entered under detailed scheduling, the system uses the routing (if entered) from the rate-based planning. Routings entered under rough-cut capacity planning are not used for repetitive manufacturing.
Run Schedule Header Caution: From Release 4.6A, run schedule headers are no longer available. It is now sufficient to have an allowed production version for repetitive manufacturing, and to create a product cost collector (KKF6N, KKF6M). Up to Release 4.5B, you need to work with run schedule headers. These cannot be compared to other "orders" (such as production orders, process orders, product cost collectors or internal orders), as they are purely logistical objects and do not have their own CO object. Therefore, you always need to link them to a CO object. This is normally a product(ion) cost collector (in rare exceptions: order type SA: run schedule header with production order). You can use the following transactions for maintaining run schedule headers: - MF01 Create Run Schedule Header - MF02 Change Run Schedule Header - MF03 Display Run Schedule Header - MF04 Create Run Schedule Headers: Selection Screen - MF21 Run Schedule Headers (overview) When you create a run schedule header, a product cost collector is created at the same time (PKSA, until Release 4.0B only), according to the run schedule header (see Repetitive Manufacturing Profile). Otherwise, you need to create a product(ion) cost collector manually first (PKMN). Run schedule headers are only saved in the SAFK table (not in AUFK, AFKO, AFPO). The order number (AUFNR) is used as the only key. The quantity structure data is transferred from the production version when the run schedule header is created. The corresponding product cost collector is kept in the run schedule header. For run schedule headers that have the order type PKSA, there is a 1:1 connection to the production cost collector. In this case, the order number of the run schedule header is recorded in the master data of the production cost collector. A schedule header is not entered in the master data of the product cost collector, if it was created manually using the KKF6, KKF6N or KKF6M transactions.
Product Cost Collectors Product cost collectors are special orders from order category five. Product cost collectors can be used for collecting costs in production for the following production types: - Repetitive manufacturing with the following: o Make-to-stock production (from Release 3.0A) o Make-to-order production with valuated sales order or project stock (from Release 4.0A) - KANBAN (from Release 3.0A) - Production orders (from Release 4.5A) - Process manufacturing (from Release 4.5A) The product cost collector always has a periodic settlement rule to Material. To create the product cost collector, you can use the transaction for editing the product cost collector (KKF6N from Release 4.6A, previously transaction KKF6) and "Create
Multiple Product Cost Collectors for Production Versions" (KKF6M from Release 4.5B). It is only possible to create multiple product cost collectors in repetitive manufacturing. Product cost collectors are created for all selected production versions for which the "Repetitive manufacturing allowed" flag has been set. Up to Release 4.0B, it was possible to created product cost collectors in the background while creating a run schedule header (MF01) (order type PKSA). During creation, a product cost collector is automatically released. From Release 4.5A, product cost collectors are always created with reference to a production process from the quantity structure tool. A production process is created for a material and describes the way in which that material is produced (in other words, which quantity structure is used). The way in which a production process is formed, depends on the controlling level of the material (up to 4.5B: naming rule). The following controlling levels can be used for product cost collectors: - Production version (recommended): The production version is noted during the production process. The quantity structure (bill of material/routing), is taken from the production version. The production process is determined by the following characteristics: material, production plant and the production version. One production process can be created for each production version. - Bill of material (BOM )/routing: The quantity structure is stored directly in the production process. The production process is determined by the following characteristics: material, production plant, planning plant, bill of material and routing. It is possible to create a production process for each combination of BOM and routing. The "BOM/routing" controlling level is not recommended for use with repetitive manufacturing, since you always have to work with production versions in repetitive manufacturing. - Production plant/planning plant: No quantity structure is stored in the production process. The production process is only determined by the following characteristics: material, production plant and planning plant. It is not possible to create a preliminary costing for the product cost collector. For this reason, the "production plant/planning plant" controlling level is not recommended. The exact controlling level is specified on the material level, meaning that a material can only be assigned to a controlling level, and all production processes are created for this controlling level. If you create a product cost collector for a material that has not yet been assigned to a controlling level, then the required controlling level is initially queried (when creating multiple product cost collectors using KKF6M, the "production version" controlling level is always used). Moreover, the product cost collector for the production process is created in the background. You can also create product cost collectors for existing production processes. However, only one valid product cost collector may ever exist for a production process (this means without a deletion flag). Production processes can be processed using the transaction for editing production processes (CKML_FPR1N, until Release 4.5B: CKML_FPR1). The controlling level can be changed from Release 4.6A, using the transaction for editing controlling levels (CKMLMV_CA). To do this, all existing product cost collectors assigned to a production process of the material must be deleted. In Release 4.5A/B, it is not possible to change the controlling level. The number of the production process is noted in the AUFK-PROCNR field in the product cost collector. On the interface, the production process is represented by an appropriate short text rather than the process number. This short text is automatically generated by the system, but can also be defined by the user. To select a product cost collector in the periodend closing transactions (individual processing) and in reporting, you always need to specify the material, (production) plant and production process (short text). A costing lot size can be stored in the production process. This lot size is used for the preliminary costing of the product cost collector. If a lot size has not been stored in the production process, the costing lot size from the material master is used. Production processes are also used to determine the assignment in a cost object hierarchy.
Product cost collectors have an unlimited runtime (the runtime ends when you set the deletion flag). The following parameters are transferred as default values to the master data of the product cost collector when you create product cost collectors: - The profit center is taken from the material master - The business area is taken from the material master using the division. From Release 4.6C, the business area is always transferred to the master data, even if no business area financial statement has been activated. - The plan costing variant is determined from the plant parameters for the order type (transaction OKZ3). It is used for the preliminary costing of the product cost collector. - The actual costing variant is determined from the plant parameters for the order type (transaction OKZ3). It is used for the actual costing (valuation of actual material withdrawn and actual activities). - The costing sheet is determined from the plan costing (if this exists, otherwise the actual costing variant is used). Until 4.6B, the costing sheet was determined from the actual costing variant. The change was made to adapt the procedure to that of production orders. - The overhead key is determined from the overhead cost group for the material. - The results analysis key is determined from the plant parameters of the order type (transaction OKZ3) for the product cost collector. - The variance key is transferred from the costing view of the material master. - The functional area is transferred from the order type (KOT2_PKOSA). Features: Actual debits (activities and goods issue) and actual credit (good receipt) can be posted by means of backflushing (backflushing for repetitive manufacturing or the assigned production or process order). It is not possible to post any material movements to the cost collector except by using backflushing. Activities can also be posted to the product cost collector by means of an activity allocation (for example, from a cost center). For product cost collectors, you can use overhead application and a template allocation. Product cost collectors do not have a plan quantity, and therefore, no plan costs either. However, you can create a preliminary costing for the product cost collector (up to 4.0B: costing by production version). The costing lot size that is used must not be regarded as the plan lot size of the product cost collector. The preliminary costing for the product cost collector uses the plan costing variant that is stored in the master data of the product cost collector. The system always uses the quantity structure stored in the corresponding production process (until 4.0B: from the quantity structure in the production version). The preliminary costing is usually only carried out with one level (from 4.5A, it can only be done using one level). The preliminary costing has the following functions: - Valuation basis for target version one and possibly three - From Release 4.0A, valuation basis for WIP and scrap (according to valuation variant WIP and scrap. It is recommended that you use the preliminary costing). - Determination of the activity quantities that are to be posted inversely (according to the Repetitive Manufacturing Profile) - From Release 4.0A, adjustment of the reporting point structure for routing changes
You can only determine WIP on the product cost collector if reporting points were defined or production or process orders were used for the product cost collector that have transaction backflushing. In the following scenarios, it is not possible to define reporting points, therefore, it is also not possible to calculate WIP: - Repetitive manufacturing with valuated sales order stock, since the quantity of reporting points needed for determining WIP cannot be recorded by sales order. - KANBAN production. Variances can be calculated in target versions 0 and 1, and in repetitive manufacturing, also in version 3. Target version 2 is not possible. Since Release 4.5A, you can use the product cost collector not only in repetitive manufacturing, but also in Product Cost by Period on the product level in relation to manufacturing orders (= production and process orders). In this scenario, the manufacturing orders are purely logistical objects that are, for example, used for capacity planning and scheduling. Backflush entries are still entered in the manufacturing orders, but the debits and credits are posted directly to the corresponding product cost collectors by the system. For the purposes of CO (period-end closing and reporting), only the product cost collector is analyzed. The following manufacturing orders cannot be assigned to a product cost collector: - Manufacturing orders with manufacture of co-products - Manufacturing orders that were created for a sales order - Manufacturing orders in collective orders To assign a manufacturing order to a product cost collector, you need to create a suitable product cost collector first. When you create the manufacturing order you must use a suitable order type (transaction OPL8, define order type-dependent parameters). In the order type, the "cost collector" flag must be set. In addition, the order type must contain "PP2" (periodic) as its default rule. Note: Manufacturing orders are not settled to product cost collectors as they do not carry any costs. This means that the default rule in the order type is no longer used for anything else. For backflushing by transaction of the manufacturing orders to product cost collectors, you can confirm each transaction that can be confirmed on a manufacturing order without product cost collectors. The transactions to be confirmed are not restricted to milestones. When product cost collectors are created, a settlement rule with 100% to material is created. From Release 4.5A, there is also a new rule for this with method 5 "delivery value for product cost collector". This distribution rule cannot be subsequently changed. During settlement, the "delivery value for product cost collector" method means that the distribution of the costs to be settled to the various valuation segments is taken into account (MBEW segments for materials with separate valuation, EBEW segments for valuated sales order stock). A distribution rule is dynamically determined for this during settlement, for each valuation segment. It is determined from the delivery values posted in the period. If there is no delivery in the period to be settled, then settlement is made to the price difference account PRP. The assignment of the goods receipt documents to the valuation segments is made using the procurement alternatives entered in the goods receipt documents (see quantity structure tool). You can use these to directly determine the material, valuation area, and if appropriate, the valuation type and the sales order position. This information uniquely determines the valuation segment. Up until Release 4.0B, settlement was only made to material, without taking into account the valuation segments. For sales order stock, it was possible in Release 4.0A/B to create your own product cost collector (set "Sales order stock" flag), although here, settlement was only made to the price difference account PRD. This type of product cost collector does not have a settlement rule. In 4.0A/B, a material cannot have any other product cost collect if a product cost collector exists for the sales order stock.
For more information on settlement of product cost collectors, see note no. 388457. It is also possible to process product cost collectors with the KKF2 transaction (CO production order). However, it is strongly recommended that you do not do so. The changes made to the master data or the settlement rule of a product cost collector using the KKF2 transaction lead to data inconsistencies. It is planned to prevent maintenance of the product cost collector with this transaction in future. When upgrading from a release older than 4.5A to 4.5A or higher, the existing product cost collectors are converted using the XPRA program RK_PKOSA_MLMV_X1. This means that production processes are created for product cost collectors, and they receive the new settlement rule with method 5. During conversion, the controlling level "production version" is assigned to the corresponding material (exceptions: product cost collectors for KANBAN that do not have a version, and product cost collectors for sales order stock. The "production plant/planning plant" controlling level is used for this. From Release 4.5A, it is only possible to have one valid product cost collector for a production process. Previously it was possible to have more than one (if several manufacturing orders exist for a production version, but not overlapping). In this case, only one of the product cost collectors for the production version is converted. The product cost collector that is assigned to the run schedule header at the time of the upgrade is the one that is converted. Any existing future run schedule headers are assigned to the converted product cost collector. If there is no run schedule header at the time of the upgrade, then the one before or after it is searched for and the corresponding product cost collector is then converted. The existing product cost collectors for sales order stock do not get any (new) settlement rule (settlement to PRD only, even after the upgrade).
Quantity Structure Tool Since Release 4.5A, product cost collectors are always linked with a production process. Production processes are objects from the quantity structure tool, which is a Material Ledger tool. The quantity structure tool contains procurement alternatives and production processes as its objects. Procurement alternatives specify the way in which a material is procured (for example, external procurement, in-house production or stock transfer). For product cost collectors, you can only have procurement alternatives from the "BF=Production" category (process category). Production processes are meta objects that enable a certain separation between Logistics and Accounting. They contain references to the logistical quantity structure terms such as bill of material/routing or production version. The way in which production processes and procurement alternatives are created (which logistical terms are used in them) is determined on the material level by the assigned controlling level (see: Product Cost Collectors). In a simple case (make-to-stock production without manufacturing of co-products) there is a 1:1 relationship between procurement alternatives and production process. However, m:n relationships between procurement alternatives and production processes are generally possible. If a material is produced using a certain production version for the valuated sales order stock then there is, for example, a procurement alternative for each sales order stock (EBEW segment), but only a total of one production process. The same applies to a material that has a separate material valuation. In this case, there is a procurement alternative for each MBEW segment. The following order categories are linked to production processes: - Product cost collectors are always linked to production processes - Production and process orders are linked to production processes if: o Material Ledger is activated
o They are linked to a product cost collector (then they are linked to the same production process as the product cost collector) o They are assigned to a cost object hierarchy whose objects are individually assigned based on production processes. Procurement alternatives are also needed to specify the mixing ration of mixed costings. There is a field for this in the master data of the procurement alternatives or production processes called "costing lot size". This field is also used as the costing lot size for the preliminary costing of product cost collectors. Since it is used in two applications (preliminary costing and mixed costing), this field can only be set once in the master data maintenance of the product cost collector, after which it cannot be changed. You can only make a subsequent change to the costing lot size in the maintenance of the production process (transaction CK91N).
Repetitive Manufacturing Profile The repetitive manufacturing profile controls repetitive manufacturing. It is entered in a material that is to be manufactured using this process (MRP 4 view, up to Release 3.X, MRP 2 view). The repetitive manufacturing profile is read during backflushing from the material master. Its settings can be partly overridden in the backflushing transaction. Caution: Changes to the repetitive manufacturing profile in the material master or in Customizing have a direct effect on the operating productive system. You define repetitive manufacturing profiles in Customizing (transaction OSP2). The following settings are important: - Inverse goods issue for GR posting: If this is activated, goods issues are inversely posted during backflushing of repetitive manufacturing, otherwise, the goods issues must be manually posted (it is recommended that you activate this indicator). Until Release 4.5B, the indicator was called 'GR and GI' with the following values: 1/blank = GR and GI, 2 = only GR. - Reporting point backflush: If this is activated, the backflushing is entered on the reporting point level. Otherwise it is only possible to enter goods receipt backflushing. There is a choice between "required" and "optional". If "required" is set, the reporting points must be posted. "Optional" (rarely used) is used if you only post goods issues during the period, and want to post the physically existing WIP at the end of the period to the system, using reporting point backflushes. Reporting point backflushes are a prerequisite for calculating WIP in repetitive manufacturing. Until Release 4.5B, the indicator was called "with reporting point", with the following values: blank = no reporting points, 1 = required reporting points, 2 = optional reporting points. It is recommended that you use required reporting points. - Automatic GR posting for actual data entry at the last reporting point: If this is activated, then the system posts a goods receipt during backflushing at the last reporting point in the routing using the backflushing quantity (except for scrap). Otherwise, the goods receipt must be entered manually. If this indicator is set, then there are no WIP quantities at the last reporting point. Until Release 4.5B, the indicator was called "automatic GR" with the following values: blank = no automatic GR, 1 = automatic GR. - Post activities: If this indicator is activated, then the production activities are inversely posted during backflushing. The activity quantities to be posted are determined using a costing. You can determine activities using the standard cost estimate for material or the preliminary costing for the product cost collector (until Release 4.0: Costing by production version). It is recommended that you use the preliminary costing for this. This indicator only controls the calculation of the activity quantities. The actual costs that are to be posted for the production activities are determined using these quantities, based on the valuation variant of the actual costing variant in the product cost collector. Until Release 4.5B, the indicators were called "Activities" with the following values: 1 = no activity posting, 2 = activity posting, and "Costing" with the following values: blank = standard cost estimate, 1 = preliminary costing. - Reduce plan orders: Determines how existing plan orders are reduced in a goods receipt posting for repetitive manufacturing. The following values are possible:
o 0: no reduction of plan orders o 1: reduction of plan orders or run schedule quantities for the material, that are assigned to the specified production version. o 2: as in 1, but also reduction (if required) of the plan orders and run schedule quantities for the material, that are not assigned to a production version. o 3: as in 2, but also the reduction (if required) of the plan orders and run schedule quantities for the material, that are assigned to production versions other than the one specified. - Reduction period (in days): Reduction of the plan orders and run schedule quantities whose date falls before the posting date plus reduction period. - Plan orders: Determines how the reduced plan orders are created again if a goods receipt is reversed. Values: o Blank: no plan orders are created o 1: plan orders are created for the current date. The same number of plan orders are created as the quantity that was reversed. o 2: plan orders are created by asynchronous MRP during the reversal. - Movement types: The different movement types for different goods movements (GI, GR, scrap, reversal etc.) are stored in the repetitive manufacturing profile. You can change these during backflushing. Up until Release 4.0B Customizing has two transactions for repetitive manufacturing profiles: "Define repetitive manufacturing profiles" (OSP2) and 'Specify control data for repetitive manufacturing profiles" (OSP3). In the OSP2 transaction, you assign two order types to the repetitive manufacturing roles: - The run schedule header type (not to be confused with the order type for production orders or product cost collectors); This has three possible values: o PKSA: when you create a run schedule header, a new production cost collector is always created in the background. There is a 1:1 relationship between cost collector and run schedule header. This order type is not recommended up to Release 4.0B. From Release 4.5A, this order type is no longer available. o PKMN: before you create a run schedule header you need to manually create a production cost collector. You can link more than one run schedule header with a cost collector. o SA: Run schedule headers are not linked to production cost collectors but production orders. This scenario is very rare and is not recommended. - The order type for the production cost collector; this is automatically used when a cost collector is created, and is normally the RM01 type. It contains default values for the plan and actual costing variant, and the results analysis key (always plantdependent), as well as for the settlement profile, and (from 4.6C) the functional area. You can also enter the residence times for archiving and the number range for the order number. From Release 4.5A, only the OSP2 transaction is available. From Release 4.5A, order type PKSA is no longer available. From Release 4.6A, the order type for the run schedule header is obsolete since the run schedule header is no longer available. From Release 4.5A, the order type for the product cost collector is specified when the cost collector is created, and no longer determined from the repetitive manufacturing profile.
Definition of the Reporting Points In the repetitive manufacturing profile, if reporting point processing is activated, then you need to define operations in the routing specified by the production version for repetitive manufacturing. You can (optional reporting points) or must (required reporting points) make your backflush to these. Reporting point backflushes are used for determining WIP. In addition, assembly scrap, and component and activity postings can also be entered for the reporting point. Reporting point backflushes are only possible for make-to-stock production. Reporting points are defined in the routing in the transaction overview. The operations that are to be used as reporting points must have a control key with milestone processing (flag: Backflushing with control key =1). Not all operations have to be defined as reporting points. Reporting points are always defined in the plan sequence 000000. The following operations cannot be defined as reporting points: - Operations in parallel sequences - Operations in alternative sequences - Sub-operations
Backflushing in Repetitive Manufacturing From Release 4.6A, you can use the MFBF transaction for backflushing in repetitive manufacturing. This replaces the transactions that were valid until Release 4.5B: - MF40 (goods receipt backflush for make-to-stock production) - MF44 (goods receipt backflush for sales orders) - MF4S (goods receipt for production lot) - account assignment to WBS element, no longer taken into account here - MF43 (reporting point backflush) - only for make-to-stock production - MF4U (goods issue backflush) - MF4A (component scrap) - in CO terms, this leads to extra use of the component, no difference to MF4U - MF48 (backflushing activities) - MF4R (reset reporting points) posts existing WIP quantities as scrap to set the WIP quantities to zero. This transaction can be used if a product cost collector is to be deleted. WIP needs to be at zero for deletion. Note that if you reset reporting points, no costs are posted to the product cost collector. You can only backflush in repetitive manufacturing during MM periods (current and last). If appropriate, during backflushing in repetitive manufacturing, the goods issues and activities are inversely posted according to the settings in the repetitive manufacturing profile. During reporting point backflushing, goods issues are posted for the BOM components that are assigned to the confirmed reporting point, as well as all components that are assigned to the operations that are not reporting points and are between the confirmed reporting point and the previous one. Components that are not assigned to a transaction are posted when the first reporting point is confirmed. If transactions that are not reporting points come before the last reporting point transaction, then the assigned components are posted during goods receipt. The assigned activities are posted in the same way. Setup times are not inversely posted as lot-fixed-costs. This has its own function in the backflush transaction.
Example: Routing: | Operation | Milestone | Activity |
0005
ACT1
0010
X
ACT2
0015
ACT3
0020
X
ACT4
BOM:
Item
Component
Assigned to operation
0010
KOMP1
0005
0020
KOMP2
0010
0030
KOMP3
0015
0040
KOMP4
not assigned
Backflush to reporting point 0010: The following are posted: components KOMP1, KOMP2 and KOMP4 as well as activities ACT1 and ACT2.
Backflush to reporting point 0020: Component KOMP3 and activities ACT3 and ACT4 are posted. The components and activities are valuated according to the valuation variant that is stored in the actual costing variant in the corresponding product cost collector. If there are no reporting point postings (as per repetitive manufacturing profile), then all components and activities are posted during the goods receipt. During backflushing in repetitive manufacturing, you can change the components and activity quantities that are to be inversely posted, and enter more components or activities (posting with correction function). This creates input quantity and resource-usage variances. Work in process (WIP) If you enter backflushing with a reference to reporting points, then work in process (WIP) is created. The confirmed reporting point quantities are updated in the CPZP table (PZPP and PZPS tables before Release 4.0A). During WIP determination on the corresponding product cost collector, these WIP quantities are valuated using a costing (with the current standard cost estimate before Release 4.0A, after which according to the valuation variant for WIP and scrap) to calculate the WIP value. If a reporting point backflush is entered with a larger quantity than in the previous reporting point in the WIP, then the system issues a warning message. If you still continue with the posting, this causes a negative WIP quantity for the previous reporting point. Negative WIP quantities are ignored in WIP determination. The system does not create reserves for missing costs. Scrap Backflushing in repetitive manufacturing can also post assembly scrap with or without references to reporting points. For assembly scrap that refers to reporting points, the same components and activities are posted as they are for a corresponding yield backflush. If scrap is posted without a reference to reporting points, then all components and activities (similarly to goods receipt) are posted. The WIP quantities are reduced according to the scrap postings. It is also possible to make a posting with a correction for scrap. The posted scrap quantities are updated in the CPZP table (before Release 4.0A, table PZPP). During variance determination on the corresponding product cost collector, the posted scrap quantities are valuated (in the same way as the WIP quantities) and the difference of the determined scrap costs and the plan scrap can be displayed as scrap variances. The confirmed component scrap is not included in its own variance category in the variance determination, but flows into the input quantity variances. Reversal Reporting point backflushes can be reversed by document (transaction MF41 or MF12 - document log overview). This type of reversal is only possible for documents that are still in the open MM periods. If a reporting point is deleted, the documents that were posted to it cannot be reversed any longer. In addition to the document reversal, you can also post backflushing with a reversed movement type (function: reverse movement type). This means that goods receipts become goods issues and vice versa. This enables you to "reverse" any reporting point quantity without a document (for example, if the documents to be reversed are not in the MM periods, and thus make reversal impossible). Until Release 4.0B, this is only possible for goods movements. Activities must be posted manually using activity allocation (transaction KB21) from the product cost collector back to the corresponding cost centers. From Release 4.5A, activity is also included in backflushing with a reversed movement type.
Documents In backflushing in repetitive manufacturing, material documents (for goods receipt and issue) and reporting points (for reporting point posting) are created in addition to the accounting documents (FI and CO documents with activity documents). These documents are collected in a document log record and can be displayed using the MF12 transaction.
Flexible Reporting Points From Release 4.0A, flexible reporting points are available that allow a change to the reporting point structure in the routing during realtime. Possible changes are the deletion and insertion of reporting points and the change to the unit of entry for a reporting point. Existing WIP and scrap quantities are adjusted according to the new reporting point structure. The adjustment is made by preliminary costing of the appropriate product cost collector, or automatically during backflushing in repetitive manufacturing.
Release Upgrade Note the following scenarios and special features in each release or upgrade:
Release 3.0/3.1: The reporting point structure is read from the routing and stored when you create a run schedule header. Subsequent changes to the reporting point structure in the routing are not possible (workaround: close the current run schedule header, change the reporting point structure in the routing, create a new run schedule header with the new reporting point structure).
Release 4.0: Introduction of the flexible reporting points. Changes in the reporting point structure are now possible during realtime without a new run schedule header having to be created. The change is made in the system using a costing by production version (from 4.5A: preliminary costing for product cost collector). To valuate WIP and scrap, you can use different costings using the valuation variant for WIP and scrap. You can create product cost collectors for the valuated sales order stock (settlement to price difference account PRD only).
Release 4.5: Interim between production cost collector and product cost collector. The product cost collector is no longer assigned to the production version. Instead it is assigned to the production process (tool that belongs to the quantity structure tool) according to the naming rule assigned to the material (from 4.6: Controlling level). Only the PKMN order type is available, which means that all product cost collectors must be created manually. You can use the KKF6M transaction for multiple creation of the product cost collectors (equivalent of multiple creation of run schedule headers - MF04). The settlement of the product cost collectors to material now includes the distribution to the different valuation segments (MBEW for material with separate valuation, EBEW for sales order stock). There is a new settlement rule for this with a distribution rule that are dynamically determined. Individual objects are now assigned in the cost object hierarchy for the production process instead of the production version or run schedule header. The Costing by production version is now called the preliminary costing for the product cost collector.
Existing product cost collectors and cost object assignments are converted during the release upgrade using XPRAs RK_PKOSA_MLMV_X1 .
Release 4.6: The run schedule header is no longer available. Backflushing in repetitive manufacturing takes place directly via the production version, using the XPRA PPREM_XPRA_NO_RSH program. New interface for processing product cost collectors (KKF6N) instead of the KKF6, KKF7 and KKF8 transactions. Replacement of the production process number by the short text for all transactions in which you have to enter a product cost collector. Renaming of the naming rule to controlling level. The functional area is transferred as a default value from Customizing to the product cost collectors (4.6C).
MM Related config: OMS2 - material types - make sure that "costing relevant" is active (field T134-EKALR) Material is costed with quantity structure This indicator determines whether the material is costed using costing with or without a quantity structure. Use If you usually cost materials using costing with quantity structure, turn on this indicator. If you usually cost materials using costing without quantity structure, do not turn on this indicator. You can change the indicator in the material master record at a later time. Procedure If you always cost your materials (including raw materials) using costing with quantity structure, you should turn on this indicator. This improves performance, because the system does not search in vain for existing cost estimates without a quantity structure for every material when it explodes the BOM. Therefore, only turn on this indicator if you normally cost the materials using costing without quantity structure. Regardless of the setting, you can cost a single material with or without quantity structure. However, you should bear in mind that this
setting is always used in the costing run and in mixed costing (creating procurement alternatives). Dependencies For every cost estimate, the system searches for existing cost estimates that have the materials in their structure. If a released cost estimate exists, the system copies it. If this indicator is set, the material is costed using costing with a quantity structure. The system searches for any existing cost estimates with quantity structure for the individual materials; it ignores existing cost estimates without quantity structure. If the system does not find any valid costing data for the materials, it costs the material or accesses the price in the material master. See also: Transfer control If this indicator is not set, the planned costs for the material are calculated using the cost estimate without quantity structure. In this case, you use unit costing to create the quantity structure manually by entering costing items for materials and activity types, for example. The system now searches for any existing cost estimates without quantity structure. If a cost estimate without quantity structure exists for a material, the results of this cost estimate are included in a cost estimate with quantity structure. If there is no cost estimate without quantity structure, the cost estimate with quantity structure accesses the price in the material master record. The planned costs for this material then go into the cost estimate with quantity structure as raw material costs. This does not apply if the indicator Ignore prod cost est w/o qty structure is set in the costing variant.
OS20 - Indicator: item relevant to costing This indicator controls whether and, if so, to which extent BOM items are relevant to costing. For example, items that are relevant to costing are taken into account for pricing in product costing. In accordance with the usage key, you define for all items whether they o must be maintained in costing o can be maintained in costing (.) o cannot be maintained in costing
KO88 - Actual Settlement: Order
Configuration OPN2 - Create Valuation Variant for Manufacturing Orders (PP) OPL1 - Create Costing Variant for Manufacturing Orders (PP) OPL8 - Define Goods Received Valuation for Order Delivery
WIP and RA config OKG1 - RA Key OKG2 or OKG9 - RA Version OKGC - Valuation Method Order-Related (actual) OKGD - Valuation Method Order-Related (plan) SM31 view V_KKAX - Define Line IDs OKGB or OKG5 - Define Assignment (incoming charges by CE to Line ID's) OKG4 - Define Update (can be used to segregate WIP creation/accrual from usage) ???? - Define Posting Rules (Various Transactions) OKG6 - Number ranges for RA
Variances & Settlement OKVW - Define Default Variance Keys for Plants OKV6 - Define Target Cost Versions OKOA - Create Settlement Profile (w/o CO-PA)
Development Classes --------------------------------------------------------------------------------
Dev. cl.
Short text
--------------------------------------------------------------------------------
CK
R/3 Application development: PP Product Costing
CK_ECP
Easy Cost Planning
CKAL
Costing ALE functions
CKAPP
MiniApps for the Calculator
CKAZ
R/3 Application development:PP Costing displ.cost components
CKBA
Procurement alternatives and mixing ratios for mixed costing
CKBK
R/3 application development PP costing valuation
CKCO
R/3 Application development: PP Transfer to CO object
CKCORE
CKCY
Treatment of cycles in costing
CKDS
R/3 Application development: PP Product Costing Dialog Ctrl.
CKEK
Multilevel unit/simulation costing
CKEXECUTION
E@sy Execution
CKJ1
Customizing product cost accounting
CKJ2
Layer between application and Customizing (costing)
CKJ3
Archiving and reorganization in product cost accounting
CKJ4
Marking and release for product costing
CKJ5
Customizing: flexible error control
CKJ6
USER exits in product costing
CKJ8
BAPIs in Product Costing
CKKA
Interface for product costing customer order
CKKT
R/3 Application development: PP Costing driver program
CKMC
Customizing material ledger
CKML
Material ledger
CKMLCCS
Actual Cost Component Split
CKMLCUMREV
Cumulation and Revision
CKMLDUV
Distribution of Usage Variances
CKMLGRIR
Account Maintenance of the GR/IR Account
CKMLLA
Update of Activity Consumption in Quantity Structure
CKMLMV
Quantity structure tool
CKMLRUN
Costing Run in Material Ledger
CKMLSIM
Simulation
CKMP
R/3 Application dev.: PP Costing manual maintenance
CKMPC
Material Price Changes (ML)
CKR1
R/3 Application development: PP Costing Reporting 1
CKSA
R/3 application development COPC-PCP quantity structure tool
CKST
Quantity structure determination from product costing doc.
CKWB
Product Cost by Production Lot(Pre-planned SEIBAN)
CKWBREPORT
Cost Reports Production Lots
CKXX
R/3 Application development: PP Costing basic product
-------------------------------------------------------------------------------Hi, Steps to be followed for product costing Two aspects: 1. Calculating standard cost estimate 2. Order costing ==== 1. Create materials a. Five raw materials (Two for creation of semi finished, three for finished)- ROH b. One semi finished material-HALB
c. One finished material-FERT 2. Create secondary cost elements for defining activity types 3. Create secondary cost elements for defining credit elements in costing sheet 4. Create activity types (use category 1 & price calc as 3 - for now) 5. Define prices for combination of cost center and activity type in KP26 6. Define costing sheet 7. Define cost component 8. Define components of costing variant a. Date control b. Valuation variant c. Costing type 9. Define costing variant 10. Next, create standard cost estimate Use either CKUC( for multi unit costing) or KKPAN
( for material without quantity structure)
In case of csoting with quanity structure (means with BOM) we use CK11N (for individual material costing) & CK24 for update price in material master & CK40N for mass costing & update material price. if want to capture OVERHEAD then overhead group & OH key to be defined, OH group is defined in MATERIAL MASTER. while rates are maintained for OH key with validity dates. This OH rates are then captured in cost sheet and then roll up in material cost thru use of costing variant. 11. Next to update prices, use the below transaction CK24 for price update First, MARK Then, RELEASE Hope this helps.
View more...
Comments