VOFM problem

I am trying to modificate the net price in VOFM for a purchase order, but i need to know the position of the purchase requisition order that i put in the table control of me21n and when i make a get parameter of BAP parameter i don´t find the data, and i can´t find it in komp, komk, xkomv structure, does anybody how can i get this data in my routine?
thanks in advance

Hi,
The procedure to create the new VOFM.
1. Go to VOFM transaction
2. Page down until you find a new spot on the page to put in the VOFM number and description.
3. Put in the VOFM number and the description of the VOFM.
4. Now the VERY IMPORTANT part of the process. Double click on the VOFM description not the VOFM number to create this as a Development/Correction and not as a repair. If you double click on the number then this copies some existing code and prompts you for a repair.
5. Activate and generate the VOFM routine. Note: Configuration must be setup by the OM team for this step.
for example Go to the routine number that needs to be copied.
Put your cursor on the routine number field that needs to be copied.
Overwrite that number with your new routine number and hit enter.
The new routine will be created as a copy of the old routine and you can modify the new routine as you need it.
Ex.
You have to copy routine 104 to 904
Routine number Description Active
104 Bill.bus.item data X
Put your cursor on 104 and then change it to 904 and hit enter.
904 will be created as a copy of 104 and you can make your changes in 904.
Don't forget to activate it after you are done.
refer the below link
https://forums.sdn.sap.com/click.jspa?searchID=3604222&messageID=994791
Reward points
Regards

Similar Messages

Routine (VOFM) problem

Hi friends,
In TCode VOFM, I have created two output types zet1 for shipment(V7) and another one is zet2(V3). but the print program is same which is assigned to nace for V7 and V3
in billing v3: if the routine(TCode VOFM) gives sy-subr = 4 then nace is not triggered it's working fine.
BUt(MY Problem), in shippment(V7): if the routine(TCode VOFM) gives sy-subrc =4 then the nace(print program) is triggered. How we can restrict.
Thanks & Regards,
Vallamuthu.M

Hi,
Two possibilities:
1. In tcode VOFM, when you do the entry for this subroutine, you have a field for this appl.
2. In the ABAP coding, set a check for the values of komkbv7 (for V7) and for komkbv3 (for V3). Or check the value of NAST-KAPPL or XNAST-KAPPL. Set a breakpoint and check what it's your best option to filter it.
I hope this helps you
Regards
Eduardo

VOFM - Requirements

Hi Folks,
I am working on requirements.
I am a bit new to this process.I wud like to have some detailed info on the same.Please clarify the below mentioned.
1.I've seen Requirements in VOFM only for some areas..like output control,pricing,material determination etc. what is the working mechanism of this? How is it different from USER EXITS?
2.The same piece of code appears twice in the same requirement under to differnet form definitions,namely form KOMBD and KOMBV ? why this is required twice?
3.why do we need to run RV80HGEN after creating a requirement?
4.From where the number series starts for newly defined routines apart from standard requirements?
5.If we want to modify the standard exist what are the precaution to take? what i heard is ..once we give the access key for it...there is some icons apper on tool bar like INSERT DELETE etc..
Your help is appreciated.
Thanks
Raja

Hello Raja,
As indicated only for the following as indicated number range is allowed for rest it is 600-999.
Name Number
Subsequent functions 900 - 999
Group key routines 50 - 99
Data transfer routines f. texts 50 - 99
all other group indicators 600 - 999

I am attaching another note which deals with VOFM problem. Keep this with u as it will prove useful.
 SAP Note 327220
This note is an explanation of function "Maintain: Requirements and Formulas", which is also known as "VOFM".
By using descriptions and examples, this note explains how the VOFM function works in the R/3 Standard System, which objects are related to it and which restrictions exist.
Chapter 2.7 explains possible causes of errors and solutions for problems with the VOFM function.
To provide a good overview, this note is subdivided into the following subareas:
 1. General information
 1.1 Definition of terms
 1.2 Application areas
 1.3 A frank word on the "source code responsibility"
 2. Technology
 2.1 Introduction
 2.2 Namespaces
 2.2.1 SSCR object registration
 2.3 Structure of a VOFM object
 2.3.1 Include file with ABAP form routine
 2.3.2 Table entries in TFRM and TFRMT
 2.4 Calling VOFM objects
 2.4.1 VOFM object carrier
 2.5 Activation, generation and RV80HGEN
 2.6 Transport
 2.7 FAQs: Possible causes of errors and problems
