V/08 - Pricing Procedures & calcul - Please help - Very Important & Urgent

[Former Member]

Hi,

My task is to remove hardcoded values from over 35 calculation routines.

Each routine include starts with the prefix RV64a__________, with the blank being the 3 digit routine number.

As I understand, transaction V/08 is the configuration area.

What I will be doing is copying the standard routine include to a custom (z) routine, modifying the custom routine and then going through V/08, finding the standard routine that I just copied and putting the custom routine in it's place.

However, I am no clear on several things:

1. Is the above method of copying routines and then changing configuration in V/08 correct?

2. Is any additional configuration needed?

3. IF you go into V/08, select a procedure, click on control and then press F4 in the column "CalType", you will get a dialog with a list of all of the available calculation types. Will my custom calculation type appear here? Is this even necessary? How do I make it appear here, if necessary?

4. Also, the routine programs are actually includes. A full list of available routines is stored in include RV64ANNN. How do I get my custom routines there? Is this even necessary? How do I make it appear here, if necessary?

Please help.

Thanks,

John

[Former Member]

Sorry John, it is not 9xx, could be 6xx, 7xx. It may not be a universal standard, that's why you'll want to read the detail documentation. At least if you go with 9xx you are safer !

[Former Member]

Can anyone quickly explain why these require access keys? Is it because they are assigned to an SAP standard Development class?

[Former Member]

Access keys are used to find out the right G/L account to post the values of the condition types in th pricing procedure.

Because of access keys, All the condition type values are posted to accounting dept.

HOpe it is useful...

[Former Member]

you need access key to change any standard functionality and also to add new routines than what SAP provides. Some times it can also be on charge basis. Its required for sap to provide you service.

kaleeswaran, i think john is asking about access key not account key

regards

sadhu kishore

[Former Member]

However, SAP won't maintain custom routines (600-999). If custom routines are modified, why is an access key needed for custom routines (not modifying the standard ones > 001-599)?

[Former Member]

Yes ,

Sorry i misinterpreted.

[Former Member]

John, Like Manfred said, use T-Code VOFM.

Whereby you use "Z" for ABAP stuff, The deal with these 3-digit routines is that you use 9nn for your custom routines. Anything 900 and higher is like the ABAP "Z" custom code. Behind the scenes it will actaully create the RVAxxxx program.

So create your 9nn routine, and then put that number in the Pricing Procedure (V/08).

Then

a) Test.

b) Adjust Code

c) Repeat until you get it !

Read the link Manfred provided for more detail.

[Former Member]

Thank you for that bit of information - very helpful.

However, are you sure that it is 9XX and not say 7XX or 8XX? Is there any online documentation that can provide proof for your answer? I ask this because my functional resource, while not being able to provide much help, has mentioned that routines over 500 or 5XX are custom, while everything below was delivered with the system?

Does this depend on the system? Please help.

Thanks,

John

[Former Member]

John,

As per standard all routines over 599 are custom. I have not seen any documentation saying this. This doesnot depend on system. This is an universal standard.

For more information read this.

Introduction

A VOFM object is uniquely defined via characteristics "group indicator" GRPZE and "group number" GRPNO.

Here the group indicator, technically represented by a character field of length 4, is the logical connection to the calling environment.

Examples:

ABED copying requirement in the order

ADAT data transfer in the order

PBED requirements pricing

CASC Data transfer for sales activities

PBEK requirements account determination

CHRG requirements batches

REAK archiving for orders

VFCL Multi-dimensional scales

...

You can find all defined group indicators in the allowed values of the "GRPZE" domain in the ABAP Dictionary (Transaction SE11).

The group number can have a value from 1 to 999.

Exceptions are group indicators "PSTK" (= group key routine pricing) and "TDAT" (= data transfer for texts). For these the system can only assign group numbers from 1 to 99.

2.2 Namespaces

The VOFM has separate number ranges in order to distinguish VOFM objects delivered by SAP from customer-specific VOFM objects. These number ranges are often also called "VOFM namespaces".

However, note that this is not a "real namespace" that is protected by corresponding entries in system table "TRESC" (= reserved names for Customizing tables and Customizing objects). Instead, only the VOFM logic itself does the definition and check of the number ranges.

The following list displays the customer number ranges sorted according to group indicators:

