VALUATION APPLICATION: TECHNICAL DESIGN DOCUMENT
Greek Localization R/3 4.70 – ERP 6.0
Material Valuation, Warehouse Book,
Analytical Ledger
Application Overview and Technical design Document
Please refer to Hellenization notes
1135997, 1138580, and 1148425
for latest developments.
1
Introduction
This document serves two purposes: the first is to provide an architectural overview of the material valuation
application as part of the Localization of SAP ERP (and R/3) for Greece; the second is to expose the main
technical details of the application and its components. The application has been developed by SAP with the
prime objective to fulfil the requirements of Greek Law regarding the following issues:
Periodic valuation of materials at pre-selected time intervals.
Printing of the (legal) Warehouse Book(s) with material values updated as a result of step 1 above.
Performing material-relevant postings in the Analytical Ledger using the values from step 1.
Printing of the (legal) Inventory Book at the end of the fiscal year.
SAP Hellas
Page 1 of 40
21/6/2012
VALUATION APPLICATION: TECHNICAL DESIGN DOCUMENT
2
Table of Contents
1
INTRODUCTION ............................................................................................................................................. 1
2
TABLE OF CONTENTS .................................................................................................................................. 2
3
KEY TERMS AND ACRONYMS .................................................................................................................... 4
3.1
MATERIAL VALUATION ................................................................................................................................ 4
3.2
WAREHOUSE BOOK ...................................................................................................................................... 4
3.3
ANALYTICAL LEDGER .................................................................................................................................. 4
3.4
MATERIAL LEDGER ...................................................................................................................................... 4
3.5
VALUATION EQUATION ................................................................................................................................. 4
3.6
TRANSACTION CATEGORY ............................................................................................................................ 5
3.7
DOCUMENT CATEGORY ................................................................................................................................ 5
3.8
WAREHOUSE BOOK LOGICAL COLUMN ......................................................................................................... 5
3.9
WAREHOUSE BOOK PHYSICAL COLUMN........................................................................................................ 6
3.10 VALUATION FREQUENCY .............................................................................................................................. 6
3.11 VALUATION HORIZON ................................................................................................................................... 6
3.12 VALUATION METHOD ................................................................................................................................... 7
3.13 VALUATION LEVEL ...................................................................................................................................... 7
3.14 VALUATION ERROR ...................................................................................................................................... 7
3.14.1 Rounding errors. .................................................................................................................................. 7
3.14.2 ‘True’ valuation errors. ........................................................................................................................ 8
3.15 CUSTOMIZING TABLES .................................................................................................................................. 8
3.16 DATA TABLES .............................................................................................................................................. 8
3.17 CONTROL TABLES ........................................................................................................................................ 8
3.18 REPOSTING .................................................................................................................................................. 8
3.19 DEVALUATION ............................................................................................................................................. 9
3.20 INVENTORY BOOK ........................................................................................................................................ 9
3.21 OFFLINE UPDATE ......................................................................................................................................... 9
3.22 ADJUSTMENTS TO CARRIED-FORWARD TOTALS .............................................................................................. 9
3.23 ROUNDING DIFFERENCES ............................................................................................................................ 11
4
COMPONENTS .............................................................................................................................................. 12
5
PROCESSES ................................................................................................................................................... 13
6
INTEGRATION ASPECTS ............................................................................................................................ 14
6.1
6.2
7
INPUT ........................................................................................................................................................ 14
OUTPUT ..................................................................................................................................................... 14
CUSTOMIZING ............................................................................................................................................. 15
7.1
7.2
7.3
7.4
7.5
7.6
7.7
7.8
7.9
7.10
7.11
7.12
7.13
7.14
7.15
7.16
SAP Hellas
GLOBAL SETTINGS (TABLE J_1GVL_WHB000) .......................................................................................... 15
WAREHOUSE BOOKS: DEFINITION (TABLE J_1GVL_WHB001) .................................................................... 15
WAREHOUSE BOOKS: TEXTS (TABLE J_1GVL_WHB01T) ........................................................................... 16
VALUATION METHODS (TABLE J_1GVL_WHB019)..................................................................................... 16
VALID PLANTS (TABLE J_1GVL_WHB002) ................................................................................................ 17
VALID MATERIALS (TABLE J_1GVL_WHB003).......................................................................................... 17
TRANSACTION CATEGORIES (TABLE J_1GVL_WHB 008) ............................................................................ 18
VALID MOVEMENTS AND DOCUMENT TYPES (TABLE J_1GVL_WHB005) .................................................... 19
VALID ACCOUNTS AND COST ELEMENTS (TABLE J_1GVL_WHB004)......................................................... 20
WAREHOUSE BOOKS LAYOUT (TABLE J_1GVL_WHB006) ......................................................................... 20
FUNCTION MODULES (TABLE J_1GVL_WHB007) ...................................................................................... 21
ANALYTICAL LEDGER POSTINGS (TABLE J_1GVL_WHB013) ...................................................................... 21
CO REPOSTING SETTINGS (TABLE J_1GVL_WHB014)................................................................................. 22
FI REPOSTING SETTINGS (TABLE J_1GVL_WHB015) .................................................................................. 22
ORDERS RELEVANT FOR WORK IN PROGRESS (TABLE J_1GVL_WHB017) ................................................... 22
CUSTOMER ENHANCEMENTS (TABLE J_1GVL_WHB020) ........................................................................... 22
Page 2 of 40
21/6/2012
VALUATION APPLICATION: TECHNICAL DESIGN DOCUMENT
8
CUSTOMER-SPECIFIC ENHANCEMENTS ............................................................................................... 23
8.1
DEFAULT FUNCTIONS/FORMS ...................................................................................................................... 23
8.2
PREDEFINED FORMS (DELIVERED EMPTY) .................................................................................................... 23
8.2.1
Valuation program (J_1GVL_VL) ...................................................................................................... 23
8.2.2
A/L postings program (J_1GVL_ALPOST_DI) ................................................................................... 24
9
LEGACY SYSTEM MIGRATION ................................................................................................................ 24
9.1
9.2
10
APPLICATION IS ACTIVATED TOGETHER WITH SAP R/3 GOING LIVE .............................................................. 24
APPLICATION IS ACTIVATED IN A LIVE R/3 SYSTEM ...................................................................................... 25
MONTHLY OPERATIONS ....................................................................................................................... 25
10.1
10.2
10.3
10.4
10.5
11
MATERIAL VALUATION (FOR CO REPOSTING) ............................................................................................. 25
MATERIAL VALUATION PROPER .................................................................................................................. 25
WAREHOUSE BOOK(S) ................................................................................................................................ 25
ANALYTICAL LEDGER POSTINGS ................................................................................................................. 25
RESETTING THE APPLICATION RUNS ............................................................................................................ 25
YEAR-END-CLOSING OPERATIONS..................................................................................................... 25
11.1
11.2
12
DEVALUATION AND MINIMUM PRICE SELECTION .......................................................................................... 25
INVENTORY BOOK AND CARRYING FORWARD TO NEXT FISCAL YEAR ............................................................ 25
REPORTING .............................................................................................................................................. 26
12.1 REPORTS EXECUTABLE PRIOR TO MONTHLY OPERATIONS ............................................................................. 26
12.1.1 Purchases Report ............................................................................................................................... 26
12.1.2 Sales Report ....................................................................................................................................... 26
12.1.3 Production Expenses Report............................................................................................................... 26
12.1.4 Transportation Costs Report .............................................................................................................. 26
12.2 REPORTS EXECUTABLE FOLLOWING RUN OF MONTHLY OPERATIONS ............................................................ 26
12.2.1 Valuation Data (compact version) ...................................................................................................... 26
12.2.2 Valuation Results (detailed version) ................................................................................................... 26
12.2.3 Stock comparison report..................................................................................................................... 26
12.2.4 Analytical Ledger Postings check report ............................................................................................. 26
12.3 AD HOC REPORTING .................................................................................................................................... 26
13
TECHNICAL DETAILS: MATERIAL LEDGER ..................................................................................... 26
13.1 MATERIAL LEDGER FIELDS ......................................................................................................................... 26
13.2 MATERIAL LEDGER VERSIONS .................................................................................................................... 27
13.3 REVENUE DOCUMENTS AND THE ML .......................................................................................................... 29
13.4 MM-ORIGINATING ACCOUNTING DOCUMENTS AND THE ML ......................................................................... 30
13.5 UPDATING THE MATERIAL LEDGER ............................................................................................................. 30
13.5.1 Online update .................................................................................................................................... 30
13.5.2 Offline Update ................................................................................................................................... 32
13.5.3 MM data ............................................................................................................................................ 32
13.5.4 FI data............................................................................................................................................... 32
13.5.5 CO data ............................................................................................................................................. 32
14
TECHNICAL DETAILS: VALUATION ................................................................................................... 33
15
TECHNICAL DETAILS: WAREHOUSE BOOK ..................................................................................... 35
16
TECHNICAL DETAILS: ANALYTICAL LEDGER ACCOUNTING ..................................................... 36
17
TECHNICAL DETAILS: YEAR-END CLOSING (DEVALUATION AND INVENTORY BOOK)....... 36
17.1
17.2
18
REQUIREMENTS .......................................................................................................................................... 36
SOLUTION .................................................................................................................................................. 37
APPENDICES ............................................................................................................................................. 37
18.1
18.2
SAP Hellas
APPENDIX 1: MATERIAL VALUATION PROGRAM DOCUMENTATION .............................................................. 37
APPENDIX 2: TREATMENT OF CYCLIC PRODUCTION/PLANT TRANSFERS ......................................................... 40
Page 3 of 40
21/6/2012
VALUATION APPLICATION: TECHNICAL DESIGN DOCUMENT
3
Key Terms and acronyms
The following key terms will be freely used henceforth in this document and must therefore be properly
defined at the outset:
3.1
Material Valuation
This refers to the procedure whereupon ‘valuated’ (in the SAP R/3 sense, i.e. materials with accounting
view) materials are assigned a new price (or prices, since, depending on the valuation method, the
remaining stock price and the consumption price are a priori different). This is achieved by solving the
Valuation Equation.
3.2
Warehouse Book
This is a report (henceforth denoted ‘WHB’) of the material movements and financial documents that
pertain to the assignment of value to these materials. It is printed (or saved on a CD) once per month, in
either trial balance (‘
’) or analytical ledger form
(‘
’
’) and constitutes a legal book in Greece. According to rule 270, to the extent that the
columns of the report provide the necessary cost structure information, the WHB renders printing of
another legal book (‘Cost Production Book’, ‘
’) unnecessary and
essentially obsolete (the material valuation application makes indeed use of this bylaw).
3.3
Analytical Ledger
The name (henceforth denoted with ‘AL’) refers to a specific range of accounts (9*) in the Greek Chart of
Accounts in which the cost flow of the whole enterprise is manifest. The Material Valuation Application is
responsible for performing the material-relevant postings in the AL.
3.4
Material Ledger
This refers not to the SAP R/3 component with the same name but to table J_1GVL_ML (henceforth
denoted ‘ML’) in which material-relevant transaction data from MM, FI and CO are gathered after being
filtered and assigned a proper transaction category and logical column according to the application
customizing.
3.5
Valuation equation
A dual equation (per quantity and per value) relating initial and final stock for each valuated material within
a period. There are many ways to write it down but the most generic one reads:
Quant InitStock Quant Inputs Quant EndStock Quant Consumptions and similarly for values:
ValueInitStock ValueInputs
ValueEndStock ValueConsumptions
The left-hand side (LHS) of the equations contains known values while the right-hand side (RHS) contains
objects that receive values. The valuation equation essentially amounts to a prescription of how to split
the total LHS value into remaining stock and consumption values. The specific algorithm of how to do this
is prescribed by the valuation method.
The ‘inputs’ to the LHS include several types:
Goods Receipts from Purchasing.
Goods Receipts from Production (direct material + expenses).
Other goods receipts with ‘own value’.
Goods receipts from subcontracting.
Goods receipts from other stores assigned a value and accompanied by a legal document (‘
’) .
Material to material transfers (‘
’).
Goods receipts from material assembly.
Goods receipts from plant transfers (plant level valuation)
Other Invoiced expenses (e.g. shipping costs).
SAP Hellas
Page 4 of 40
21/6/2012
VALUATION APPLICATION: TECHNICAL DESIGN DOCUMENT
There is one such ‘double’ equation for each ‘valuated object’. The precise definition of what this
‘valuated object’ is, depends on the valuation level. In the simplest form it can be identified with the
‘material’ concept (valuation level = company). Other possibilities exist, though:
Valuated object = material + plant (valuation level = plant)
Valuated object = sales order line item
Valuated object = project etc.1.
3.6
Transaction Category
This is a two-digit code that groups together MM movement types and FI document types/accounts. It
serves two purposes:
To provide rules as to how the corresponding MM/FI data are to be taken into account by the valuation
equation. For example the MM movements 101B, 121B, 122B are all assigned the transaction
category ‘PU’ (for ‘purchases’), while the corresponding 101F etc movements the transaction category
‘PD’ (for ‘Production’).
To provide a means for account assignment with respect to the Analytical Ledger postings of the
application. In that respect, if the AL accounting requires a more detailed analysis and breakdown then
more transaction categories must be employed.
In direct relation to their purpose transaction categories come in three types:
Predefined: these are used by the valuation program to perform the calculations and should therefore
not be used differently from the way they were contrived (see the Material Valuation Program
documentation for more details).
Freely defined (a): These are transaction categories that could be defined and assigned to
‘consumption-type ’ MM movements (e.g. a new transaction category ‘01’ could be assigned to
‘consumption to WBS element’ movements). These transaction categories appear in the RHS of the
valuation equation.
Freely defined (b): These are transaction categories that appear in the LHS of the valuation equation.
They are not of consumption type; rather, they are used in conjunction with the user exits of the
application in order to perform calculations in user-defined valuation methods. (see the Material
Valuation Program documentation for more details).
All transaction categories are defined in customizing table J_1GVL_WHB008.
3.7
Document Category
Strictly speaking this two-digit code (the name is an unfortunate misnomer carried over for historic
reasons) refers to terms in the valuation equation and the corresponding prices that a material may be
assigned. Examples are:
Remaining stock price (RM),
Consumption price (CO),
Negative consumption price (NC, used for stock in transit movements),
Average total production cost price (PD),
Average production price due to direct material production only (PC).
Plant-to-plant transfer price (T2, in case of valuation at plant level).
Values for each document category (price) are calculated in the material valuation program and stored in
table J_1GVL_WHB011. Unlike transaction categories document categories are not freely defined but
amount to the fixed values of the corresponding DDIC domain in SAP R/3.
3.8
Warehouse Book Logical Column
This is a two-digit code that signifies a column of the ML table for storing the quantity/value of an
MM/FI/CO line item. To each Logical Column XX correspond in general 3 fields in the ML: VLXX_QS
(quantity), VLXX_VS (value according o SAP valuation), VLXX_VA (actual or historic cost value
computed based on the prices determined via the valuation procedure). The following must be noted
regarding the logical columns:
FI and CO items in the ML update only the corresponding value fields (not quantities).
1
Note: There have been variants of the Greek Localization application to cover the last two cases but they have not yet been
included in the standard version.
SAP Hellas
Page 5 of 40
21/6/2012
VALUATION APPLICATION: TECHNICAL DESIGN DOCUMENT
For FI and CO items as well as for MM movements that are input to the valuation equations (e.g.
purchases) the SAP and actual values are the same.
For items corresponding to MM movements that are part of the output of the valuation equation (that
is, they receive value after solving it, e.g. sales, consumption to production etc.) the SAP and actual
values are a priori different.
The logical columns also appear in table J_1GVL_WHBPOL but without the VL prefix (a remnant of
version 40B).
It is possible to define new, customer-specific Logical columns. This may be required if a
customer wants to show some movements in a special column of the WHB (e.g. a pharmaceutical
company wants to print ‘Goods Issues for Lab Inspection’ separately). The procedure to define a new
logical WHB column (named for example ‘YY’) amounts to:
1) Create a triplet of fields (VLYY_QS of type ‘quantity’, VLYY_VS and VLYY_VA of type ‘value’) in
an append-structure to table J_1GVL_ML.
2) Create a corresponding triplet of fields without the ‘VL’ prefix (i.e., fields: YY_QS, YY_VS and
YY_VA) in an append-structure to table J_1GVL_WHBPOL for storing the corresponding totals
after running the WHB.
3) Customize the corresponding movements accordingly (see the movements-customizing
section).
The WHB program will automatically detect the new column and print the corresponding records
according to customizing.
3.9
Warehouse Book Physical Column
While the number of logical WHB columns is practically unlimited, the physical constraint of max 255
characters per line of the WHB (some of which, approx. 65, are reserved for details of the corresponding
movement, e.g. movement description, partner description etc.) limits the number of usable columns
down to 11-13 (depending of the allocated size). Thus many logical WHB columns must be printed under
the same header in the WHB. The physical column of the WHB is thus simply defined as the position in
the WHB under which several logical columns are printed. Physical columns are implicitly defined in the
‘WHB layout’ customizing. The relation between logical and physical columns is therefore N:1.
3.10
Valuation frequency
The valuation frequency refers to ‘how often’ the valuation procedure is performed. Given that rule 270
requires company results at the least per trimester the available choices are:
Once per month.
Once per trimester.
As per ministerial decision POL.1024/2007 (see note 1148425), the valuation process can also run:
Once per year (annual).
3.11
Valuation horizon
The valuation procedure is a periodic one. The valuation horizon determines the time interval for which
data are gathered so as to perform the valuation procedure. Possible choices are:
Monthly valuation: only data for the current month are taken into account. Makes sense only for
valuation frequency = month.
Trimester-to-date: data of the last incomplete trimester are taken into account. That is, for January:
only month 1 is taken into account, for March: months 1,2 and 3, for April: month 4, for May: months
4 and 5, for August: months 7 and 8 etc. Makes sense only for valuation frequency = trimester.
Year-to-date: all data of the current fiscal year are taken into account. That is for January only month
1, for March months 1, 2 and 3, for April months 1,2,3 and 4 etc. Makes sense for valuation
frequency = month, trimester, and year, although the second option is not really used.
It must be pointed out that the choice of valuation horizon is not a trivial one as there are important
consequences associated with either choice:
The choice ‘horizon = month’ entails a rather uniform run time for the valuation application though the
year. It also has the advantage that there are no adjustments to carried forward totals. The
drawbacks are: firstly, a more rapid fluctuation of the valuation results during the fiscal year;
secondly, a more serious drawback is that materials with neither stock or movements during a month
(say August) for which a late invoice is received cannot be valuated and lead to a non-trivial (not of
‘rounding’ type) valuation error.
SAP Hellas
Page 6 of 40
21/6/2012
VALUATION APPLICATION: TECHNICAL DESIGN DOCUMENT
On the other hand the choice ‘horizon = year’ allows for damped fluctuations of the price during the
year at the expense of progressively longer run times (as more data are read each month) and the
necessity of computing, printing and interpreting adjustments in the WHB. Regarding the late
invoices issue this is alleviated in the year-to-date case provided that according to the Greek Code all
invoices are received at the end of the fiscal year.
The trimester solution interpolates between the previous two ones.
Based on the above monthly valuation should be reserved for companies with strict procedures regarding
vendor invoices.
3.12
Valuation Method
This denotes the algorithm used for solving the valuation equations. Currently supported methods
include:
First-In-First-Out (FIFO) for raw materials and trading goods (a variant for produced materials also
exists but involves many assumptions). In this case the remaining stock is valuated first using the
period's goods receipts on a first-in first-out basis and the consumptions are valuated afterwards. Thus
the consumption and remaining stock prices are in principle different.
Last-In-First-Out (LIFO) for raw materials and trading goods. In this case the remaining stock is
valuated first on a last-in first-out basis and the consumptions are valuated afterwards. Here also the
consumption and remaining stock prices are in principle different.
Weighted Moving Average (WMA). Remaining stock and consumptions are assigned a uniform
price.
Fixed cost (FIX). Used for by-products. Assigns a fixed price (e.g. SAP price) to the production cost
and uses WMA to find the consumption and remaining stock value of the by-products.
Weighted Moving Average with Work-In-Progress (WMAW). Variation of WMA in that the cost of
production used to determine the input part of the valuation equation is modified so as to take into
account Work-In-Progress (WIP).
Weighted Moving Average for Plant-Level Valuation (WMAPL). Variation of WMA in which plant
transfers are treated as input with values determined at the source plant. This makes sense for valuation
at plant level and requires the treatment of potential circular transfers.
Using the enhancement options of the valuation program it is easy to define customer-specific
valuation methods ranging from simple variants of the standard ones supplied with the application to
radically different ones. Examples of such variants can be requested from SAP Hellas to be used as
templates.
3.13
Valuation Level
This refers to whether the valuation procedure assigns a unique price to a material within a company
code (and its plants)
‘company-level’ valuation or individual prices at each plant (or group of plants)
‘plant-level’ valuation. It must be emphasized that this choice is totally disjoint from the similar choice
when setting up MM in SAP R/3. The Greek code calls for ‘company-level’ valuation but also allows plant
level valuation. Note: plant-level periodic valuation requires a careful treatment of pant transfers. Unless
the company wants to use the results of the Greek Localization valuation application for executive and
not just legal purposes, setting up the application at plant-level is not recommended as it unnecessarily
overburdens the valuation program (more ‘objects’ to valuate -materials times plants-, potential circular
transfers etc.)
3.14
Valuation error
This denotes the amount for which the valuation equation is not satisfied. A list of materials having such
‘valuation errors’ is produced at the end of the valuation program printout. A valuation error can occur
mainly for two reasons:
3.14.1 Rounding errors.
This the most common reason.. For example in the WMA valuation method when a uniform price is
determined for remaining stock and consumptions as:
pWMA Value InStok Value Inputs Quant InStock Quant Inputs ,
SAP Hellas
Page 7 of 40
21/6/2012
VALUATION APPLICATION: TECHNICAL DESIGN DOCUMENT
the remaining stock value is Value EndStock
pWMA Quant EndStock rounded to 2 decimals. Similarly the
total consumption value ValueCons.
pWMA Quant Cons is also rounded to 2 decimals (for €). It is
conceivable then to have Value EndStock Value Cons Value Init .Stock Value Inputs due to rounding. The
resulting valuation errors are of the order of magnitude of one cent of the €.
3.14.2 ‘True’ valuation errors.
An example of such errors is when a material has neither initial stock nor MM movements during the
valuation horizon period and yet a late invoice (FI) is received. Then all terms of the Quantity branch
of the valuation equation are zero; for the value branch though we have
Value InitStock Value EndStock Value Consumptions 0 but Value Inputs 0 (because of the late invoice)
and a valuation error equal to the value of the invoice is produced.
Such valuation errors can be avoided using year-to-date valuation but late invoices spanning two
fiscal years will result in a valuation error even in that case.
Valuation errors are saved in the database (table J_1GVL_WHB010) under transaction category ‘ER’.
This transaction category must be included in the A/L postings customizing so that the postings
generate the correct remaining stock value.
3.15
Customizing tables
A set of tables of the type J_1GVL_WHB0XX used for the customizing of the application. See the
customizing section for more details.
3.16
Data tables
These tables store the data from the non-test runs of the valuation and WHB application. They are:
J_1GVL_WHB011: contains valuation results per document category.
J_1GVL_WHB010: contains valuation results per transaction category.
J_1GVL_WHBPOL: contains the monthly totals from the runs of the warehouse books.
3.17
Control Tables
The application is prevented from running in ‘non-test’ mode again after ‘non-test’ (alt. ‘productive’ or
‘official’) runs have updated the relevant data tables. These tables are:
J_1GCONTROL for the valuation and A/L applications. This table has a single record per year.
To reset, change the last field (‘period’) to a previous value.
J_1GVL_WHB009 for the WHB program. This table has one record per month.
To reset delete the record.
The utility ‘initialize production runs’ (tr.code J1GVL_T11) has views to these tables for performing the
reset (selection-screen pushbuttons).
Note: resetting the control table has nothing to do with reversing the data of the production run per se.
The valuation and WHB data can be refreshed by using the same ‘initialize production runs’ utility
(tr.code J1GVL_T11). However, transaction data produced by the application (like: FI postings generated
via either FI re-postings or A/L postings or CO data from re-posting) have to be reversed manually.
3.18
Reposting
This is a method of transferring variances between SAP values and historic cost values computed by the
valuation program to CO. Only variances produced by materials and transaction categories labeled as
‘repost –relevant’ in the customizing of materials and transaction categories are transferred. There are
two forms of reposting:
CO reposting: in this case the variances produced are posted per primary cost element to a pair of
orders (transaction KB11). Then CO will allocate these amounts to production orders and afterwards
the main valuation will read off the corresponding amounts as a type of production expenses (direct
labor, overhead or even interpret them as ‘direct material cost’ – the latter case makes sense for
spare parts and consumables variances). This form of reposting only makes sense for spare parts
and consumables, not for produced materials (since for the later the final production costs per order
SAP Hellas
Page 8 of 40
21/6/2012
VALUATION APPLICATION: TECHNICAL DESIGN DOCUMENT
must be known ahead of time and therefore the complete CO settlement/assessment must have
been executed).
FI reposting: in this case the variances are indirectly transferred to CO via a FI posting between a
B/S and a P/L account. To the extent that the variances are not going to be distributed to production
orders FI re-postings make sense for all materials (buy + make). Of course one may use the FI
reposting technique for transferring variances to CO that must be distributed but in that case FI repostings should only be used as a preliminary valuation in as much the same way as the CO repostings.
3.19
Devaluation
In the context of this application this term refers to two concepts, both allowed at the last period of the
year:
Selection of minimal between historic (valuation) and replacement (last purchase) prices.
Ad hoc devaluation of material stock (e.g. for scrapping).
Both options apply to the remaining stock price and not the consumption price. This allows avoiding the
mayhem of rolling such variances up the production ladder. As a result a valuation error is produced:
error
priceHistCost price New quantity EndStock . This is stored in table J_1GVL_WHB011 under
transaction category ‘DV’, then is printed by the WHB program and finally read off by the valuation of the
1st month of next fiscal year.
3.20
Inventory Book
This is the ‘last’ component of the application. It runs after the last valuation and WHB of the fiscal year. It
produces a list of inventory (by quantity and value) and updates the carry-forward totals of the application
data tables for the next fiscal year.
3.21
Offline Update
This denotes the procedure whereupon the data in the ML are inserted periodically and not in real time.
This maybe required either because online update is not activated or because some additional data need
to be inserted (e.g. the customizing has changed during the period).
3.22
Adjustments to carried-forward totals
The concept of adjustments plays a crucial role in the case of year-to-date valuation (see valuation
horizon). The need for adjustments can be traced back to the fact that the Greek Law requires the (legal)
Warehouse Book to include only the current month’s data while the valuation procedure can have a
larger horizon. More specifically, adjustments are required to the carried-forward totals of the warehouse
book because of the following mutually exclusive requirements:
1. The WHB of period N (being a legal report) must start off with carried forward totals = the cumulative
2
year-to-date totals of the previous month N-1 (as printed on the last month’s WHB, that is, computed
using the year-to-date valuation prices for the horizon: 1 to (N-1)).
2. If the valuation horizon is larger than a month (trimester-to-date or year-to-date) then the data printed
on some (TTD) or all (YTD) past months (1,2…N-1) have been revaluated – the carried forward
totals are wrong!.
Example:
Consider the case of a material for which 1000 units were sold in January and another 2000 in February.
The valuation procedure uses the year-to-date period and found a consumption price = 10€/unit in
January and 11€/unit in February (recall that this means that the price was 11€/unit for the whole January
+ February period!). Thus, the cost of goods sold was 10.000 for January (N=1) and 33.000 for the
January to February period. Its crucial to realize that the net result of the N=2 period is not equal to the
sales volume of that period times the YTD price. The net result of period N=2 is found by subtracting the
year-to-date totals of N=1+2 minus the one for N=1, yielding an effective price for the period of February
of 11,5€/unit.
2
This holds for N>1. For the first month there are by definition no adjustments.
SAP Hellas
Page 9 of 40
21/6/2012
VALUATION APPLICATION: TECHNICAL DESIGN DOCUMENT
Valuation (year-to-date) results
period
Sales Quantity Cost of Goods Sold YTD valuation price
N=1
1.000
10.000
10
N=1+2
3.000
33.000
11
net result for N=2
2.000
23.000
11,5
If we now print the WHB for January we will obviously have COGS = 10.000€ as the amount to be
carried forward to the following period. What would now the WHB for February look like?
WHB of February (without adjustments)
Sales Quantity Cost of Goods Sold January Price New YTD price
carried forward from January
1.000
10.000
10
11
February totals
2.000
22.000
cumulative YTD totals
3.000
32.000
The new cumulative amount must agree with the valuation result of 33.000 but as seen it is 1000 sort of
the correct value. Why is that so? Because the carried forward totals from January must be adjusted to
reflect the new price (10 11), in other words from 1000x10 to 1000x11 = 11000!
Clearly therefore the proper solution to the above problem is that the WHB for month N must start off
with the data as printed in period N-1 but with an additional line printed indicating that the carriedforward totals have been adjusted to reflect the most recent revaluation:
WHB of February (with proper solution for adjustments)
Sales Quantity Cost of Goods Sold January Price New YTD price
carried forward from January
1.000
10.000
10
11
adjusted carried forward totals
11.000
February totals
2.000
22.000
cumulative YTD totals
3.000
33.000
However (for technical reasons related to performance3) this solution had not been implemented in the
original versions of the application. An alternative approach to printing the adjustments is to start off
with the (essentially ‘wrong’) carried forward totals, leave them unaltered, add the current month’s
movements (with the correct -most recent- valuation prices) and then compute the adjustments as the
difference between the so computed cumulative totals and the true year-to-date totals which are taken
from the valuation application. Note hat such a comparison is only possible at the valuation level. Thus
the adjustments are printed per material in separate areas of the WHB before the company totals (if
valuation level = company) or before each plant’s totals (if valuation level = plant). Given that the vast
majority of companies use company level valuation there is a misconception that the adjustments are
printed before the company totals and not under each material because we don’t have valuation at the
plant level. This is wrong. In fact even if we used valuation at the plant level we still could not print the
rd
adjustments under each material because the WHB has still one more level below plant (the 3 party
location) which is not taken into account during valuation (if all this seems incomprehensible read first
the warehouse book section where the hierarchical level of the printout is defined).
Using this approach the adjustments would be printed like this:
3
The customizing allows printing movements with a priori different prices in the same logical WHB column. Thus it is not possible to
adjust the totals stored in table J_1GVL_WHBPOL. Rather it is required to adjust all movements of the past periods belonging to the
valuation horizon. This would significantly affect the performance of the WHB. An alternative solution based on a new version
(‘COL’) of the ML has been recently included (see main text).
SAP Hellas
Page 10 of 40
21/6/2012
VALUATION APPLICATION: TECHNICAL DESIGN DOCUMENT
WHB of February (plant X)
Sales Quantity Cost of Goods Sold January Price New YTD price
carried forward from January
1.000
10.000
10
11
February totals
2.000
22.000
cumulative YTD totals
3.000
32.000
Adjustments Section
adjustment for material …
1.000
Corrected Company totals (assuming valuation at company level…)
adjusted cumulative totals
33.000
As explained above this solution has the merit that adjustments are readily obtained by comparing with
the valuation results (table J_1GVL_WHB010). The disadvantage is that the true nature of adjustments
is not manifest in this approach. A more serious drawback is that the results at the plant level (for
company level valuation) are not corrected for year-to-date effects (the plant result of 32000 is wrong!).
For these reasons an approach that allows dealing with the performance problem while at the same
time displaying adjustments as a manifest change of carried forward results has been developed. It is
based on a new version in the ML table where all movements of the valuation horizon period are
collected per key of the WHB printout (i.e., material/valuation type/plant/3rd party) and stored not once
but for each revaluation of the year that affects them (that is, the January results are calculated and
stored in 12 records per key if the valuation is YTD, the August ones in 5 records/key, the December
ones once; each key will have 78 records per year for the YTD horizon). The computation of this ‘COL’
version (for collect’) is done during the valuation runs so as not to affect the performance of the WHB.
Adjustments are stored in table J_1GVL_WHBPOL with the field ‘adjustment’ equal to ‘A’4 .
3.23
Rounding differences
Note that the alternative approach to the adjustments issue as explained above defines adjustments
implicitly as the difference between the valuation year-to-date results and the year-to-date totals of the
WHB. If all is correct no such difference should remain. In particular: suppose we implement a proper
solution to adjustments as a revaluation of the carried forward totals; should we then end up with no
differences at all? The answer is no. After all, there do exist differences between the WHB and the
valuation totals even for N=1 (where no adjustment is required!). This happens because the WHB values
are added per document and line item after they have been rounded to two decimals while the valuation
totals are computed as total quantity times the price and then rounded. The two computations have
different rounding levels!
To see how residual rounding errors might occur consider the above example but with the January
price calculated to 10,011€/unit. Then the valuation program shows COGS = 10.011€. Suppose now that
all sales took place as having quantity = 1 unit per line item. Then the WHB (as a ledger5) will display
1.000 line items with value 1x10,011 = 10,01€ each (rounded to 2 decimals) or 10.010€ in total. Thus a
rounding error of 1€ between WHB and valuation is generated. For this reason the ‘alternative’ approach
to adjustments is still used in order to catch and display such rounding errors even if the carried forward
total have been recalculated.
4
In older versions of the application (where adjustments and rounding errors are not distinguished) they are
saved with ‘X’.
5
The WHB as a trial balance is exactly the same program but simply without displaying the line items so it will give the same result.
SAP Hellas
Page 11 of 40
21/6/2012
VALUATION APPLICATION: TECHNICAL DESIGN DOCUMENT
T
Transaction
categories
N:1
1 physical WHB
column where
all T and L are
assigned
L
Logical
WHB
Columns
• adjustments shown per material + physical WHB column
• N:1 relationship between tract and LWHB column
• Adjustment of period P = Sum(T/P) – Sum(T/ P-1)
– Sum(L LWHB cols for period P)
To perform such computations an algorithm is required. The algorithm must connect the basic parameter
of valuation (the transaction category) to the basic parameter of the WHB (the logical column). Such a
relation is established by assigning one (or none) logical column to each transaction category (see
transaction categories customizing). Note that this means that there may be more than 1 transaction
categories assigned to a given logical column. The following figure explains how the ‘adjustment’ is
computed: totals for all logical columns ‘L’ appearing under a given physical column are computed. Then
totals for all transaction categories (‘T’) assigned to these logical columns are computed for the current
(‘P’) and the previous period (‘P-1’) and subtracted to produce the effective monthly result. This ‘correct’
result is compared to the period’s WHB totals for the relevant logical columns to give the end result.
In our original example suppose we have a transaction category ‘SL’ mapped onto the logical column ‘SL’
(recall that this simply denotes the ML field J_1GVL_ML-VLSL_VA). Then:
1. If we have not implemented the carried forward adjustment we compute ‘rounding error’ = 33.000
(corresponding to P=2 YTD above) minus 10.000 (P=1 result) minus the WHB period amount =
22.000, thus we find adjustment = 1000.
2. If we do implement the carried forward adjustment then we compute ‘rounding error’ = 33.000
(corresponding to P=2 YTD above) minus 11.000 (P=1 result + adjustment of 1.000) minus the WHB
period amount = 22.000, thus finding a residual adjustment = 0.
Thus, the whole discrepancy is in this scenario due to the revaluation effect and not to rounding (it is
easy to redo the computation with price 10,011 for January which will generate a genuine rounding
error…).
Rounding errors are stored in table J_1GVL_WHBPOL with the flag ‘adjustment’ equal to ‘R’6 (and the
plant, i.e., field J_1GVL_WHBPOL-WERKS, blank if valuation is at company level).
4
Components
The application consists of the following:
A set of customizing tables that allows to tailor the application to the specific needs of each customer.
The Material Ledger table J_1GVL_ML where material-relevant transaction data from MM, FI and CO
are stored.
A set of application tables in which data of the official program runs are stored.
A set of applications:
Material Valuation
determines the historic cost price based on the input data stored in ML.
Warehouse Book
uses the historic cost prices to print the legal WH book.
use the historic cost prices to update the Analytical Accounting sector of
Analytical Ledger postings
the Greek CoA.
Year-end devaluation
selection of minimum price between historic and replacement cost or ad hoc
devaluation of certain materials.
Inventory Book
uses valuation and devaluation results to print the Inventory Book at the end of the
fiscal year and transfer the results to the new year’s application tables.
6
In older versions of the application (where adjustments and rounding errors are not distinguished) they are
saved with ‘X’.
SAP Hellas
Page 12 of 40
21/6/2012
VALUATION APPLICATION: TECHNICAL DESIGN DOCUMENT
A set of utilities:
Production run initialising
allows resetting the control tables and refreshing the application tables so
that one or more components of the application may run again in non-test mode.
Initial stock update
allows populating the application tables before going live (assumes simultaneous
go live between SAP R/3 and the valuation application).
A customizing-checking utility.
The core program J_1GVL_WHBFORMS that has the routines that check the customizing and update
the ML. The program is invoked either during online update from the MM update user exit MB_CF001
and the RWIN components ZWHB and ZRV or offline from the ‘offline update’ utility for managing the
ML.
Utilities for managing the Material Ledger (insert data offline, delete data, read data).
A set of pre-valuation reports:
Purchases/Sales/Expenses ALV reports
ML values report per logical column.
Stock report per period (can also run during valuation or after the WHB to compare stocks).
A set of post-valuation reports:
Compact valuation results report.
Hierarchical valuation results report
AL postings comparison report.
5
Processes
The processes involved in the monthly execution of the valuation application are described below:
The central object of the application is the Material Ledger table J_1GVLML that contains data from MM, FI
and (in some more recent versions) CO that have been deemed ‘valid’ with respect to the application
customizing by the ML update routines. Having the data in a central database table allows easy reporting
and fast execution of the application components by activating proper indices. The ML may also contain
data of non-valuated materials, which are nevertheless to be printed on the WHB. For the modes of updating
the ML the reader is referred to the ML section.
Valuation prices
MM
MB_CF001
ML
FI
valuation
RWIN
Valuation
data
FI repostings
A/L
postings
CO repostings
CO
Warehouse
book
adjustments
3rd party stock
After the (online or offline) update of the ML the valuation application reads the ML data (and possibly CO
data if no CO data have been directly inserted in the ML like in more recent versions) and performs the
valuation of all eligible materials. In ‘non-test’ mode totals per valuated object and price/transaction category
are stored in database tables (see data tables) and all MM line items of the current period7 in the ‘DET’
version of ML are updated. If a reposting scenario has been implemented the variances between SAP prices
7 The values of previous months of the ‘DET’ version are not changed so that the WHB can be re-executed for these past periods
without producing different results. The ‘COL’ version though of ML does have revaluated results for the whole YTD period.
SAP Hellas
Page 13 of 40
21/6/2012
VALUATION APPLICATION: TECHNICAL DESIGN DOCUMENT
and valuation prices are transferred to CO (directly in the CO re-postings case or indirectly in the FI repostings case).
After the valuation program has been executed in ‘non-test’ mode it is the turn of the Warehouse Book(s) to
be executed. The carried forward amounts from the previous periods are compared with the ‘COL’ version of
the ML in order to determine the adjustments to carried forward totals (recent versions only!); the new
cumulative totals are compared with the valuation results (table J_1GVL_WHB010) in order to determine
potential rounding differences (as explained above in the original versions of the application this comparison
gives the rounding and adjustment values combined).
The next operation involves the AL postings that are performed according to the valuation frequency
settings. The AL postings use values from the valuation tables. In the case of company-level valuation the
WHB totals are also read in order to determine the value of 3rd party stock that in the case of company level
valuation is not directly read off from the valuation data.
This concludes the set of monthly operations. At the end of the year two more components of the
applications are used:
The first is the devaluation program. Its use is optional. It allows changing the price of the remaining stock in
an either ad hoc manner of by selecting the minimum between historic cost and replacement price.
The second is the obligatory (and legal) Inventory Book application that combines quantities from the WHB
table and values from the valuation tables in order to print the legal Inventory book report. This combination
of data retrieval allows to allocate all remaining rounding differences to plants with stock so as to ensure that
the whole amount of the valuation tables is assigned to the WHB remaining stock. At the end of this
procedure period ‘00’ of the next fiscal year is updated in all Warehouse Books.
6
Integration Aspects
6.1
Input
The application uses as input:
MM documents (almost all material movements, with the possible exception of movements that do
not have to be shown on the WHB or affect the valuation procedure, e.g., movements that do not
change the plant or 3rd party location of the material like 321, 311 etc8)
FI documents: these may include accounting documents of MM (purchases invoices) or SD origin
(billing documents) or even ‘direct’ FI documents with material and plant information. Only
documents of valid document type and posting to valid account, plant and material are taken into
account.
CO documents: production expenses per order posting to a valid cost element.
Also one may say that the application uses input from other modules like SD (document flow), PP
(production order details, product costing info etc.) in an indirect way, that is to say, not as documents per
se but in order to update certain non-key fields of MM or FI documents in the ML.
6.2
Output
The output of the application includes two types:
Update of database tables of the application (that is, not SAP R/3 transactions or tables) with the
results of the various components of the application.
SAP R/3 transactions. These are:
o FI documents produced by the Analytical Ledger component of the application that post the
valuation results to the ‘Analytical Sector’ of the Greek Chart of Accounts.
o Optional: CO documents posted during the ‘CO-repost’ phase of the valuation procedure.
o Optional: FI documents posted during the ‘FI-repost’ phase of the valuation application.
o Optional: MM ‘change price’ transactions (MR21, MR22) that may update the SAP price
according to the historic cost prices determined by the valuation program.
8
Of course one may choose to label even such movements as valid and take them into account
SAP Hellas
Page 14 of 40
21/6/2012
VALUATION APPLICATION: TECHNICAL DESIGN DOCUMENT
o
7
Optional: Update of the CO-PA using the historic cost price.
Customizing
7.1
Global Settings (table J_1GVL_WHB000)
Here the basic settings of the application are defined for each relevant company code. The relevant fields
are:
Company Code.
Year-to-date flag: corresponds to the valuation horizon choice.
Period type: use ‘P’ unless the company code variant should be overridden with the default ‘K1’
variant, for example in companies where month and period do not coincide. For companies with
fiscal years starting say in 1st of April, the default ‘P’ choice should be used.
Valuation frequency: corresponds to the valuation frequency choice.
Negative stock check: determines whether the ‘SUM’ version of the ML table is activated for checking
negative stocks per posting date. It should only be used with online update of the ML and with proper
migration of historic data of the ML SUM version. It terminates the MM posting update. A variant of
this option for checking negative stocks during the MM line item editing (and not on the update) has
been developed by SAP Hellas and is recommended rather than activating the SUM version here,
but has not yet been included in the standard Greek Localization packaget.
Routines program: Name of customer program (of type 'I') where additional routines for valuation can
be maintained. Currently 2 types of additional routines are supported:
o New valuation methods (routines declared in customizing and called dynamically in the program
depending on material type/valuation class.
o Form "CUSTOMER_FUNCTION" is called during accessing J_1GVL_ML in the form
"READ_ONLINE_WHB" of the valuation program. Here one may define and fill internal tables to
be used later in the new valuation method.
Example:
A customer wishes to create new valuation methods, then this field must be updated with the name of
the customer include program where these routines are to be found. If a name is entered then code
lines are automatically appended to program J_1GVL_VLCI (material valuation generated include).
By maintaining this field the program J_1GVL_VLCI (never to be edited manually) is automatically
generated and includes the specified ‘include’ program. If the system options do not allow for transport of
J_1GVL_VLCI create a transport of copies manually.
As per note 1138580 the valuation program’s enhancement technique has changed. The ‘routines
program’ field in global settings and include J_1GVL_VLCI, are no longer used. Customer routines
should be created in include ZXJ1GVL.
7.2
Warehouse Books: definition (table J_1GVL_WHB001)
Here the warehouse books are defined. The fields are:
The WHB code
SAP Hellas
Page 15 of 40
21/6/2012
VALUATION APPLICATION: TECHNICAL DESIGN DOCUMENT
Whether the WHB should be taken into account in valuation. This is required because in the case of
branches it is possible to save the line items of MM/FI items in more than one WHB codes. In that
case only one of these WHB should be ‘primary’ or ‘valuation-relevant’ otherwise the valuation
program will double-count the corresponding entries.
The mode of legal issuing of the WHB (trial-balance = space).
Value-Type: whether the WHB prints historic cost (actual, ‘A’) values from valuation or SAP values
(S) or only quantities or IAS valuation values.
7.3
Warehouse Books: texts (table J_1GVL_WHB01T)
WHB descriptions (in Greek and English).
7.4
Valuation methods (table J_1GVL_WHB019)
Includes code name and description of the valuation methods used by the application. Custom-defined
valuation methods can be defined here (example: WMAPL).
SAP Hellas
Page 16 of 40
21/6/2012
VALUATION APPLICATION: TECHNICAL DESIGN DOCUMENT
7.5
Valid Plants (table J_1GVL_WHB002)
This table contains the valid plants. Relevant fields:
Plant number
WHB code for which the plant is valid (in general a plant may be valid for many WHB codes).
Own/Third Indicator:
o ‘’
Own stock at own premises (carries value),
o ‘T’
Own stock at 3rd party's premises (carries value)
o ‘K’
3rd party's stock at own premises (does not carry value)
Value indicator: plant movements carry value (‘X’) or not (space). Note: K-type plants must always
have value indicator = space.
7.6
Valid Materials (table J_1GVL_WHB003)
This table contains the valid materials, parameterized by valuation class, type and material type. The
relevant fields are:
Material type.
Valuation type (leave blank if split valuation inactive).
Valuation class: important note: all materials are assumed to have the same valuation class per
valuation level. That is if level = ‘company code’ then all valuation areas for this company code (table
T001W, T001K) must in table MBEW be mapped to a unique valuation class.
Warehouse book code (as with valid plants: a material may be valid in many WHB codes).
Valuation method. If the material is to be valuated the relevant method (see Valuation Methods) must
be supplied here. Non-valuated materials are also allowed (for printing in the WHB). Also, for WHB
codes that either do not show values or print SAP values (like WHB = ‘S’ in the screen print below)
the relevant entries should have the valuation method blank.
Value update: material carries value (and therefore must be included in the valuation procedure).
Repost: Material’s movements contribute to CO/FI re-postings. The repost run of the valuation will
only take such materials into account.
Valuation level (new versions only). If set to ‘X’ the material is valuated at the plant level.
SAP Hellas
Page 17 of 40
21/6/2012
VALUATION APPLICATION: TECHNICAL DESIGN DOCUMENT
7.7
Transaction categories (table J_1GVL_WHB 008)
This table contains the definition and properties of the transaction categories. The relevant fields are:
The transaction code (2 digit character).
Consumption indicator: denotes that the transaction category will label movements on the right-hand
side of the Valuation equation that receive value from the valuation procedure. Transaction
categories of that type are freely defined and automatically update table J_1GVL_WHB010 without
further ado. MM movements labeled with such a transaction category (see movement types
customizing below) should use the consumption document category (‘CO’) for post-valuation update.
Sorting indicator: helps bundle together movements of the same transaction category in the WHB
printing.
Repost indicator (the ‘CO’ is irrelevant): denotes that the valuation program will compute variances
between SAP and historic cost prices for all movement types labeled with this transaction category.
Logical WHB column: this is the key mapping between valuation and WHB parameters for computing
rounding differences in the WHB.
Sign: defines the natural sign of the movements/documents labeled with this transaction category. It
has a meaning only when combined with the debit/credit AL account in the Analytical Ledger
accounts customizing (see below). Thus, for example, document type WE in purchasing has a
natural sign ‘+’ but if in one period we have more returns than receipts the corresponding field
(J_1GVL_WHB010-DMBTR) will be negative and then the AL accounts will be posted in the opposite
order (credit the ‘Debit’ account). Similarly, the sales movements (and most consumption-type
transaction categories) have a natural ‘-‘ sign because they are naturally ‘goods issues’ and the AL
customizing has been set up under that premise (i.e. credit the AL stock account and debit the AL
COGS account).
Description: a text for the transaction category (will appear in the valuation reports and in the text
amount of the AL FI documents).
Note: as already explained there are some transaction categories that have a fixed meaning and are
used by the valuation program for special purposes (see also the valuation program documentation).
Examples are: PU and GR for purchases, CP for consumption to production etc. Some of these special
transaction categories may be consumptions themselves (like CP). Another type of transaction
categories is one where they are defined by the customer but not labeled as consumptions. Such
transaction categories only make sense if one activates the customer enhancement mechanism of the
valuation program. In the screen printout above one can see transaction categories of all such types:
‘CP’ is a standard, consumption type category with a special meaning (updates internal table
TBL_ANALP in valuation, see valuation program documentation).
‘PU’ is a standard category with a special meaning (updates internal table TBL_PURCH in valuation,
see valuation program documentation) but not of consumption type.
‘56’ is a customer specified transaction category. It was contrived for companies using the EIN
approach in purchasing (purchasing account is updated during goods receipts and not using the
Greek Localization ‘PU program’). The precise way it is used can be seen in the customer include
program of valuation (see the automatically generated code in J_1GVL_VLCI program). Of course if
the customer include program has not been activated or does not contain instructions of how to use it
this transaction category is pointless.
‘9E’ is also a customer specific transaction category. It is of consumption type and has no special
meaning.
SAP Hellas
Page 18 of 40
21/6/2012
VALUATION APPLICATION: TECHNICAL DESIGN DOCUMENT
7.8
Valid Movements and Document types (table J_1GVL_WHB005)
This customizing table serves a dual function, to define the valid documents types (for FI postings) and
the valid movement types for MM postings.
Valid document types are defined by specifying the document type and leaving the rest of the key
fields pertaining to MM movement types blank.
Valid MM movements require the document type field blank and the full movement type key (type +
indicators: special stock, movement, receipt, consumption) specified. The D/C indicator maybe left
blank in which case it is interpreted as a wildcard.
The non-key fields are:
Transaction category.
Algorithm for updating the "Material Ledger" table J_1GVL_ML with material movements and
accounting documents during "real-time" (as opposed to "after valuation") posting. More than one
logical WHB columns may be updated for each document.
For each column to be updated use XX/B/NN where:
o XX is one of the allowed logical WHB columns (e.g. IS, PU, GR..)
o B can take the values: Q (update quantity only), V (update value only), QV(update both). New
allowed options are N (update quantity with opposite sign) and NV.
o NN is any of the allowed function modules for determining the value (use only of B contains 'V').
More than one column can be updated for one line item using X1/B1/N1, X2/B2/N2, etc
Algorithm for updating the value fields of the Material Ledger table J_1GVL_ML with the prices
found by the valuation procedure.
This is performed at the end of the non-test run of the valuation program.
The format that should be used is: X1/P1, X2/P2, where:
o X1, X2... are logical WHB columns
o P1, P2 are the document categories for the valuation price to be used for the update (for
example: CO = consumption price).
In the above example:
- The document type Q1 is specified as ‘revenue’ related (transaction type ‘RV’.) During online update
of the ML it will update two logical columns, the revenue (‘RV’) and the Gross Margin (‘GP’) ones.
Both columns will be updated by value only (‘V’) using the function module code ‘11’, which should
be included in table J_1GVL_WHB007.
- Document type KR is simply denoted valid for Purchases but its logical WHB column is not
determined here. This has been chosen so that different accounts posted in documents of that type
will update different columns (for example: ‘PU’ and ‘GR’, see also the notes below).
- Movement type 101 B is denoted as ‘purchases-relevant’ and updates only one column (‘PU’) by
quantity. We expect that the value of purchases will be supplied from the accounting documents of
the Goods Receipt and the Invoice Verification. Since this is an input movement to the valuation
equation it is not updated after valuation (the post-valuation ‘val. WHB’ field is left blank)!
SAP Hellas
Page 19 of 40
21/6/2012
VALUATION APPLICATION: TECHNICAL DESIGN DOCUMENT
-
-
Movement type 601 LV is denoted as ’cost of sales-relevant’. During online update of the ML it
updates the ‘SL’ logical column by quantity only. After valuation the corresponding value field
(J_1GVL_ML-VLSL_VA) will be updated using the ‘consumption’ price (‘CO’) of the relevant material,
i.e.: J _ 1GVL _ ML VLSL _ VA priceCO J _ 1GVL _ ML VLSL _ QS .
Also, after valuation the same value will be assigned to the Gross Profit column ‘GP’. Since ‘SL’
quantities are by nature negative and the revenue documents (which are by nature ‘negative’) are
posted with reverse sign (se Q1 document above and function module ‘11’) the net balance of the
‘GP’ column will show the gross profit as required.
Movement type 101 B X is a special movement because in SAP MM involves a single line item
without values. In the WHB we update two quantity columns for this movement with opposite signs.
Run the tool "check customizing" to check your entries (there are some on-line checks performed as
well).
Notes:
While maintaining the valid accounts/cost elements table please note the following:
In the case of an ‘account-type’ entry maintenance of the transaction category and the column
algorithm is required only if you want to override the customizing of the document type, ie valid
accounts customizing has precedence over valid document types.
In the case of a valid cost element the format is simply XX (w/o B and NN). In the original versions no
more than one column were allowed. In the new version with CO documents been inserted directly
into the ML this restriction has been removed..
7.9
Valid Accounts and Cost Elements (table J_1GVL_WHB004)
This table serves two purposes: it defines the valid accounts (for filtering FI documents) and the valid
cost elements (for filtering CO documents). The relevant fields are:
Company Code
Chart of accounts
Controlling area (cost elements only)
Valid GL account (FI documents only, wildcard allowed).
Valid Cost Element (CO documents only, no wildcard allowed yet).
Warehouse Book code (recall that a single line item may appear in more than one lines in the ML for
various WHB codes
Transaction category: fill only if the default is to be overridden the default is set upon document type
customizing).
Column algorithm: for accounts fill only if the default is to be overridden the default is set upon
document type customizing); for cost element filling the WHB column is obligatory.
7.10
Warehouse Books Layout (table J_1GVL_WHB006)
Defines the layout of the WHB (that is the way it will appear on screen/in print). The fields are:
Warehouse book code (defined in J_1GVL_WHB001).
Logical WHB column
Offset for printing of the Logical WHB column. Each offset implicitly defines a physical WHB column.
SAP Hellas
Page 20 of 40
21/6/2012
VALUATION APPLICATION: TECHNICAL DESIGN DOCUMENT
English texts for the Physical WHB column (2 lines).
Greek texts for the Physical WHB column (2 lines).
Note the N:1 relation between logical and physical columns (e.g. for offset 191 where logical columns CO
and OE are mapped).
7.11
Function Modules (table J_1GVL_WHB007)
In this table the function modules used to determine values for the ML update are defined. At the
minimum this table should contain:
a function module for assigning the BSEG value (e.g. for purchasing invoices): here ‘1’.
a function module for assigning the BSEG value with reverse sign (here ‘11’). This makes sense for
accounts for which we want to show their values with opposite sign than their ‘natural’ one like the
GR/IR account and the revenue accounts.
Custom defined function modules can be defined provided they respect the interface structure of the
default ones.
7.12
Analytical Ledger postings (table J_1GVL_WHB013)
This table contains the account assignment for AL postings. The relevant fields are:
Company code
Plant (added in new versions, wildcard allowed)
Valuation type (only if split valuation active)
Material Type (wildcard allowed)
Valuation Class ((wildcard allowed)
Debit AL account
Credit AL account
Posting frequency. Allowed values:
o M Every Valuation Period (Month/Trimester)
o L
Only Last Valuation of Fiscal Year
o A Only First Valuation of Fiscal Year
o C Custom (implement as a function module validation)
Posting Date Mode. Allowed values:
SAP Hellas
Page 21 of 40
21/6/2012
VALUATION APPLICATION: TECHNICAL DESIGN DOCUMENT
o ‘ ‘ Post on current period (default)
o ‘1’
Post on 1st date of next period.
Function Module Number for validating the line item: used to activate custom validations. The
function module should be defined in table J_1GVL_WHB007.
In the new version user exits have been added in the A/L postings program that allow to define customerspecific function modules that implement edit masks in the account customizing. For example a record
with plant = 0XXX, valuation class = 2X++ and credit account = 942C0XXX00 can be interpreted to
replace 0XXX with the plant number and 2C with the first two digits of the valuation class into the account
number (function module event ‘ALACC’ in table J_1GVL_WHB020).
7.13
CO reposting settings (table J_1GVL_WHB014)
Used for CO re-postings. Fields are:
Sender Order
Receiver Order
Screen Variant for transaction KB11
7.14
FI reposting Settings (table J_1GVL_WHB015)
Used for FI re-postings. Fields are:
Valuation area (wildcards allowed)
Valuation class (wildcards allowed)
Debit General ledger account (usually a P+L account in the 2x9 range).
Credit General ledger account (typically a 2x9 Balance Sheet account).
7.15
Orders relevant for Work in Progress (table J_1GVL_WHB017)
Defines orders relevant for WIP. Fields are:
Fiscal year
Fiscal period
Order Number
WIP Indicator
The table can be populated using the ‘find WIP orders’ utility. Only orders marked as ‘WIP indicator’ = ‘X’
will be taken into account.
7.16
Customer Enhancements (table J_1GVL_WHB020)
This client independent table contains some default functions/subroutines that are called in predefined
places in the application. The customer may substitute these default functions with his/her own provided
the interfacing is respected. This table may be updated periodically to include more functionality or to
substitute some functions with more recent (and hopefully better performing) ones! Currently it includes
the following entries:
SAP Hellas
Page 22 of 40
21/6/2012
VALUATION APPLICATION: TECHNICAL DESIGN DOCUMENT
The object type field has as possible values:
‘F’
Function Module
‘P’
Program
‘R’
Form (routine)
Examples:
If one wants to update the ML in a somehow different way than the default then OBJ_NAME field in
the ‘FORMS’ entry must be changed. The new entry must be a program (‘P’) of the same type as the
default J_1GVL_WHB_FORMS (i.e., an ‘executable’ program). The MM and RWIN user exits of the
applications as well as the offline update program will detect such a change dynamically and execute
the new customer program instead.
In some companies where all materials are valuated but their number is large it makes sense to use
a different function module (in record ‘VALMAT’) to identify the ‘valid materials’ which will rely on just
table MBEW rather than the default function J_1GVL_VALMAT3 (which assumes that there may be
non-valuated ones also so it accesses both MBEW and MARA). Even in the standard case the
original default function was J_1GVL_VALMAT, which has now been replaced with
J_1GVL_VALMAT3 for performance reasons.
During printing of the WHB the 3rd party (‘LOCAT’, customer or vendor) field may require some
special algorithm to be identified. The default one is supplied in the ‘LOCAT_MM’ and ‘LOCAT_RW’
entries for MM and FI documents, respectively but can easily be modified with a customer-defined
function module (‘F’-type record!).
In order to reduce the number of records in the A/L customizing table one may define user-defined
edit masks using entry ‘ALACC’.
8
Customer-Specific Enhancements
Please consult also note 1138580 for latest developments regarding the enhancement techniques used.
The application supports two types of enhancements:
8.1
Default functions/forms
These are places in the application where default function modules or routines are called are defined in
the client-independent table J_1GVL_WHB020 as explained above.
8.2
Predefined forms (delivered empty)
There exist predefined positions in the applicatins where customer-specific forms can be executed.
8.2.1
Valuation program (J_1GVL_VL)
Such forms in the valuation program must be edited in the customer-include program defined in the
global settings. Such forms are:
Upon ‘INITIALIZATION’
form ‘CUST_INIT’.
Upon ‘SELECTION-SCREEN’ checks
form ‘CUST_SEL_SCR_CHECK’. Here additional
(customer-defined) checks on the selection-screen fields may be added.
SAP Hellas
Page 23 of 40
21/6/2012
VALUATION APPLICATION: TECHNICAL DESIGN DOCUMENT
Upon ‘SELECTION-SCREEN-OUTPUT’
form ‘CUST_SEL_SCR_OUTPUT’. This can be used
for deactivating some selection-screen fields, for example if the company does not use FIFO all
FIFO/LIFO options can be deactivated.
During accessing of the ML
form ‘CUSTOMER_FUNCTION’. Here customer-defined internal
tables may be filled.
Upon ‘START-OF-SELECTION’
form ‘CUST_START’.
8.2.2
A/L postings program (J_1GVL_ALPOST_DI)
There exist predefined positions in the A/L postings program where customer-specific forms can be
executed. They must be edited directly in the (by default empty) include program J_1GVL_ALPOST_CI
(no generating mechanism like in the Valuation program has been devised here). Actually it is
preferable that all such forms are edited in a customer range include program (say YALFORMS) and
then a single line ‘INCLUDE YALFORMS’ is inserted in J_1GVL_ALPOST_CI to facilitate handling upon
upgrades. Such forms are:
Upon ‘INITIALIZATION’
form ‘CUSTOMER_EXIT_INIT’.
Upon ‘SELECTION-SCREEN’ checks
form ‘CUSTOMER_EXIT_SELSCR’. Here additional
(customer-defined) checks on the selection-screen fields may be added.
During data access from tables J_1GVL_WHB010 and J_1GVL_WHB011:
o Form ‘CUSTOMER_EXIT_READ10A’. Here data to be read are filtered.
o Form ‘CUSTOMER_EXIT_READ10B’. Here additional extracts to the field group can be
effected.
During formation of posting details
form ’CUST_SET_BSEG’. Here for example one may set
the business area (T_BBSEG-GSBER) or the segment text (T_BBSEG-SGTXT).
9
Legacy System Migration
It is strongly recommended to migrate to this application at the beginning of the fiscal year. In this case all
that is needed from the migration point of view are the initial stock data that must be inserted in tables
J_1GVL_WHB011 (with posting date = last day of ending fiscal year for valuation) and J_1GVL_WHBPOL
(with fiscal year = the starting fiscal year and period = ‘00’ for the WHB). Migration during the fiscal year
entails that all transaction categories and all logical columns must be inserted in tables J_1GVL_WHB010,
…011 and …POL and, for year-to-date valuation, all line items for the previous periods of the fiscal year
must be inserted in the ML as well. This is a difficult operation (reconciliation between the J_1GVL_WHB*
tables and consistency with the legacy systems legal Warehouse Books is at stake) and, although some
customers have implemented it (mainly multinational companies forced to do so by the parent company) it
should de avoided - if possible. The following notes assume a migration at the fiscal year change.
9.1
Application is activated together with SAP R/3 going live
In this case initial stock is uploaded from the legacy system using 561, 562 movements. These
movements create MM items in the ML (usually under transaction category ‘IS’). Then the ‘Upload Initial
Stock’ program (see tools
transaction J1GVL_T01) will read these ML records and populate the
J_1GVL_WHB011 and J_1GVL_WHBPOL tables accordingly. The corresponding values can be
uploaded either via the 561,2 movements if they are parameterized with ‘Q’ and ‘V’ in table
J_1GVL_WHB005 but it is also possible (and more often used) to use 561, 2 movements for quantities
only and upload values from FI documents (in which case RW line items from the ML will be customized
with transaction category = ‘IS’). In either case run ‘Upload initial stock’ afterwards!
SAP Hellas
Page 24 of 40
21/6/2012
VALUATION APPLICATION: TECHNICAL DESIGN DOCUMENT
9.2
Application is activated in a live R/3 system
In that case initial stock data must be retrieved from the legacy system’s Inventory Book of the ending
fiscal year. The corresponding ABAP program (that must be developed!) will then either insert directly the
data into the J_1GVL_WHB011 and 1GVL_WHBPOL tables or insert the data as line items in the ML in
which case the ‘Upload Initial Stock’ utility will be used as above to transfer them to the WHB tables.
10
Monthly Operations
10.1
Material Valuation (for CO reposting)
See accompanying user manual.
10.2
Material Valuation proper
See accompanying user manual.
10.3
Warehouse Book(s)
See accompanying user manual.
10.4
Analytical Ledger Postings
See accompanying user manual.
10.5
Resetting the application runs
See accompanying user manual.
11
Year-end-closing Operations
11.1
Devaluation and minimum price selection
See accompanying user manual.
11.2
Inventory Book and Carrying forward to next fiscal year
See accompanying user manual.
SAP Hellas
Page 25 of 40
21/6/2012
VALUATION APPLICATION: TECHNICAL DESIGN DOCUMENT
12
Reporting
12.1
Reports executable prior to monthly operations
12.1.1 Purchases Report
See accompanying user manual.
12.1.2 Sales Report
See accompanying user manual.
12.1.3 Production Expenses Report
See accompanying user manual.
12.1.4 Transportation Costs Report
See accompanying user manual.
12.2
Reports executable following run of monthly operations
12.2.1 Valuation Data (compact version)
See accompanying user manual.
12.2.2 Valuation Results (detailed version)
See accompanying user manual.
12.2.3 Stock comparison report
See accompanying user manual.
12.2.4 Analytical Ledger Postings check report
See accompanying user manual.
12.3
Ad hoc reporting
The design of both the ML table and the tables that store valuation results allow easy design of custom
made reports.
13
Technical Details: Material Ledger
In this section we describe in some detail the structure and functional logic of the Material Ledger (ML).
13.1
Material Ledger Fields
The ML fields can be grouped in three categories:
Key fields: The key field structure of the ML is reminiscent of typical LIS structures (in fact the ML is
an LIS table in release 40B of Greek Localization). The key fields are:
VRSIO
Version: currently used versions include: DET (line items), SUM (day totals,
activated in ‘global settings’), COL (period totals for adjustment computation,
installed only in January 2003 version of the application)
SPTAG
WHBCODE
BUKRS
BELNR
DET and SUM versions: posting date. COL version: last day of fiscal period
Warehouse Book Code
Company Code
DET version: original document number (MM/RW/CO). SUM version: blank.
COL version: PERIOD: XX, where XX = period
BUZEI
WERKS
DET version: Line item. SUM version: blank. COL version: period.
Plant
LOCAT
This field in Greek Localization denotes 3 party (customer/vendor) location
SAP Hellas
rd
Page 26 of 40
21/6/2012
VALUATION APPLICATION: TECHNICAL DESIGN DOCUMENT
MATNR
BWTAR
ORGN
Material number
Valuation type
Record origin: MM for material documents, RW for accounting documents, CO
for CO documents (>= January 2003 version of the application)
Note that the behavior of some fields depends on the version of the ML.
Logical Column Fields: these are the multiplets of {VLXX_QS, VLXX_VS, VLXX_VA} fields that
correspond to the logical WHB columns XX.
Other information Fields: the rest of the fields supply additional information (transaction category,
movement, partner details, order details, account etc.).
Note that additional fields can be appended to the ML at will so that they maybe used by customerenhanced valuation methods or to identify new logical columns (that are automatically recognized by the
WHB program).
13.2
Material Ledger Versions
The version field of the ML requires some detailed exposition.
DET version
This is the default (and in most cases the only one used) version. DET stands for ‘detail’ and signifies
that the line items of MM, FI, CO documents are inserted ‘as-is’, i.e., without any summarization in the
ML. The only tricky point is that for FI documents the BELNR field contains the ‘original document’ and
not the actual ‘accounting document’. Note that the item field (BUZEI) is not referenced as the 3-digit FI
line item but as the ACCIT item field as used in the RWIN interface. In this way it covers both the MM and
CO line item number ‘length’. For time-dependent number ranges the date (SPTAG) field allows insertion
of same document number in different years without a problem. The material, plant, valuation type and
3rd party location fields are not required as key fields in the DET version (each line item is supposed to
correspond to one and only one combination of these fields). These fields can be viewed as a
‘generalized material key’ and are constructed as key fields for the ‘SUM’ and ‘COL’ versions where the
BELNR & BUZEI fields are dummy.
SUM version
This version allows one to create cumulative totals per posting date (SPTAG) and the ‘generalized
material key’ for the MM items in the ML only. Forming such totals for each material movement allows to
identify and prevent material movements that at that CPU time do not lead to negative stock but under
‘favorable’ circumstances might result in a negative stock for some posting date in the past. Example:
Say that Stock for Material ‘X’ in plant ‘A’ is:
Posting date
Stock
August 1, 2000
10 PC
August 8, 2000
100 PC (goods receipt of 90 PC on August 8)
Then on August 9 a goods issue for 70 PC with posting date = August 2 is allowed with respect to both
SAP and Greek Localization. However, if the posting date is before August 8 (say August 5) then Sapwise the movement is allowed but with respect to Localization it will result to negative stock = -60 PC in
the WHB between August 5 and August 7. The SUM version updates posting date totals for all posting
days between the document postings date and the current system date and if negative stock is detected
for any of these days the MM movement is not allowed.
Preventing negative stock with the SUM version has 2 (interrelated) shortcomings:
The algorithm for updating past days is understandably slowing down the performance of the
transaction especially when it is taken into account that the check and the corresponding ‘ABEND’
are performed during the MM document ‘save’ user exit MB_CF001 which is on the update task.
Thus,
Upon an error the transaction is aborted without giving the user the option to enter a smaller goods
issue quantity so that no negative stock is found.
For these reasons it is recommended not to activate the SUM version in the global settings but instead
activate a similar mechanism during the MM user exit MBCF0002 (Customer function exit: Segment text
in material doc. Item) that will perform all customizing checks for ML updating but update a different table
with a simpler key structure (posting date + generalized material key). This solution has been
SAP Hellas
Page 27 of 40
21/6/2012
VALUATION APPLICATION: TECHNICAL DESIGN DOCUMENT
implemented at some customers but has not been included as part of the Greek Localization proper yet.
(See also comments at the ‘global settings’ customizing).
COL version
This version makes sense primarily in the case of year-to-date or trimester-to-date valuation. It has
period totals for each logical column and for every ‘generalized material key’ (MATNR+ WERKS +
BWTAR + LOCAT). The purpose of this version is to provide comprehensive information of the totals per
period, material, plant, valuation type and 3rd party that will be used by the WHB program in order to
compute without performance costs the adjustment of the carried forward totals for each period. To
achieve this, the COL version fields are updated in the following manner:
SPTAG
has the last date of the period of the original posting date (e.g. all days in March 2003 are
saved under 31/3/2003).
BELNR
has the format ‘PERIOD: N’ where N = the period when the valuation runs.
BUZEI
N where N = the period when the valuation runs.
All other alphanumeric fields are cleared (e.g. origin, transaction category, account…) to allow
forming only 1 line per ‘generalized material key’.
In this way each MM line item with post-valuation update in the customizing that has a DET version will
be revaluated 13 minus N times. For illustration, an August line item with posting date 12-Aug will
contribute to the following 5 COL version entries:
SPTAG
BELNR
BUZEI
31/08
PERIOD: 08
00008
31/08
PERIOD: 09
00009
31/08
PERIOD: 10
00010
31/08
PERIOD: 11
00011
31/08
PERIOD: 12
00012
For example the 3rd line in the table above will give us the total value of the August movements for this
material plant etc valuated during the run of the October year-to-date valuation. Thus, if one wants to
print the WHB of November then the 10 line items in the COL version from January up to and including
October with BELNR/BUZEI = ‘PERIOD: 10’/’10’ will (after summation) give the correct October totals
carried forward to November according to the November valuation; these must ‘adjust’ the October totals
saved after the run of the October WHB in the J_1GVL_WHBPOL table (which were computed using
October year-to-date prices).
Note that this means that for each ‘generalized material key’ there will be 12+11+…+1 = 12(12+1)/2 = 78
line items per year. Thus for companies with large number of material movements the COL version will
not be a problem in terms of data size, but in companies with a large number of materials that have few
movements in a period the COL version can be of size comparable to the DET version.
9
The COL version is first refreshed and then created during the non-test valuation run, when ML records
are read in the ‘READ ONLINE WHB’ form; then an internal table is formed:
For origin = MM records the quantity and all actual values are stored (in most cases the values are
irrelevant because they will be recomputed by the valuation procedure; possible exceptions are
transaction categories like ‘OI’ with ‘own’ input value).
For origin = RW or CO all logical columns are processed and their values added.
In non-test mode this internal table is processed so that for MM movements the actual value of the
movement is computed. Then all records are collected to form the COL version.
Note: the COL version has totals per logical column and not per transaction category. In that respect it
resembles the WHB totals table J_1GVL_WHBPOL. It is very different from this table though in that it
contains data for each period more than one times - just because of the revaluation implicit in a year-todate valuation. The COL version will show some small rounding differences from the valuation totals
even for logical columns (like SL) which are usually in 1:1 correspondence with a transaction category,
because in the COL version we first sum over a month’s quantities and then multiply with the price
whereas in the valuation program we have only one such multiplication (total quantity over the whole
year-to-date period times price).
9
The COL version is not affected at all by the ‘Initialize production runs’ tool.
SAP Hellas
Page 28 of 40
21/6/2012
VALUATION APPLICATION: TECHNICAL DESIGN DOCUMENT
EXP version
Introduced with note 1135997 in order to store production expenses as they are apportioned to coproducts by the valuation program (provided that this type of valuation has been activated in ‘global
settings’). The data in EXP version are stored in a way similar with COL.
TOT version
This version is envisaged as a more detailed COL version (subtotals per transaction category). It can be
activated (default = ‘NO’) during the valuation program run. Not operational yet in any customer.
13.3
Revenue Documents and the ML
The problem
Revenue documents create problems in the offline update of the WHB solution because it is not
straightforward to map the BSEG line items (“FI view”) into the tables ACCIT/ACCCR (“accounting view”)
that is used in the ML update.
Normally, the offline update program reads BSEG and then invokes the function module “FI DOC TO
ACC TRANSFORM” that creates tables ACCIT/ACCCR, used to update ML. This function module
assigns line item numbers to ACCIT/ACCCR in ascending order (1,2,3…). This is problematic in the case
of revenue documents because during online update via RWIN the tables ACCIT/ACCCR (which have a
10-digit line item number POSNR) the revenue line items starting at 1000!
That means that the line-item number of ML during on-line and off-line update is NOT necessarily the
same and therefore if a revenue document has been inserted into ML online and for some reason we try
to insert it offline as well, ML will most likely contain it 2 times, one with line item > 1000 and one with a
line item < 999!
This problem is particularly obvious (but not confined to) if FI summarization is active, in which case one
line item of BSEG (without material) must be transformed to many line items of ML.
What to do
With the original form of the online update program the only safe practice is to delete the ML revenue
documents that have been inserted online before starting offline update.
An alternative method has been developed in the updated version of the offline update program (a radiobutton in the FI selection screen distinguishes between the two). The new method does not rely on BSEG
at all for revenue documents. Instead it re-creates the FI document directly in ACCIT/ACCCR form
starting from VBRP and KOMV. This is achieved by using the function module “RV ACCOUNTING
DOCUMENT CREATE”.
The good news is that the line item of ML will by definition be the same during either on- or off-line
update. Therefore option “Revenue from Billing doc.” is also compatible with online update of ML, unlike
the “Revenue from FI doc.” option, which is not.
The bad news is that most probably the offline update of revenue documents will be slower, as this
function calls AC DOCUMENT CREATE, which calls all the RWIN function modules. Also note that this
function performs all accounting checks (e.g. requires FI period to be open), and it’s not compatible with
cancellation of billing documents (in case of cancellations you should consider deleting the original
invoice from ML, instead of updating ML with the cancellation, or simply use the “Revenue from FI”
option).
The tricky point is that this function processes ACCIT/ACCCR but does not communicate them back to
the calling program. In order to access the contents of the internal tables we need an extra RWIN step in
which we export the contents of these tables to a memory id and import it back after the function module
has been executed. What to do:
1. Define an RWIN component, e.g., ZRV (table TRWCI) and activate it in TRWCA.
SAP Hellas
Page 29 of 40
21/6/2012
VALUATION APPLICATION: TECHNICAL DESIGN DOCUMENT
2. Use the function module J_1GVL_RV_PROJECT in RWIN. Edit table TRWPR and insert a line:
DOCUMENT PROJECT 910 ZRV SPACE J_1GVL_RV_PROJECT. The function module code
contains a single line:
EXPORT T_ACCHD T_ACCIT T_ACCCR TO MEMORY ID ‘RV_RWIN’.
13.4
MM-originating accounting documents and the ML
In some cases accounting documents with MM origin (reference procedure ‘MKPF’) have line items with
number different between the ML and the FI document (table BSEG). This happens because the original
MM document may contain ‘statistical’ items (field ACCTIT-KSTAT not blank), which are ‘passed over’ in
the accounting document. In order to avoid the possibility to insert these items twice if we try an offline
update without first deleting the period’s data from the ML, the offline update utility has been modified in
order to obtain the ‘proper’ line item number from table ACCTIT.
In case MKPF/RMRP summarization is active in the system, the update of tables ACCTHD, ACCTIT
should not be deactivated (as per SAP note 48009), as this would make the offline update of ML with
accounting documents from MM, impossible.
13.5
Updating the Material Ledger
The ML can be updated either online or offline. In either case the same forms are called in the program
specified in the ‘FORMS’ record of the customizing table J_1GVL_WHB020 (default
J_1GVL_WHB_FORMS).
13.5.1 Online update
To activate the online update the following is required:
Material (MM) documents
MM line items that are eligible for insertion into the ML are checked and inserted using the
MB_CF001 Customer function exit for ‘update of material document’ that is performed at the update
task of the MM movement.
If the exit is already in use (like above where it is used for the Greek Localization legal documents
’) the corresponding include program ZXMBCU01 will have been already created. If not,
create a project in transaction ‘CMOD’, add the MB_CF001 enhancement to it, double click at
ZXMBCU01 to create the program. In any case insert the following lines of code in ZXMBCU01:
IF NOT XMSEG[] IS INITIAL.
DATA: W_PROG LIKE SY-REPID.
READ TABLE XMSEG INDEX 1.
SELECT COUNT(*) FROM J_1GVL_WHB000 WHERE BUKRS = XMSEG-BUKRS.
IF SY-SUBRC = 0.
SELECT SINGLE OBJ_NAME FROM J_1GVL_WHB020 INTO W_PROG
WHERE BUKRS = XMSEG-BUKRS
AND
EVENT = 'FORMS'.
PERFORM WHB_ONLINE_MM IN PROGRAM (W_PROG)
TABLES XMKPF XMSEG
IF FOUND.
ENDIF.
ENDIF.
SAP Hellas
Page 30 of 40
21/6/2012
VALUATION APPLICATION: TECHNICAL DESIGN DOCUMENT
Accounting (FI) documents10
Accounting documents are inserted in the ML via the standard RWIN interface to accounting. The
required steps are:
Create an RWIN component, say ‘ZCLA’ in TRWCI (maintain via SM30)
Create entries in the (client-independent) table TRWPR as follows
Here the following must be noted:
o Transaction ‘BELEG’ refers to accounting document originating in FI (reference procedure
BKPF and BBKPF), whereas ‘DOCUMENT’ to accounting documents created from original
documents in other modules (examples: reference procedure MKPF for MM-originating
documents like goods receipts for order, VBRK for billing documents, RMRP for invoice
receipts etc.)
o The RWIN interface functions are performed in the dialog task, not in the update. During
‘PROJECT’ the line items are supplied by the interface and at the ‘POST’ the original
document’s number (I_AWREF) is supplied. The line items read during ‘PROJECT’ are
passed to internal tables of the function group J1G_WHB (Greek Localization - Material
valuation / Warehouse book) and further manipulated during ‘POST’.
o The PREREV record pertains to > 4.6 releases and is required to allow cancelled billing
documents to update online the ML (Just a trick: in this way we force the function RV
ACCOUNTING DOCUMENT CREATE to go through AC DOCUMENT CREATE and thus
rebuild table ACCIT, otherwise AC DOCUMENT REVERSE is called and branches directly
to AC DOCUMENT POST without ‘passing’ from the PROJECT phase: as a result ML
cannot be updated!)
o The actual update of the ML takes place by calling function J_1GVL_RWIN_UPDATE in the
update task.
Acivate the RWIN component in TRWCA table:
Controlling (CO) documents10
Online update of CO documents is now
in TRWPR are as follows:
TRANS
TIME
NO
K-BELEG
FERTIG 999
K-BELEG1
FERTIG 999
K-BELEG2
FERTIG 999
K-ABRECH
FERTIG 999
also possible using the RWIN interface. The relevant entries
COMPONENT
ZWHB
ZWHB
ZWHB
ZWHB
FUNCTION MODULE
J_1GVL_RWIN_CO
J_1GVL_RWIN_CO
J_1GVL_RWIN_CO
J_1GVL_RWIN_CO
10
From ERP (ECC) 6.0 onwards, you cannot define components from the customer namespace (Z*) directly
in RWIN tables (TRWCI, TRWPR, TRWCA). A workaround to this issue can be found in note 1278637.
SAP Hellas
Page 31 of 40
21/6/2012
VALUATION APPLICATION: TECHNICAL DESIGN DOCUMENT
13.5.2 Offline Update
Offline update is performed using the program ‘Offline update’ (J_1GVL_WHBT04). The program:
1. Reads MM, FI and (new versions: CO) line items
2. Maps them into a form (interface) same as the one required during online posting (that is, for FI
and CO documents transform into RWIN interface)
3. Performs a simulation of ML update if so requested (i.e., items is valid or not, has been inserted
already etc.)
4. Calls the same functions in the ‘master’ program (J_1GVL_WHB_FORMS or a customer substitute,
see above) as the online update.
Already inserted
Awaiting insertion
Does not ‘pass’
customizing test
Document saved in ML under reference
doc (if SD FI or MM FI)
13.5.3 MM data
MM line items from MSEG are checked as to whether they satisfy the customizing constraints in the
form ‘WHB_ONLINE_MM’. As the form is already called in the update task the ‘valid’ data are simply
inserted in the ML without further ado.
13.5.4 FI data
FI line items pose a more complicated problem because they do not always have in BSEG the
required information (material + plant). Thus, FI documents are read from two sources:
1. Either directly from BSEG (option “Revenue from FI doc.”).
2. From other ‘original’ sources (option “Revenue from billing doc.”). This is required in case of
ambiguity in the line item number (e.g. billing documents, MKPF document line items is read from
ACCTIT), but it is generally not recommended (see also RV documents).
Currently the application supports the RMRP (note 1044342 required) and VBRK summarization
procedures and the RM-CA industry solution.
In case of SD documents having more than one documents in accounting, option “Support for SD
docs w/ many FI” of the program’s selection screen must be used (notes 1044150 and 1140218 are
required).
The retrieved line items are mapped to RWIN interface. They are then checked as to whether they
satisfy the customizing constraints in the form ‘WHB_RWIN_POST’ and finally posted using the
J_1GVL_RWIN_UPDATE function module.
Note: FI documents are saved in the ML under the original document number!
13.5.5 CO data
Data are retrieved from data base view J_1GVL_COVP and then mapped to RWIN interface.
Following that they are checked as to whether they satisfy the customizing constraints in the form
‘WHB_ONLINE_CO’ and finally posted using the J_1GVL_RWIN_UPDATE function module.
SAP Hellas
Page 32 of 40
21/6/2012
VALUATION APPLICATION: TECHNICAL DESIGN DOCUMENT
14
Technical Details: Valuation
The valuation program is the most complicated component of the application. In the following the logic of the
program is sketched. For more details the reader is referred to the Appendix 1. The program performs the
following steps:
1. Read basic settings and customizing tables.
2. Determine the date range (based on valuation horizon).
3. Call the function for determining the valid materials (records ‘VALMAT’ in the customer-enhancements
table m default ‘J_1GVL_VALMAT3’).
4. Get the WIP orders (if applicable)
all
Dates/depth
Access
ML
WHB codes
materials
TBL_TRANS
TBL_PURCH
PU
TBL_ANALP
TBL_INTR
T2
TBL_PROD
TBL_OIMP
TBL_COST
More ...
CP
SP
PD
Access
COEP
AE, EE, PC
??
Key concept: transaction category.
•Some hard-coded, used to fill designated tables.
• Can define more ‘consumption’ w/o changing program.
•For additional functionality program must be changed, though.
5. Accesses the ML. Depending on the transaction category several internal tables are filled (see Appendix
1). If the customer enhancement is activated additional internal tables can be filled for special purposes
in the ‘CUSTOMER_FUNCTION’ form.
a. Example 1: a customer wants to have FIFO on the subcontracting orders. Then in the
‘CUSTOMER_FUNCTION’ one may fill an internal table ‘PROD_BY_DATE’:
FORM CUSTOMER_FUNCTION.
* FILL ASSEMBLY + FACON DATA FOR FIFO.
IF J_1GVL_ML-TRACT = 'PD' .
CLEAR PROD_BY_DATE.
PROD_BY_DATE-EBELN = J_1GVL_ML-EBELN.
PROD_BY_DATE-EBELP = J_1GVL_ML-EBELP.
PROD_BY_DATE-MATNR = J_1GVL_ML-MATNR.
PROD_BY_DATE-BWTAR = J_1GVL_ML-BWTAR.
PROD_BY_DATE-BUDAT = J_1GVL_ML-BUDAT.
PROD_BY_DATE-MENGE = W_MENGE.
PROD_BY_DATE-DMBTR = W_DMBTR.
PROD_BY_DATE-ORGN = J_1GVL_ML-ORGN.
COLLECT PROD_BY_DATE.
ENDIF.
ENDFORM.
b. Example 2: a customer wants to have some FI documents posting to expense accounts 64*
contributing as a separate input factor to the valuation program (‘transport expenses’). Then a
special transaction category ‘LC’ is created to label these items and in the
‘CUSTOMER_FUNCTION’ one may fill an internal table ‘TINX’ as follows:
FORM CUSTOMER_FUNCTION.
IF J_1GVL_ML-TRACT = 'LC'.
CLEAR TINX.
TINX-MATNR = J_1GVL_ML-MATNR.
TINX-WERKS = THE_WERKS.
“<- Valuation @ plant level!
TINX-BWTAR = J_1GVL_ML-BWTAR.
TINX-MENGE = J_1GVL_ML-MENGE.
TINX-DMBTR = J_1GVL_ML-VLLC_VA.
“<- New Logical WHB Column!
COLLECT TINX.
ENDIF.
SAP Hellas
Page 33 of 40
21/6/2012
VALUATION APPLICATION: TECHNICAL DESIGN DOCUMENT
6. Old versions: CO documents are accessed to determine production expenses (obsolete step in new
versions).
7. Get initial stock from J_1GVL_WHB011.
8. If requested, get SAP stock (by submitting the stock report J_1GVL_WHBT14 and retrieving the data via
memory). Will be used to compare with the remaining stock quantity during the valuation.
9. Then the valuation iteration starts as depicted below. The internal table TBL_TRANS contains all the
materials found with either initial stock or movements during the period that must therefore be
processed.
yes
Tbl_trans
no
yes
empty?
Progress
made?
Repost mode?
no
yes
no
yes
Store val.
data in DB
Do FI/CO
repostings
Output
results
Cyclic on?
no
Switch on
cyclic valuation
Construct
irreducible sets
Solve linear
system (WMA)
List failures
end
Get TBL… for next
material/call method
Read components
(TBL_ANALP)
no
components
valuated?
yes
Valuate
material
Prepare save
(TBL_VAL)
Delete
Tbl_trans
The program attempts to valuated each material in TBL_TRANS according to the method proper for this
material type and valuation class. A material is valuated only if all its ‘components’ have already been
valuated. Here ‘component’ is used in the generic sense of direct material components from order
production (stored in internal table TBL_ANALP as shown in the diagram below), assembly or material
transfer (internal table TBL_OIDT) as well as plant transfer in the case of plant level valuation (internal
table TBL_INTR). If the material is successfully valuated the corresponding record is deleted from
TBL_TRANS. Thus, the valuation is completed when TBL_TRANS contains no entries.
10. Data for the already valuated materials are stored in two internal tables:
a. TBL_VAL (all prices and totals per transaction category).
b. TABPR (new versions only). This is a ‘sorted’ type table in which all the consumption prices are
stored. This table is very crucial because it is by checking the records of this table that the decision
is made as to whether a material has all its components valuated already and therefore can be
11
further processed.
11. If the program detects that ‘no progress is made’, that is, the number of yet not valuated materials in
TBL_TRANS is not diminishing then this is interpreted as an indication that the remaining materials have
‘coupled’ valuation equations, that is, cyclic production or cyclic transfers. In this case the remaining
materials are processed by the cyclic production routine:
a. They are grouped in irreducible sets (for details see: Cyclic Valuation Documentation (in
Greek)).
b. Each set is processed by according to the selection screen ‘cyclic valuation’ method. Currently
supported methods are:
i. (L)
Linear System solver. This is an exact method; it uses the Gauss Jordan
algorithm. So far applicable to WMA and WMAPL methods only. Note that in principle
the method may lead to negative prices for some materials. The program has been
carefully designed to single out linear systems that have a zero determinant and cannot
be solved. If however such a system forgoes the detection mechanism and is fed to the
Gauss Jordan solver a message ‘Singular Matrix in Gauss Jordan set XXX:’ will indicate
that a linear system with vanishing determinant was identified. All cases encountered so
far where such a message occurred where cases where at least one of the materials
11
In the original versions the corresponding entry in TBL_VAL was checked (with document category ‘CO’)
but this leads to performance problems.
SAP Hellas
Page 34 of 40
21/6/2012
VALUATION APPLICATION: TECHNICAL DESIGN DOCUMENT
included in the set was leading to negative remaining stock quantity. In such a case the
negative stock problem must be first dealt with and then the valuation repeated.
ii. (I)
Iteration. This is an approximation rather than an exact method but it can be
applied to all valuation methods. The approximation takes as starting value the SAP
prices or the previous period’s values. In some rare cases it may fail to converge after
the current limit of 100 steps. Note also that in background processing the spool request
contains a ‘printout’ of all iterations during the application of the method.
iii. (C)
Customer defined method. Use this for creating a variant of the cyclic valuation
methods, for example to write down a variant for cyclic that will take WIP into account.
Prerequisite: the customer-include program in the global settings must have been
activated. Write your ABAP code for a function ‘CUSTOMER_CYCLIC’ in this include
program.
12. In non-test mode the following take place:
a. Data from the internal tables are stored in J_1GVL_WHB011 and J_1GVL_WHB010.
b. The last period’s MM movements in the ML are updated with the valuation prices. Note: for a
valuation run for period N only the dates (field SPTAG in the ML) belonging to period N will be
updated. In particular that means that in the case of year-to-date valuation the movements of
periods 1 to (N-1) will not be updated according to the new prices. This looks awkward at first
sight but it has been so designed in order to allow reprinting of the Warehouse Book (which
reads these DET version lines) without producing different results from its legal run! For
example, if we have printed the WHB for February and we perform the year-to-date valuation of
March, April, May etc we do not update each time the February DET line items in the ML
because we want to re-run the WHB of February and get the same results as when we first run
it and we stored it as a legal book (i.e., with February prices).
c. Although the DET lines are not re-updated for past periods the COL version is updated for the
whole valuation horizon (that is, periods 1 to N in the year-to-date case), or, to be more precise,
new line items for each period are created with BUZEI = N (see CO: version design above).
d. The valuation control table J_1GCONTROL is updated for the current fiscal year and program (field
ALLGBMON contains the last valuation run period N).
13. Finally a summary report is displayed with totals per valuation method and material type.
15
Technical Details: Warehouse Book
The Warehouse book program J_1GVL_WHB_POLY is basically a report on the DET version of the ML. The
only tricky points pertaining to this program are:
The same program serves as both Trial Balance (
) and Analytical Ledger (
). The only
difference is that in the main printing routine ‘WRITE_WHB_SORTED_BY_PLANT’ the subroutine
‘WRITE_ONE_Q_AND_ONE_V_LINE’ is only executed in ‘analytical ledger’ mode.
Each record (be it a line item in analytical ledger mode or one of the totals lines in the trial balance
mode) occupies two lines in the printout, one for quantities and one for values. Exceptions: Some
records that involve no quantities at all (like adjusted carried forward totals or rounding adjustment lines)
have of course only one line – the ‘value’ line.
In the case of materials without value update or plants without value update or WHB codes without
values update (see the customizing section) the corresponding value lines are omitted in the printout.
Repeated use is made in the code of processing the logical WHB columns using field symbols. This is
done in order to allow:
o A dynamically defined layout (see WHB layout customizing).
o New logical WHB columns appended to the J_1GVL_ML and the J_1GVL_WHBPOL tables to be
seamlessly integrated (the field-group fields are dynamically defined during initialisation.)
The following code excerpt from the routine ‘WRITE_TOTALS‘ that prints the totals lines in the Trial
Balance part of the code exemplifies this situation:
LOOP AT I_OFFSET.
W_COL = I_OFFSET-WHBCOLUMN.
AT NEW WHBOFFSET. CLEAR W_DMBTR.ENDAT.
CONCATENATE 'TTT-VL' I_OFFSET-WHBCOLUMN '_VA' INTO MY_FIELD.
ASSIGN (MY_FIELD) TO <F>.
IF SY-SUBRC = 0.
READ TABLE MY_NAMETAB WITH KEY FIELDNAME = MY_FIELD+4 BINARY SEARCH.
IF SY-SUBRC = 0. ADD <F> TO W_DMBTR. ENDIF.
ENDIF.
AT END OF WHBOFFSET.
WRITE AT I_OFFSET-WHBOFFSET(LENGTH_V) W_DMBTR CURRENCY SS-WAERS.
NDAT.
SAP Hellas
Page 35 of 40
21/6/2012
VALUATION APPLICATION: TECHNICAL DESIGN DOCUMENT
ENDLOOP.
Although the remaining stock quantity is computed as initial stock + quantity involved in each line, the
remaining stock value is computed at the end (and not per line) as quantity x remaining stock price
(found from valuation table J_1GVL_WHB011). An exception is WHB codes labelled as ‘S’ (SAP price),
in which case the remaining stock value is computed per line as previous movement (or carried forward)
stock value plus/minus the current movement’s value. Care must be taken in this case for columns like
Revenue or Gross Profit that do not contribute to the valuation equation and should therefore not
contribute to the update of the remaining stock value either.
The Warehouse book must reflect the valuation results at least insofar as the cumulative year-to-date
totals are concerned. Thus, code is required to handle two issues:
o Adjustment of the carried forward totals from the previous period according to the new valuation
(valuation horizon <> month only) These adjustments are performed by comparing the carried
forward totals (by summing results from period 1 to N-1 in table J1GVL_WHBPOL where N = current
period) to the ‘COL’ version totals in the ML. They are shown for each level in the hierarchy of the
printout (see below), that is, we have material-level adjusted totals, 3rd-party level adjusted totals etc.
o Compute and show residual rounding errors. These are computed by comparison with the valuation
results in table J_1GVL_WHB010. In the case of year-to-date valuation the results of the current and
the previous periods in J_1GVL_WHB010 are subtracted in order to produce the ‘net’ result of the
period. Rounding errors are shown cumulatively (and not per material) either just prior to printing the
company totals (company code level valuation) or per plant prior to the plant totals just prior to
printing each plant’s totals (plant level valuation).
It is only after handling both of these ‘adjustments’ that a comparison with the valuation results is
complete.
Although the program has a freely defined horizontal structure (see physical WHB columns and layout
customizing) its vertical hierarchy is predefined: the program uses a ‘plant’ type sorting, that is the
results are shown in the following hierarchy:
Company Code
Plant
Third Party
Material and valuation type (one composite level).
Each hierarchy level involves totals for:
o Previous periods (carried-forward from previous periods).
o Adjusted previous periods totals (only WHB codes with value update and only for valuation horizon
not equal to month).
o Current Period Totals.
o Cumulative Totals carried forward to the next period.
In official mode the program:
o Stores the period data in table J_1GVL_WHBPOL. To be precise the values saved for period N are
the period totals PN (saved with adjustment = space) plus the adjustment AN (saved with adjustment
= ‘A’, new versions only) to the carried forward results. This ensures that adding the
J_1GVL_WHBPOL data for periods 1 to N will (correctly) give the cumulative totals printed on the
WHB for period N. The rounding differences are stored as separate lines in J_1GVL_WHBPOL with
the adjustment flag = ‘R’ (old versions ‘X’, for company code valuation these records have plant =
space).
o Inserts a new record in the WHB control table J_1GVL_WHB009.
16
Technical Details: Analytical Ledger Accounting
17
Technical Details: Year-End Closing (devaluation and inventory
book)
17.1
Requirements
The year-end closing solution for the WHB application must fulfill the following requirements:
During the last valuation of the year we must choose the minimum between the following prices for
the remaining stock:
o Historic cost (valuation) price
SAP Hellas
Page 36 of 40
21/6/2012
VALUATION APPLICATION: TECHNICAL DESIGN DOCUMENT
o Last purchasing price
o Last sales (revenue) price
o An ad-hoc price (revaluation/manual valuation)
Note that selecting any price different from the historic cost one entails a value DV by which the
valuation equation is violated.
The movements in the WHB must use the original ‘consumption’ price determined during valuation.
Since we must also show the DV value so we will add a new “plant” in the WHB layout for “price
differences during year-end-closing”, much like the case of rounding adjustments. We must also
decide which other column to “credit” so that the equation is still satisfied.
The total stock value (RM+DV) must be shown as:
o Valuation total at last day of fiscal year (e.g. 31/12)
o WHB total in J_1GVL_WHBPOL table for period 12 of current fiscal
o WHB total in J_1GVL_WHBPOL table for period 00 of next fiscal
The whole historic cost valuation remaining stock value must be transferred to the next fiscal year’s
WHB without any residual rounding errors.
17.2
Solution
Value differences resulting from choosing minimum price are stored under document category RM
and transaction category DV.
Valuation program reads as initial stock both valuation (VL) and “devaluation” (DV) RM document
category records of table J_1GVL_WHB011.
New program for “devaluation” (J_1GVL_WHBT10).
By default the program will not attempt to identify last sales or purchases price but will assume that
an ad-hoc devaluation is to be made. Although the program contains some sample routines for
determining the most recent sales or purchase price from ‘RV’ and ‘PU’ records in J_1GVL_WHB11 we
do not recommend to use this feature for two reasons:
o The corresponding operation is time-consuming
o In most cases the customer wants anyway to supply his/her own rule of what should the historic
cost price be compared with.
For these reasons the program allows to use event ‘PURVPR' in the customer-enhancements table
to identify a Z… program where customer-specific routines for getting last sales and purchases price
can be supplied.
In the WHB:
o Print remaining stock prices as now (using RM only)
o Print adjustments and rounding errors as usual.
o After adjustments and prior to company level totals print “devaluation” per material with values
under ‘RM’ and ‘DV’.
For statutory inventory book (program J_1GVL_INVB) we don’t use at all the (now obsolete) Greek
Localization table J_2GV.
When printing the Inventory Book we recalculate the remaining stock value per plant based on the
valuation results (essentially this allocates all RM rounding adjustments proportionally to each plant’s
rd
st
and 3 party’s RM quantity). Rounding errors are avoided by dumping any residual variance to the 1
plant with nonzero stock. That way we ensure the agreement between valuation and WHB. In nontest mode we transfer the stock quantities and values value to period 00 of the next fiscal year in
J_1GVL_WHBPOL.
18
Appendices
18.1
Appendix 1: Material Valuation Program Documentation
Description
This program reads the 'online material book table' or 'material Ledger' table J_1GVL_ML (henceforth
ML) and valuates materials. The movements of valuated materials in table J_1GVL_ML are updated
using the valuation prices. The valuation procedure is based on filling internal tables according to the
transaction category field TRACT. These internal tables are in turn used by the valuation routines.
Special transaction categories
The following transaction categories have special meaning and should be used only as described here.
Other transaction categories can be freely defined but the program must be edited if they are to be
SAP Hellas
Page 37 of 40
21/6/2012
VALUATION APPLICATION: TECHNICAL DESIGN DOCUMENT
assigned a special meaning (see 'enhancements' below!):
PU: purchasing account FI postings, fills tables TBL_PURCH (per purchase order item) and
TBL_PU (summarized per material).
GR: goods receipts and invoice verification in purchasing, fills TBL_PURCH (per purchase order
item) and TBL_GR (summarized per material).
PD: production against order; fills TBL_PROD.
CP: consumption to production; fills TBL_ANALP with relation between consumed and produced
material.
FS: facon expenses, fills TBL_COST.
PF: facon production fills both TBL_COST and TBL_PROD
OI: other imports which carry their own value as input to the valuation equation. Fills TBL_OIDT.
RV: revenue fills TBL_REV. Not used by valuation, but used from program that performs the A/L
postings.
SA: consumption towards assembly method 1 (treat disassembly as reverse assembly). Fills table
TBL_ANALS.
AP: production from disassembly-method 1, treat as SA.
SP: production from assembly-method 1, fills TBL_OIDT (per material and TRACT).
AA: consumption towards disassembly-method 1. Treated as reverse assembly, thus same as SP.
OA: consumption to assembly-method 2, same as SA.
OD: consumption to disassembly-method 2 (treat materials resulting from disassembly as
products): fills TBL_ANALS but reduces the quantity of the disassembled material according to the
quantity and value of the co-products. Method 2 will require cyclic valuation if both assembly and
disassembly occurs within same valuation period
IA: in from assembly-method 2, same as SP
ID: in from disassembly-method 2, same as IA. All that are marked as consumptions fill tables
TBL_ANAL (per material) and TBL_CANAL (per TRACT as well).
DT: stock in transit. Irrelevant for valuation, but fills TBL_CANAL with two lines, one with quantity =
VLTR_QS and tract = 'TR' , and one with tract = 'DI' and opposite quantity.
T2: incoming transfer with value at source plant, fills TBL_INTR.
Valuation Assumptions
All valuation methods solve the equation IS + PU + PD + OI = RM + CO, where:
o IS = initial stock
o
PU = purchases (including GR/IR)
o
PD = production costs including direct material cost (PC) plus all forms of expenses
o
OI = other imports, by definition = movements that carry 'own' value other than purchases or
production
o
RM = remaining stock
SAP Hellas
Page 38 of 40
21/6/2012
VALUATION APPLICATION: TECHNICAL DESIGN DOCUMENT
o
CO = all other movements that acquire value through the valuation process, such as:
-
Cost of goods sold
-
Consumption to production
-
Physical inventory movements
It has to be stressed, that in the case of multiple phase production the cost of components (PC) for a
semi finished material produced in phase i, for example, is defined as the sum of the product: "Quantity
consumed to production x Consumption price of consumed material" over all these components. Note
that consumption price by construction implicitly includes production costs for lower production phases
(<= i - 1).
It is also noted that when valuating materials, the rule of 'selecting the minimum price between historic
cost and current replacement cost' is not applied directly. Rather, there is an option to modify the RM
stock prices according to this rule AFTER the valuation program has run (at the year end closing). With
this method the consumption price is not affected and therefore price changes according to 'selecting the
minimum' rule do not have to 'propagate' upward the production chain. The resulting deviations from the
valuation equation are displayed in the Warehouse book separately.
Only WMA and WMAPL valuation methods are currently supported with linear system cyclic valuation.
The following two assumptions pertain to the LIFO and FIFO methods:
o
The OI transactions can also be used as part of the LIFO/FIFO layer (selection screen).
o
The FIFO/LIFO layer is constructed on the basis of Goods Receipts for a given purchase order
line item. The value of each Goods Receipt is obtained by collecting the total value of the PO
line item (invoices + subsequent D/C + GR/IR) and distributing the amount on the Goods
Receipts based on GR quantity.
Currently supported valuation methods
FIFO (First In First Out): Remaining stock 'covered' by most recent purchases, uniform 'consumption'
price. OI transactions can also contribute in building the layer.
LIFO (Last In First Out): Remaining stock 'covered' by initial stock; when this is insufficient, by older
purchases; uniform 'consumption' price. OI transactions can or cannot contribute in building the layer.
WMA: Remaining stock and consumptions have identical price. Supports co-products, and cyclic
valuation with linear system.
WMAW: WMA with Work in Progress (WIP). Does not support linear cyclic valuation or co-products.
Production orders characterized as WIP are valuated with SAP price and the difference from the actual
value is defined as WIP.
WMAPL: WMA for Plant level valuation. Variation of WMA in which plant transfers are treated as input
with values determined at the source plant. This makes sense for valuation at plant level and requires the
treatment of potential circular transfers. Supports cyclic valuation with linear system, but not co-products.
FIX: Fixed price (only for by-products, does not support purchases and other imports).
Enhancement options (for developers)
Self-defined valuation methods can be freely created in customer exit include ZXJ1GVL (see also note
1138580).
Follow the procedure:
1. Define the new valuation method, say 'MYVAL' in customizing of 'Valuation Methods'
2. Create customer exit include ZXJ1GVL. Note that ZXJ1GVL is already included in main valuation
program J_1GVL_VL, therefore it’s not required to repair the standard program.
3. Edit ZXJ1GVL with your new valuation method. You may use one of the standard ones (FIFO,
WMA) in program J_1GVL_VLI03 as template.
SAP Hellas
Page 39 of 40
21/6/2012
VALUATION APPLICATION: TECHNICAL DESIGN DOCUMENT
4. If additional information is required that is not available in the already used internal tables, you
can:
-
Define the new internal table(s) in program ZXJ1GVL.
-
Create a form 'CUSTOMER_FUNCTION’ in ZXJ1GVL. Localization is delivered with this
form nonexistent. If found, it is executed during access of J_1GVL_ML in form
‘READ_ONLINE_WHB'.
-
Edit the form 'CUSTOMER_FUNCTION’ in order to append data to these new internal tables.
-
In ‘MYVAL’ form edit the additional internal tables filled in 'CUSTOMER_FUNCTION’ as
needed.
By searching in program J_1GVL_VL for string ‘enhancement’ you can track down all spots of the code
where customer exit routines are called.
Valuation of cyclic production and circular plant transfers if valuation at plant level
In the case of cyclic production the valuation equation for the materials 'belonging' to a cycle are coupled
and must be solved simultaneously (for details see Appendix 2).
As a first step the program determines the smallest sets of materials that are to be valuated as a system.
After that the application can apply the following method to each such set:
o Exact solution of the coupled (linear) equations using the Gauss Jordan method. Currently, this
method is only supported for WMA and WMAPL valuation and the valuation method in the
customizing is overridden once cyclic valuation starts.
o Iterative solution. This is not restricted to WMA but is slower and in principle may not converge.
o Customer-specific algorithms (for example, a generalization of the linear system approach to work
with WMAW method…) can be freely created by including a form 'CUSTOMER_CYCLIC' in program
ZXJ1GVL (see above).
Closed 'paths' of assembly / material transfer (e.g. movements 309 / 310) as well as plant transfers
(valuation level – plant only!) are also recognized by the algorithm that constructs the irreducible sets.
Note that all these methods entail the danger of arriving at extremely large or even negative prices!
18.2
Appendix 2: Treatment of cyclic production/plant transfers
In the case of valuation at the plant level but also in the case of production feedback it may well occur
that the valuation equation for one object depends on the solution of other such equations in a non-trivial
way. This scenario is denoted as ‘cyclic valuation’ and requires special treatment. The attached
document describes in detail such scenaria and a formulation of the Weighted Moving Average method
that allows handling them (in Greek). ..\
.doc
SAP Hellas
Page 40 of 40
21/6/2012