Technical field names are displayed in angle brackets [].
Note that this note only explains the mode of operation of the VOFM in an R/3 Standard Core System. For R/3 industry solutions or Add-Ons the VOFM function displays a different behavior in subareas, however, this is not dealt with in this note.
Additional key words
VOFM, SAPMV80H, TFRM, TFRMT, RV80HGEN, XPRA, formulas, requirements, data transport routine, copy routine, data transfer.
Cause and prerequisites
1. General information
1.1 Definition of terms
Depending on the business processes used it may be necessary to influence the standard behavior of R/3 applications. For that purpose the VOFM function provides a corresponding environment in order to be able to develop and manage customer-specific logic simply.
The system stores the objects generated via the VOFM in the Customizing of the respective application area (Pricing, message determination and so on) and its programs call the objects correspondingly.
Also SAP delivers certain functions in the form of VOFM objects.
Consequently, the VOFM is an exit technology as explained in more detail in Note 381348.
1.2 Application areas
Typical VOFM objects are requirements, formulas and data transfer routines.
These are used in processes of the purchase order, the delivery, billing, price determination, material determination, message determination, the free goods, the pricing and of others.
In the entries of the R/3 core menu of Transaction VOFM you can find a precise overview of the supported application areas.
1.3 A frank word on the "source code responsibility"
As in user exits, in VOFM objects are many fields and tables available. Thus, the use of VOFM objects is very versatile and consequently also very critical under certain circumstances. For the use of "customer-specific" VOFM objects the statements in Note 381348 regarding the responsibility for customer enhancements (Maintenance responsibility, problems during the upgrade and so on) apply. Read this note carefully before you decide on the use of customer-specific VOFM objects. Errors and data inconsistencies that are caused by improper application or implementation of VOFM objects are not processed by the SAP Support but exclusively within the framework of the Consulting that has to be purchased separately.
2. Technology
2.1 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.
2.7 FAQs: Possible causes of errors and problems
This chapter deals with the most frequent errors and problems that occur when using the VOFM function and its objects. If problems arise for which this note provides no explanation or solution, create an OSS message on component CA-GTF-BS-VOFM and send it to the SAP Support.
(01) Question/problem:
 During the order processing, in the shipping, LIS, billing and so on a program termination with error message: PERFORM_NOT_FOUND occurs when you call a VOFM object. This symptom can occur for all users of VOFM objects.
(01) Answer:
 The used VOFMobject is not known in the main program of the calling program and thus cannot be addressed. Details on the call method of VOFMobjects are described in section 2.4 of this note. Note 28683 describes how to correct this error.
(02) Question/problem:
 Even though report RV80HGEN was executed, the VOFMobject is not registered in the object carrier. Why?
(02) Answer:
 During the setup of the object carriers via RV80HGEN the system includes only VOFMobjects which have set the 'active indicator' (refer to section 2.3.2). If the active indicator for the corresponding object is not set, the RV80HGEN does not process the VOFMobject. Solution: Set the active indicator for the respective object and start the RV80HGEN again.
(03) Question/problem:
 The syntax check in the ABAP form routine of an VOFM object displays syntax errors.
(03) Answer:
 Note the explanations on the work method of the syntax check in Note 393012. In addition, the restrictions of the SAP maintenance responsibility to customer-specific VOFM objects (described in section 1.3) apply.
(04) Question/problem:
 When you create/change VOFM objects the system requires an SSCRregistration key, even though the VOFM is within the 'customer namespace'.
(04) Answer:
 Refer to the explanations given in section 2.2. 1 'Registration'.
(05) Question/problem:
 In which namespace can I create customer-specific VOFM objects? Or: Which routine numbers are reserved for customers?
(05) Answer:
 Refer to Note 356737, in addition refer to the explanations in section 2.2 'Namespaces'.