Indicator Name Number range customer

FOFU Subsequent functions 900 - 999

PSTK Group key routines 50 - 99

TDAT Data transfer routines f. texts 50 - 99

all other group indicators 600 - 999

In Note 356737 you can find more information on the available VOFM number ranges.

2.2.1 SSCR object registration

VOFM objects are subject to SSCR registration (= SAP Software Change Registration).

The reason for that is the necessity that every VOFM object is physically assigned to that SAP development class, from whose programs a corresponding jump into the VOFM object later occurs.

If you use the VOFM interface the system makes the assignment automatically. An assignment of customer-specific development classes is not possible.

2.3 Structure of a VOFM object

A VOFM object consists of the following parts:

Include file with ABAP form routine

TFRM table entry

TFRMT table entry

2.3.1 Include file with ABAP form routine

In the ABAP form routine the desired function is programmed.

Example pricing value formula number 001:

Include name : FV64A001

Form routine : FRM_KONDI_WERT_001

Implementation: * * Profit margin considering rebate agreements

form frm_kondi_wert_001.

xkwert = komp-kzwi3 - komp-wavwr.

endform.

Dependending on the selected group indicator, the group number and the system type (SAP or customer system), the system assigns and generates the include name and form routine name automatically.

For this reason, standard routines delivered by SAP generally have a different structure of the include name than customer-specific routines.

Example:

SAP standard value formula for the pricing

=> prefix FV64A + object number with 3 places from 'SAP namespace'

=> for example FV64A001

Customer-specific value formula for the pricing

=> prefix RV64A + object number with 3 places from 'customer namespace'

=> for example RV64A905

2.3.2 Table entries in TFRM and TFRMT

The entries in tables TFRM and TFRMT belonging to a VOFM object are used for the status management and assignment. The system always analyzes them if the user calls Transaction VOFM or if a generation operation occurs (for details refer to section 2.5).

The system generates exactly one TFRM table entry per VOFM OBjekt. In this TFRM entry the following information is stored:

Group indicator GRPZE

Group number GRPNO

Routine 'active' indicator AKTIV_TFRM

Application KAPPL

Date of the last generation GNDAT

Time of the last generation GNZEI

Examples: GRPZE GRPNE AKTIV_TFRM KAPPL GNDAT GNZEI

PBED 001 X V 06/13/2001 09:06:39

TDAT 001 X 06/13/2001 09:06:39

CHRG 003 X 06/13/2001 09:06:39

... ... ... ... ... ...

The meaning of group indicators and group numbers has already been dealt with.

The 'active indicator' controls whether a VOFM object is 'active' or 'inactive'. Active VOFM objects have characteristic value AKTIV_TFRM = 'X', inactive objects have characteristic value AKTIV_TFRM = initial.

VOFM objects flagged as 'active' are 'known' to the calling program logic, that means they were included in the main program of the 'calling program' and can thus be addressed and processed during the runtime.

You cannot delete VOFM objects that are still 'active'. In this case you have to reset the active indicator manually before.

The content of the 'Application' field serves to filter the relevant VOFM objects in various display functions and Customizing functions.

Example: Condition value formula 010 'Relevant Price'. This formula has characteristic value 'MS' for the 'Application' field (= External Services Management purchasing). Therefore the object is not open for selection in the input help during the maintenance of pricing procedure SD (Transaction V/08), because this is a Customizing transaction assigned to application 'V' (= Sales and Distribution). Storing an application key is optional.

The generation date and the generation time record the time of the last registration of the VOFM object (the object carrier, refer to section 2.4.1).

In addition to the respective TFRM entry a VOFM object can have 'n' entries in table TFRMT. The entries are used for the storage of language-dependent object descriptions, which are structured as follows:

Language key SPRAS

Group indicator GRPZE

Group number GRPNO

Description BEZEI

Examples: SPRAS GRPZE GRPNO BEZEI

D PBED 001 Regulierer abweich.

E PBED 001 Different payer

... ... ... ...

The system supplies the language key automatically with the logon language of the user during the creation of a new VOFM object.

The length of the object description is limited to 20 characters.

Important! A VOFM object is only consistent if both the Include file with ABAP form routine and a corresponding TFRM table entry exist. Entries in table TFRMT are optional.

2.4 Calling VOFM objects

As mentioned above, VOFM objects are called directly by the application logic of R/3 standard programs. Technically this is implemented by ABAP statement 'PERFORM ... IN PROGRAM'. With the aid of this statement you can specify both the name of the subroutine and the main program dynamically (during the runtime).

Example: Call of a condition value formula from the pricing

...

if xkomv-kofrm ne 0. <<< formula reference existing?

xkwert = xkomv-kwert. <<< act. value in work variable

frm_kondi_wert-nr = xkomv-kofrm. <<< set up object names

perform (frm_kondi_wert) in program saplv61a if found. <<<call

xkomv-kwert = xkwert. <<<result value assignment

endif.

...

In the example above the subroutine is determined by the contents of variable 'FRM_KONDI_WERT'; the main program, which is to be searched for the form routine, is SAPLV61A.

If the called routine is not known in the main program, a program termination with the title 'PERFORM_NOT_FOUND' occurs. Therefore some users of the VOFM technology call ABAP statement 'PERFORM ... IN PROGRAM' together with the addition 'IF FOUND', which has the effect that a jump into the form routine is only executed if this in fact exists in the main program. This does indeed prevent a program termination, however, the result of the overall process may deviate from the result expected by the user, because in this case the system does not execute the source code implemented in the VOFM object.

2.4.1 VOFM 'object carrier'

Object carriers are required to make a VOFM object 'known' in the main program of the calling program (refer to section 2.4). The object carrier is integrated in the main program of the calling program as an independent include (for example SAPLV61A, SAPMV45A and so on).

Example: Inclusion of object carriers for word processing in SD

documents; Program 'SAPLV45T'

...

*******************************************************************

System-defined Include-files. *

*******************************************************************

INCLUDE LV45TTOP. "Global Data

INCLUDE LV45TDEF.

INCLUDE LV45TUXX. "Function Modules

INCLUDE LV45TNNN. <<< 'carrier' copy requirements for texts

INCLUDE LV45TENN. <<< 'carrier' copy routines for texts

...

Every active VOFM object (for an explanation on the active indicator refer to section 2.3.2) must be registered in the 'carrier'. The system writes standard VOFM objects delivered by SAP directly into the 'carrier', VOFM objects from the number range reserved for customers (refer to section 2.2 'Namespaces') are sorted into a 'sub-include' included in the carrier.

Exactly one carrier exists per group indicator. The names of all defined object carriers are hard-coded in program MV80HF0A, form routine 'AKTIVIEREN_TRAEGER_SETZEN'. Here the names of the sub-include for customer-specific VOFM objects belonging to the main carrier are also defined.

Example: Carrier object 'FV63ANNN' for the registration of condition basis formulas in the pricing (Program SAPLV61A)

FV63ANNN

<<< main

carrier-include

|-INCLUDE RV63ANNN. "User-Routinen <<< sub-include customer objects

| |- INCLUDE RV63A910. "Customer specific

| |- INCLUDE RV63A911. "Customer specific

| |- INCLUDE RV63A912. "Customer specific

| |- ...

|- INCLUDE FV63A001. "Volume

|- INCLUDE FV63A002. "Net value

|- INCLUDE FV63A003. "Net Price

|- INCLUDE FV63A004. "Net Value Plus Tax

|- INCLUDE FV63A005. "KZWI1

|- ...

Because the content of the VOFM object carriers is automatically created source code, you should avoid manual changes to them.

SAP notes, which suggest manual changes to the object carriers, are therefore also incorrect. However, if you nevertheless receive such a note to solve a problem, contact the SAP Support with a reference to this note.

2.5 Activation, generation and RV80HGEN

The 'activation' is the inclusion of an VOFM object in an object carrier. A 'deactivation' results in the removal of the VOFM object from the object carrier. The overall process for the creation of a current object carrier is often called 'generation'.

Generally the activation or generation fall into three types.

Individual activation

Collective activation

Generation of object carriers via report RV80HGEN

The 'individual activation' causes the registration of an individual VOFM object in the corresponding object carrier. Which object carrier is relevant is determined with the aid of the group indicator and the group number. In addition to the entry of the VOFM object in the object carrier the system writes the date and time of the generation into table TFRM (refer also to section 2.3.2).