(06) Question/problem:
 Is it possible to assign VOFM objects to own development classes?
(06) Answer:
 No. Refer also to section 2.2.1
(07) Question/problem:
 When you create a VOFM object the system displays information message TR 015 'Object can only be created in SAP development class'.
(07) Answer:
 This is no error. Refer to section 2.2.1. and the answer to question number 5.
(08) Question/problem:
 How can I transport VOFM objects via the Change and Transport System ?
(08) Answer:
 The steps necessary for a successful transport are described in detail in Note 22808.
(09) Question/problem:
 The used transport request does not contain an entry for the VOFM object carrier in the object list (for example RV61ANNN, FV45ANNN ...)
(09) Answer:
 The object carriers must not be transported. Instead, a setup of a current object carrier suitable for this system is required in the target system. For details refer to Note 22808, step 5 as well as section 2.4.1 and 2.5 of this note.
(10) Question/problem:
 How are VOFM objects deleted? And can deletions of VOFM objects also be transported?
(10) Answer:
 You should delete VOFM objects only via the editing interface of the VOFM function. Only this way it is ensured that all subobjects (ABAP form routine, TFRM and TFRMT table entries) are completely removed.
 You can also transport the deletion youmade into an additional system. For that purpose, the setup of an object list in a transport request analog to the creation (refer to Note 22808) is required.
 During the deletion of objects the system deletes the object in the source system. At the time of the export the export program (R3trans) notes that the object does not exist any more. In this case the system enters a "D" into the 'Object function' field in the corresponding entry in the object list of the transport request.
 The deletion of table entries is made analog to the deletion of objects. First delete the keys in the source system. Then specify the deleted keys in the request. At the time of the export the transport program notes that the specified keys do not exist any more and deletes them in the target system. If you combine the object list of the transport request manually, you must set the object function of the individual entries correspondingly. To do that, proceed as described in the F1 help of the 'Object function' field.
(11) Question/problem:
 During the creation of VOFMobjects the system requires a transport request which contains a task of the 'Repair' category. The system displays message TK 181 'Repair &1 may only contain repaired objects'.
(11) Answer
 This problem is caused by a program error. Implement the corrections of Note 326560 or Note 385067 depending on your release.
(12) Question/problem:
 During the creation the system displays message TK 112 'Edit objects separately since they belong to different original systems'.
(12) Answer:
 This problem is caused by a program error. Implement the corrections of Note 326560 or Note 385067 depending on your release.
(13) Question/problem:
 When you create or activate VOFM objects the system displays message: 'Report/PROGRAM statement is missing or program type is INCLUDE?'.
(13) Answer:
 This problem is caused by a program error. Implement the corrections of Note 326560 or Note 385067 depending on your release.
(14) Question/problem:
 Why does the system generate VOFM objects with source system 'SAP'?
(14) Answer:
 Design. The entire VOFM logic depends extremely on basis functions like transport, object directory entries, generation and so on. Because VOFM objects are inserted in SAP standard development classes, these receive ID 'SAP' for source system during the generation process. This cannot be avoided and does not affect the VOFM function.
(15) Question/problem
 The system does not insert report RV80HGEN automatically as XPRA into the object list of a transport request.
(15) Answer
 Whether the system inserts report RV80HGEN automatically into the object list of the transport request depends on the release you use. For Releases 4.0A to 4.6B the system generates a corresponding entry, provided that all corrections for the VOFM function exist in the system. As of Release 4.6C the basis function of the 'Change & Transport System' (CTS) does not support the automatic insertion of objects of the 'XPRA' category into an object list any more. If you want an automatic registration of the transported routines in the target system, proceed as described in Note 22808, step 5.
(16) Question/problem:
 During the activation of VOFM objectsa termination occurs or the system requires a registration key for additional VOFM objects, even if they were not changed.
(16) Answer:
 There are inconsistent VOFM objects in the system (refer also to section 2.3.), that means table TFRMcontains entries for which no include with corresponding ABAP form routine exist.
 If the termination occurs for VOFM objectsfrom the SAP namespace, this is normally due to a delivery error as described, for example, in Notes 395600 and 0403705. Check whether already a corresponding note exists for the affected VOFMobject. If not, contact the SAP Support.
 If the problem occurs for customer-specific routines, the inconsistency is mostly due to a handling or transport error. For example the deletion of VOFMincludes via Transaction SE38has the effect that the system does delete the form routine and the corresponding include, however the system does not delete the entries in tables TFRM and TFRMT. Inconsistencies can also occur due to incomplete or incorrect object lists in transport requests. You can make a correction by newly creating the same object via the VOFM interface or be deletion analog to the method described in Note 395600.
(17) Question/problem:
 During the import of Support Packages or during the system upgrade, customer-specific VOFM objects were overwritten or are missing completely.
(17) Answer:
 First, check whether the missing VOFMobjects are really missing and if yes, whether all or only certain subobjects do not exist anymore (refer to section 2.3). if the VOFMobject is completely there, generally only a new setup of the object carriers is required. Read section 2.5 'Activation, generation and RV80HGEN' to learn which options exist for this purpose.
 If there is indeed a VOFM object but ifthe source code of the ABAP form routine does not correspond to the customer-specific, this is a delivery error. However, you can reconstruct the customer-specific source code with the version management. Proceed as follows: call the ABAP Editor for the affected objects by using Transaction SE38. Afterwards branch into menu 'UTILITIES' -> 'VERSIONS' -> 'VERSION MANAGEMENT'. Deselect the version delivered by SAP and select your original, customer-specific version instead. Choose 'RETRIEVE' to restore this version.
 Delivery errors of this type are documented by notes. If there is no corresponding note for the overwritten object in the OSS, contact the SAP Support.
(18) Question/problem:
 In the display of the Object Navigator (Transaction SE80) the system does not display newly created VOFM objects. On the other hand, it can also occur that deleted VOFM objects are still contained in the Object Navigator.
(18) Answer:
 The Object Navigator displays an obsolete status (refer also to Note 15447). Choose button 'Refresh object list' above the tree structure in order to correct this inconsistency.
(19) Question/problem:
 Is it possible to delete VOFM objects delivered by SAP in the standard?
(19) Answer:
 Yes. However, because of separate number ranges for VOFM objects SAP does not recommend a deletion of SAP standard objects.
(20) Question/problem:
 Which maintenance responsibility has SAP for customer-specific VOFM objects?
(20) Answer:
 None. Refer to the explanations in section '1. 3 A frank word on the "source code responsibility"'. According to Note 381348 this includes also VOFMobjects whose creation wasbased on notes of the 'Consulting' or 'Workaround for missing function' category.
(21) Question/problem:
 Where can I get help, if my customer-specific VOFM object does not work as expected?
(21) Answer:
 If you need support during the implementation of customer-specific VOFM objects you can contact the SAP Remote Consulting. Please understand that SAP cannot check VOFM objectswithin the framework of the normal support.

FAQ:Pricing determination的基本知识(3)