You can start the individual activation only manually. It is always always executed when a user selects a line within the VOFM editing interfaces and afterwards selects activity 'Activate' from the 'Edit' menu.

The 'collective activation' causes the registration of all VOFM objects that belong to a certain group indicator. Analog to the individual activation the system determines the relevant object carrier automatically and writes date and time into table TFRM. The 'collective activation' is a process which you can start also only manually. For this purpose, choose activity 'Activate all' from the 'Edit' menu.

During the generation via report RV80HGEN the system sets up the object carriers of all defined group indicators again. However, the system includes only those VOFM objects that have set the 'active' indicator in the corresponding TFRM table entry. Nonactive VOFM objects are not included in object carriers during the generation via report RV80HGEN. Due to the quantity of the data to be processed, the generation via RV80HGEN can take between 0,5 and >5 minutes (depending on the system and the constellation).

Because the RV80HGEN is defined as 'XPRA', it is executed automatically during a system upgrade.

You can also use this XPRA feature for the transport of VOFM objects in order to implement an automatic update of the object carriers after the import of VOFM objects into the target system (section 2.6 provides more details on the transport).

Both the collective activation and the activation via report RV80HGEN technically revert to the program components of the individual activation. For the separate control of the individual activation types form routine AKTIVIEREN_EINZELN (Include MV80HF0A) has a 'USING' parameter, which can have the following characteristic values:

'E' Activate individually

'A' Activate all (= collective activation)

' ' Deactivate individually

During the generation via RV80HGEN the system executes a collective activation for every group indicator sequentially, that means a call of form routine AKTIVIEREN_EINZELN with characteristic value 'A'.

2.6 Transport

If you want to transfer VOFM objects from one system (= source) into another system (= target), this is generally made with an object transport. As of Release 4.0, the VOFM function has a connection to the SAP 'Change and Transport System' (CTS) in order to simplify the transfer process for the user. By the transport connection the system automatically adds newly created or changed VOFM objects to the object list of a transport request which was selected by the user before.

All steps necessary for the execution of a VOFM transport are described in detail in Note 22808 'Transferring formulas'. Note that steps 1-4 are only needed if the VOFM maintenance environment providesno automatic connection to the transport system or if you want to combine a transport request manually. In any case you must execute step 5, regardless of how the transport request was created.

In addition to Note 22808, Note 385067 contains an overview for releases >= 4.6C regarding which sorts of tasks and object entries are required in a transport request (depending on the activity carried out (create/change/activate/deactivate/delete)) in order to transport a VOFM object successfully.

Rgds,

Naren

Edited by: Naren Someneni on Feb 20, 2008 4:06 PM

Edited by: Naren Someneni on Feb 20, 2008 4:12 PM

[Former Member]

http://help.sap.com/saphelp_46c/helpdata/en/04/c3dc097a35d111950d0060b03c6b76/frameset.htm

[Former Member]

Hi John,

you can use t.code VOFM to see all the available routines used across pricing. You can find the alt cal types, base valuues, requirements etc.

Any change in standard routing would require an access key however.

regards

sadhu kishore

[Former Member]

John,

You can not copy the standard routine to a z routine as it is generated by SAP. If you have to remove the hard coded values then the only option is to change your standard routine only RV64AXXX.

When ever you enter the routine number in the formulas -> condition value in VOFM tcode, it will ask you to enter access key. Once it is provided that routine is generated by SAP.

Activate that routine, come back, select your entry and click activate. Then you can see your include RV64AXXX in include RV64ANNN.

The when you do an F4 in the caltype in the control of the pricing procedure you can view your routine. Select it assign to whatever condition you want to.

Hope this is helpful.

Thanks,

Naren

[Former Member]

Is this a standard method (changing the standard routines)?

Is there online documentation that I can see as proof?

It's just that as developers, you should try to avoid changing standard objects and use 'z'- custom objects instead.

However, please confirm if this is the only method available for this situation, and if possible, proof or reason behind this method.

Thanks,

John

[Former Member]

Hi John,

You have to create your own routines in VOFM. Therefore you can just overwrite an existing routine (3-digits code) with your own code (e.g. 901, etc) and change the ABAP coding. Later you have to assign your routine in V/08. OSS Note 327220 gives you more information (Link: [service.sap.com/notes]

Cheers,

Manfred