这是关于Pricing determination基本功能介绍的最后一贴。帖子里涉及到的note，请大家参阅附件。
之后的下一个帖子我准备说说在日常使用pricing功能出现异常时一些简单的自查方法。
<Group conditions>
Use of group conditions
Compensation of rounding differences for percentage and fix amount conditions. Example:
Item 10 16% MWST based on 100,90 DEM = 16,14 DEM
Item 20 16% MWST based on 100,90 DEM = 16,14 DEM
but as u201Ereal tax baseu201C the total value must be used (legal requirement):
16% of 201,80 = 32,29 DEM !!!
cumluation of scale base value. E.g. 10 apples and 5 lemons are sold to a customer but there is a discount based on the total amount of ordered fruits (15 pieces)
split functionality: condition values or rates entered on header level are distributed to items. Example: Split a value of 100 DEM to 100 items (= 1 DEM set for each item).
Handling of structure conditions (KUMU). Example: Price is set on lower level item but the main item is relevant for billing
The processing of group conditions is performance critical, in standard there are only a few group conditions, e.g. MWST, SKTV
<Condition exclusion>
There are two possibilities to achieve exclusion
Exclusion indicator KZNEP
Is set in the condition record or in the condition type (customizing)
Restrictions: it is not possible that a condition will exclude itself and if a condition is entered manually exclusion will not take place
Exclusion with KZNEP is achieved by using requirements (e.g. standard requirement u201A2u2018). Review note 92090, 41490
Exclusion groups
Have to be setup in customizing, IMG: Sales and Distribution -> Basic Functions -> Pricing -> Condition Exclusion
Flexible: can be set up for groups of conditions or individual condition types or records
Rules are used to judge which conditions are excluded, e.g. best price
Restrictions: it is not possible to use different rules in parallel, zero values of conditions are not used for exclusion in standard (note 39641)
<T-cd:VOFM>
Maintenance for requirements and formulas
Requirements
Formulas for
Scale base
Condition base value
Condition Value
Structure of group key
Copying requirements
Data transfer routine
Requirements and formulas are entered in pricing procedure
Customer name space:
Group key routines 50-99
All others 600-999
VOFM problems in 46C should be fixed by note 385067 (SP 16)
<Pricing copy>
If Document A is created with reference to document B
call of PRICING_COPY using
DOCUMENT_NUMBER_FROM - to read the pricing result of the origin document
DOCUMENT_NUMBER_TO - to assign the conditions to the right document (e.g. cancellation)
MODE - pricing type: rough filter, to figure out which conditions should be copied Normally given by the customizing of copy control.
SOURCE - direct source. Means that a condition should be directly taken from order, delivery, freight calculation etc.
SOURCE_KOMV - if PRICING_COPY should not read the data stored in KONV the calling application has the possibity to pass in condition information directly
TKOMV - includes conditions which survive the check and filter mechanism of PRICING_COPY. This table later on is used for the PRICING call.
Conditions are always copied on item level. Any header and group condition property is lost.

Dear Lakshman Iyer,
Thank you for your answer. It does not work, maybe due to
wrong setup. What do I wrong?
Define Condition Exclusion Groups
I created 1 excl. group = 10.
Assignment of Condition Exclusion <-> Condition Types
Assigend 3 condition types to 10.
Assignment of Condition Exclusion <-> Calculation Schema
entered:
Snr. 1 then group A and then group 10.
A is the condition excl. procedure.
But If I create a PO all three freight conditions are available.
And the last (with the access sequence is filled with 5%).
Then I enter the manual condition type with 100 Euro. And
now I have 2 conditions filled.
The goal is: if I fill manually the condition the condition
with the percentage should not be filled anymore.
Best regareds,
Eric.
Entered grou

Problem in VOFM Urgent.

Hi All,
I have created a routine in VOFM in which i just copied routine of service agent and shipment type.I named it starting with 903.
Now the problem is that my functional consultant tells that when he is going to VT02N and giving a shipment number the forwarding agent should be populated in the shipment screen.But it is not coming now.
So what I want to know is how do i know where the problem is?
i.e how to debug.Also I have activated the routine i created.Anything else i need to do?
Thanks in Advance,
Saket.

Hi ,
I hope the Custom Routine you created is assigned against the Service agent and shipping type , so that it can check the new routine for getting these values.
If so,please put a break point in the routine and check in debugging mode.
Regards,
Savitha.

Problem in Newly created routinue in VOFM

Hi,
We created new routine in VOFM copying existing one.
After that we activated after saving. But i am not seeing that routinue active status in active column.
How to solve the problem
chidambaram

hi Buddi ,
u need to activate Routine also , not only the program.
come to MAIN--->after coding ur 9XX and activate it --->pick that one --->goto EDIT --->Active.
dont active all.
regards
Prabhu

VOFM - Formulas Problem : Can't transfer in to target Client.

I just created a formulas in Tcode VOFM, and inserted some code , and actived it. ,
GRPZE GRPNO AKTIV KAPPL
ADAT 905 X
But I can't transfer it into target client.
The transfer log is ok .
But the target client still don't have formula 905 .
Is there any special step for the transfer of formulas ?
Many many thanks .
The following is my Request ! Is there any problem ?
DR1K903890 ZZFZWANG
DR1K903891 ZZFZWANG
Program
RV45C905
DR1K903892 ZZFZWANG
Table contents
TFRM
TFRMT

Hi Eswar ;
Done. I have found the formula in the target client.
I think the problem is simple .
The request was released and posted 3 days ago from dev system ,and It just appeared in the target client. But I found the transfer log is ok in DEV system.
Thanks you very very much, Eswar .
Best Regards
Fred

VOFM access key problem

Hi SAP Gurus,
I want to write a customized routine in VOFM with routine number 601.For this i need to have the access key.So i have generated request for access key at Service market place, based on the object name RV64A601 and the object type is VSED.I even got the registration key but when i am using this regsitration key on VOFM for the respective routine creation, I am getting "incorrect entry" message.
If any one of you have requested for an access for any customizing routine pls help me ASAP.

Obviously one (or all) of these items are incorrect:
1) it's not RV64A601
2) it's not VSED (actually I think it should be PROG)
3) System Release # is incorrect
4) you got a wrong key
When requesting a key, make sure to select the same values that you see on the screen where the key is requested. SAP is looking for an exact match. If anything is off, it's not going to accept the key.
If you also need to enter the developer's key (which doesn't seem to be the case), make sure you have the correct key and correct user ID.

VOFM ( Copying Requirements ) Problem

Hi All,
I have one requirement like up to now my billing documents are created based on sold-to-party but i need to create based on sold-to-party(VBAK-KUNNR) as well as cutomer PO Number(VBAK-BSTNK).
I am giving Example
Present :
Sold-To-Party : 1001
Orders : 10   customer PO - 5
Orders : 20   customer PO - 5
Orders : 30   customer PO - 6 . So for above situation system creates only one document because all Orders are under same sol-to-party (1001).
My Requirement:
Sold-To-Party : 1001
Orders : 10   customer PO - 5
Orders : 20   customer PO - 5
Orders : 30   customer PO - 6 .
For above case i need to create two invoice documents based on Customer PO(one for 5 and another for 6).
Is above scenario is possible with copying requirements ..and please help me out....
Points will be rewarded...
Thanks and Regards,
Siva.

Yes, you can use the copying requirment to handle this scenario.
You need to modify the VBAK-ZUKRI field to make the invoice split.
VBRK-ZUKRI+0(10) = VBAK-KUNNR.
VBRK-ZUKRI+10(30) = VBKD-BSTKD.
Try changing the VBRK-ZUKRI field in the debugging (set a break point in the data transfer routine of the copy control).
Regards,
Naimesh Patel

Problem in Invoice creation

Hi All,
I am facing problem while creating Invoice Pro Forma Ind D_ZXEP.
please look below to find out the process i am following.
First i create a VMI Consign using transaction VA01 for a line item
After that i create delivery using transcation VL01 and complete the PICKING
REQUEST for corresponding line item Ex 10 and its component ex 90001
and GOODS MOVEMENT and COnsignment fill up.
No i create invoice using transaction VF01.
When i press save its create two invoice, first for item 10 with qty 0 and second for line item component 90001 for the given qty.
But it should create one Pro Forma Ind D_ZXEP.
Please help me to know to solution for the above problem.
Thanks
Piyush Mathur

Piyush, this doesn't look like an ABAP issue to me, you might want to post your questions in the SD functional area forum to get a better response.
All I can suggest as a developer is to look at the VOFM routines (VOFM transaction) for the Data Transfer -> Billing Documents. See routines 1 and 7 and check if you have any custom routines for invoice split.
Also once we had an unwanted invoice split and I had to debug the transaction. According to my old notes, the crucial place was in the include LV60AA29, at perform xvbpap_identisch. You might want to put a breakpoint there and debug your VF01.

Question about the requirement for goods issue from a delivery (VOFM)

Dear all
※Please note that this is related to the credit limit check.
I am trying to set up the SAP system, so that if the maintenance contract (rental document) is billed at least once,
the system would allow the user to bill the customer regardless of the credit usage (ex. 150%).
So I created the following routine for the credit check (in VOFM).
IF XVBAK-AUART = 'ZMZZ'. --> Please note that ZMZZ is the document type of our rental document
 LOOP AT XFPLT.
 IF XVBUK-FKSAK = 'B' or XVBUK-FKSAK = 'C'.
We will not do any credit limit check for this item line.
 MOVE CHARX TO BYPASS-SECURITY.
 MOVE CHARX TO BYPASS-STATIC_LIMIT.
 MOVE CHARX TO BYPASS-DYNAMIC_LIMIT.
 MOVE CHARX TO BYPASS-DOCUMENTVALUE.
 MOVE CHARX TO BYPASS-CRITICAL_FIELDS.
 MOVE CHARX TO BYPASS-REVIEWDATE.
 MOVE CHARX TO BYPASS-OPEN_ITEMS.
 MOVE CHARX TO BYPASS-OLDEST_OP.
 MOVE CHARX TO BYPASS-DUNNING_LEVEL.
 MOVE CHARX TO BYPASS-USER1.
 MOVE CHARX TO BYPASS-USER2.
 MOVE CHARX TO BYPASS-USER3.
 EXIT.
 ENDIF.
 EXIT.
 ENDLOOP.
ENDIF.
Now, with the routine above, it became possible to bill customers regardless of the credit usage.
However, when we try to ship (posting goods issue) the item for that maintenance contract, when the credit usage exceeds 100%, the system rejects it with the error message below.
<Error message>
Static credit check: credit limit exceeded
Now, I want to set up the system, so that if the posting goods is for the item which satisfies the following condition,
the system would not reject the posting due to the error above.
<condition>
1. The item is for the maintenance contract which was billed at least once --> this means that this is not a new contract
※Please note that for new maintenance contracts (which is not billed even once), the system should not allow to post goods
 issue if the credit usage exceeds 100 %.
I looked into VOFM, and found out that we are using the following routines for posting goods issue.
<system routine>
13
<user routine>
113
But I didn't know where the error (Static credit check: credit limit exceeded) came from.
Could you tell me how to find (or where to modify) a location where I can make the modification in order to
satisfy our requirement?
Thank you very much in advance

Dear all
I was able to solve the problem by setting up the credit check routine for delivery notes, and assign it for "No credit check" field
in the automatic credit control (OVA8).
So, thank you for your help, everyone
Takashi

Advance output VAT configuration problem, FTXP

I have a problem with configuration of outgoing down payment tax code.
In transaction FTXP I've created tax code with following configuration:
TAX TYPE ,       ACCT KEY,    %,    LEVEL, COND. TYPE, ACCOUNT
Output tax (VAT)      , MWS, 10 ,    140,      MWR1,        1960000
OutputTax-DebitClear, ZUD,            ,    150,      MWR2,        9119000
OutputTax-CredtClear, ZUK,            ,    160,      MWR3,        9010000
Tax type - A, Output tax
Check - switched on
EU Code, Target code, Tgt tax code: Output and Input   are   empty.
When I try to post invoice (transaction FB01) in SAP R3 automaticaly generates additional line item for account 1960000 but no item generates for accounts 9119000 and 9010000 (i.e. for tax type ZUD & ZUK).
Tax category for accounts 9119000 and 9010000 is set to + (only output tax allowed).
Could you give me guidence what have I missed with tax configuation..
Thanx.

The problem has been solved.
We have problem with 901-requirement witch used in tax calculation procedure. Accordingly to russian legislation requirements SAP deliver configured tax calculation procedure - taxru. To avoid error message FF 731 - "Tax code may only contain one rate" tax calculation procedure uses 901 requirement for zud and zuk. 901 requirement should has condition text (VOFM transaction -> menu requirements -> Pricing):
check: ( sy-dynnr = '0312' and
              sy-cprog = 'SAPMF05A' and
              sy-tcode = 'FB01') or
sy-cprog = 'RFUMSV25' or
        sy-cprog = 'J_3RFUM25'.
        sy-subrc = 4.
In my case this text was changed by some one and my calculation procedure did not work.
Thank you all for assistance !!!!

Allow partial quantity billing for billing plans - VOFM - SAP Note 726039

Hi Gurus,
I got one task, telling that copy that routine 23 into customized ex: 902 in VOFM. Then change the copying requirement for the corresponding item category in the copying control (Transaction VTFA).
reruirement is that the customer is paying cash in advance. Goods are partially delivered.
ex:
Order 10001206 creates a downpayment request for 10EA. A delivery is created for 2EA.
First clearing invoice 70700001 is created with billing quantity A in the copy control: A Order quantity less invoiced quantity. Hence the whole order quantity is considered for billing.
For the second clearing invoice 70700003 (the first was cancelled) billing quantity B is used in the coy control: B Delivery quantity less invoiced quantity. Hence 2EA are considered as billing quantity. For an item that has zero delivery quantity an invoice with zero billing quantity will be created ( the behavior we see).
Billing type : ZBAC
SalesDoc Type : ZSC
Item Category : zsak, zszs, zsao etc.
They are telling the Solution like this.
the quantity to be billed is calculated from delivery quantity minus the already billed quantity during the billing of a billing plan date
Pls help me, I never used VOFM for enchancement.
As an abaper what we have to do for this task,
Thanks in advance.
Kiran.
Edited by: ACC10583516 on Jun 11, 2010 6:54 AM
Edited by: ACC10583516 on Jun 15, 2010 6:31 AM

hei Kumar,
How you solve this problem?
i also face this problem.
Please share the solution. Thanks

Problem with TFRM table active indicator in pricing routine RV80HGEN

Hi experts,
I have created few custom routines in VOFM tcode, and trasported to Q system.
In DEV in program RV61ANNN and in VOFM tcode, i can see the new includes and new routines.
But when i check in Q system in VOFM tcode the new routines are not available, nor in RV61ANNN program(new includes).
I have run the report RV80HGEN . But its not working.
I checked the table TFRM and the active field is blank for the group number and routine number.
But in DEV TFRM table has an X value in active field for that routine.
I dont know how to do it.
I can retransport the request again, but i dont know what all the objects needs to be created a new request. its risky.
Plz help me out on this.
I have checked OSS notes, even it says the same.nothing else.
Points are rewarded fully.
Thsnks,
KK

Hi,
The problem is with the active field blank in the test system. From OSS note 327220:
(02) Question/problem:
Even though report RV80HGEN was executed, the VOFM object is not registered in the object carrier. Why?
(02) Answer:
During the setup of the object carriers via RV80HGEN the system includes only VOFM objects which have set the 'active indicator' (refer to section 2.3.2). If the active indicator for the corresponding object is not set, the RV80HGEN does not process the VOFM object. Solution: Set the active indicator for the respective object and start the RV80HGEN again.
So I might suggest deactivating the object in development, transporting, then reactivating the object in development, and transporting again.
BR,
Tony.

Idoc Output Control Problem, Want to prevent IDoc creation

I want to prevent an IDoc from being simply created if a certain condition is not met. However if I set the sy-subrc = 4 and exit from the routine it still goes ahead and creates an outbound IDoc. Here is the code from the routine. I have debugged into the code and it DOES get executed when i change order info header from VA02. I have already debugged to make sure that the following piece of code does get executed and the SY-SUBRC does get set to 4 before the execution exits the Form given below. Please suggest what I m doing wrong?
FORM KOBED_601.
If the document is incomplete (Price not on list)then no o/p is created
IF KOMKBV1-UVPRS NE c_c.
SY-SUBRC = 4.
EXIT. "(also tried using RETURN)
endif.
*} INSERT
ENDFORM.
FORM KOBEV_601.
*{ INSERT ECDK903987 1
Falls Verkaufsbeleg vollständig ist, soll Nachricht erzeugt werden
If the sales document is complete, then the output should be created.
*} INSERT
ENDFORM.

Wait. I think I have figured out part of the problem. The problem is that both the VOFM routine that I have written 603 is executed followed by standard SAP VOFM routine 002. Though I checked that the configuration for the output type that I m using ZBAO has the right VOFM routine number 603 set, it still does execute the Standard SAP VOFM routine 002 after executing my routine, which seems to override the SY-SUBRC = 4 that I have set. If I set the SY-SUBRC = 4 in debug mode in routine 002 then the IDoc doesnt get created.
Is there a way I can prevent it from executing the standard SAP VOFM routine 002?

VOFM problem

Similar Messages

Maybe you are looking for