Monthly Archives: August 2007

Billing quantity

You can make the settings for the billing quantity in the copy control. You have the options of keeping the billing quantity equal to order quantity or delivery quantity or delivered quantity minus the quantity already invoiced. The billing quantity indicator specifies which quantity the system copies from the source document (a sales order, for example) into the target billing document (an invoice, for example).

Make sure that control of the amount to be billed is directly related to the item category billing relevance. (e.g. K – delivery related invoice for partial quantity, G – Order related billing of the delivery quantity etc.)

Advertisements

Suppressing Fields in Sales Order

The fields in a sales order can be made optional / mandatory by following this menu path – IMG – S&D-> Basic > Functions-> Log of incomplete Procedures =>  select the fields > from the tables and the system will check for them (OVA2/VUA2)

To make a filed entry enabled or grey (non-entry allowed):

User exits in the program MV45AFZZ-USEREXIT_FIELD_MODIFICATION

This user exit can be used to modify the attributes of the screen  fields. To do this, the screen fields are allocated to so-called modification groups 1 – 4 and can be edited together during a modification in ABAP.

If a field has no field name, it cannot be allocated to a group. The usage of the field groups (modification group 1-4) is as follows:

Modification group 1: Automatic modification with transaction MFAW

Modification group 2: It contains ‘LOO’ for step loop fields

Modification group 3: For modifications which depend on check tables or on other fixed information

Modification group 4: is not used
The FORM routine is called up for every field of a screen. If you require changes to be made, you must make them in this user exit. This FORM routine is called up by the module FELDAUSWAHL.

Actually suppressing fielding sales orders userwise is quite easy. We are doing it in our company. For this we use userexit FORM USEREXIT_FIELD_MODIFICATION in MV45AFZZ.

Below is the sample code

IF SCREEN-NAME = ‘VBKD-ABSSC’.

AUTHORITY-CHECK OBJECT ‘ZMV45AFZZ’ ID ‘SCRFNAME’ FIELD SCREEN-NAME.

  IF sy-subrc = 0.
    SCREEN-INPUT = 1.
  else.
    SCREEN-INPUT = 0.
  ENDIF.
endif.

You place the authority check object in authorization profile in the role of the users, who should have access to the field (in this case it is VBKD-ABSSC), and there assign the corresponding fields that are to be accessed via this userexit.

Finding User Exits

Need to find user exits module-wise? Suppose we want to see the available sales module user exits. Go to transaction SE81. Click on SD, then click “edit” on the menu bar and choose select subtree. Click on “information system,” Open Environment node, customer exits, and enhancements. Press F8 to get all the user exits for that module. In brief: SE81->SD->Select subtree->Information System->Envir->Exit Techniques->Customers exits->enhancements->Execute(F8)

Product Hierarchy

Tcodes – OVSV, V/76  

Define Product Hierarchies

In this step, you define product hierarchies which you can use for statistical analysis or pricing, for example, or you can change their structure. The product hierarchy groups materials by combining different characteristics. Each characteristic is represented by a specific product hierarchy level.

Example

A product hierarchy can be structured as follows:

  •  
      Level Example Description
  •  
      1 00001 Electrical appliances
  •  
      2 00002 Household appliances
  •  
      3 00000003 Wet appliances

In this example, a dishwasher belongs to product hierarchy 000010000200000003.

Standard settings

In the standard system, the product hierarchy consists of up to 3 levels. The first and second levels have 5 digits and the third level has 8. The maximum number of digits is 18 and the maximum number of levels is 9.

You can define hierarchy nodes at the individual levels of the product hierarchy.

From the initial screen you can branch to the following steps:

  • Product hierarchy structure
    In the Data Dictionary, you can change the structure of the product hierarchy (e.g. the number of levels).
  • Data entry/display
    Here you define the display of the product hierarchy and the format of the accompanying text.
  • Product hierarchy
    Here you define your product hierarchies.
  • Field catalog for pricing
    Here you make fields of the product hierarchy structure available for use in pricing.
  • Field catalog for the Logistics Information System
    Here you make fields of the product hierarchy structure available for use in the Logistics Information System.

Actions concerning the product hierarchy structure

Structuring the product hierarchy

The product hierarchy can be structured via DDIC structure PRODHS. In the standard system, a product hierarchy can be created with up to three levels. The individual levels can contain the following number of digits:

Level number of allowed digits

1 5

2 5

3 8

This can be changed as of Release 3.0, where it is possible to extend the maximum number of levels to 9.

If you want to change the standard setting of PRODHS, e.g. you want to change the number of levels, proceed as follows:

    1. Create an appropriate domain in the Data Dictionary (type CHAR with the required length).
    2. Assign these domains to the standard data elements PRODH1, PRODH2, …, PRODH9.
    Please note that you should use these standard data elements.
    3. Change the structure PRODHS by creating or deleting fields with reference to the data elements.
    Choose ZZPRODHN as field name, where n is the position of the field in the structure PRODHS.

Example

You want to change the structure of the product hierarchy from 5/5/8 digits to 5/5/5/3. Proceed as follows:

Create the following domains:

ZPRODH3 with length 5, category CHAR,

ZPRODH4 with length 3, category CHAR,

Change structure PRODHS:

  •  
    • Strucutre PRODHS in the standard system:
  •  
      Structure Fields Data element Category Length
  •  
      PRODHS ->
  •  
      PRODH1 PRODH1 CHAR 5
  •  
      PRODH2 PRODH2 CHAR 5
  •  
      PRODH3 PRODH3 CHAR 8
  •  
    • Changes according to example:
  •  
      Structure Fields Data element Category Length
  •  
      PRODHS ->
  •  
      PRODH1 PRODH1 CHAR 5
  •  
      PRODH2 PRODH2 CHAR 5
  •  
      PRODH3 PRODH3 CHAR 5
  •  
      ZZPRODH4 PRODH4 CHAR 3

Note

The structure PRODHS and the data elements PRODH1, …, PRODH9 are only provided by SAP with Release 3.0 and can be changed by the customer from this point onwards.

Conversion routines for INPUT/OUTPUT

The product hierarchy can be assigned to a conversion routine. The name of the conversion routine is PRODH. The output template can be defined in Customizing (see below).

The separators used in the template are not allowed for maintaining the product hierarchy nodes.

Example:

If the template is _____/_____/__________

The symbol “/” cannot be used when maintaining the product hierarchy nodes. In this case, the following entry would not be allowed: 123456/79012345678

Text concatenation

The description of a product hierarchy can be determined via concatenation, if required.

Proceed as follows:

    1. Determine the node preceding the current node
    2. Concatenate the description of the subsequent node with the description from the preceding node.

The text concatenation is valid for the entire product hierarchy, the concatenated text has a length of 20. Text concatenation can be activated/deactivated in Customizing (see below).

Note

Make sure during text concatenation that the text of the product hierarchy does not come from table T179T. In this case function module RV_PRODUKTHIERARCHIE_TEXT_GET is available.

Allowed symbols for product hierarchy nodes

If you have stored a template for the conversion routine, the separators in the template are not allowed.

Actions concerning data entry/display

You can make two settings regarding the layout of the product hierarchy and the format of the product hierarchy text:

    1. Enter a template for displaying the product hierarchy. This template defines the length of the individual levels and the separators.
    Note that the character used to separate the levels in the template cannot be used in the product hierarchy nodes.
    2. The description of a product hierarchy node can be determined by concatenation if required.
    If you activate text concatenation, the text for one level is added to the description of the higher level and then output. The text of the first level appears at the beginning followed by the text of the second and third levels. Text concatenation applies to the complete product hierarchy. The concatenated text can have a maximum of 20 characters.
    Do not activate text concatenation if you only want to issue the description of the hierarchy levels created for these levels when the product hierarchy was defined.

Actions concerning the product hierarchy

The product hierarchy can be freely defined and include up to three levels. The SAP System checks the entry in the field product hierarchy during master data maintenance and copies it to the SD document. The separators used in the template cannot be used in the product hierarchy.

Note

Via a matchcode you can search specifically for material master records with a product hierarchy.

Analyze the product hierarchies in your organization and define their representation in the SAP System.

    1. Assign a characteristic value to the individual levels of your product hierarchy: a 5-character value to levels 1 and 2, and an 8-character value to level 3. The level number is determined automatically.
    A product hierarchy node encompasses a characteristic value of a maximum of 18 characters.
    2. Enter a description for the product hierarchy.

Actions concerning the field catalog for pricing

The product hierarchy can be used for functions in pricing. Then the fields of the product hierarchy structure must be entered into the field catalog for pricing.

Enter the fields of the product hierarchy in the field catalog.

Actions concerning the field catalog for Logistics Controlling

The product hierarchy can be used for statistical analyses in the Logistics Information System. The fields of the product hierarchy structure must then be entered in a field catalog for the Logistics Information System.

Enter the product hierarchy in a field catalog. You can refer to field catalog ‘VPHI’, which displays the standard settings.

*Courtsey – SAP help 

How Pricing flows

1. The system determines the pricing procedure according to information defined in the sales

document type and the customer master record.

2. The pricing procedure defines the valid condition types and the sequence in which they

appear in the sales order. In the example, the system takes the first condition type (PR00) in

the pricing procedure and begins the search for a valid condition record.

3. Each condition type in the pricing procedure can have an access sequence assigned to it. In

this case, the system uses access sequence PR00. The system checks the accesses until it

finds a valid condition record. (Although you cannot see this in the diagram, each access

specifies a particular condition table. The table provides the key with which the system

searches for records).

4. In the example, the first access (searching for a customer-specific material price) is

unsuccessful. The system moves on to the next access and finds a valid record.

5. The system determines the price according to information stored in the condition record. If a

pricing scale exists, the system calculates the appropriate price. In the example, the sales

order item is for 120 pieces of the material. Using the scale price that applies to quantities

from 100 pieces and more, the system determines a price of USD 99 per piece.

The system repeats this process for each condition type in the pricing procedure determines a

final price.

One Line Item per invoice

There is a standard routine provided by SAP for this. We just need to assign routine 6 at (copy control delivery to billing) data transfer VBRK/VBRP and maintain TVKO_MAXBI (Max no. of line items in invoice) = 1.

Purpose

This is an example of a data transfer routine.  FORM routines for data transfer allow you to fine tune the transferred fields during the copying process.  This requirement is used to limit the number of line items allowed in any single billing document.

Example

In some countries there are government regulations that state that there is a limit as to the maximum number of lines that can be in any single invoice document.  In order to insure that this regulation is adhered to, this requirement can be assigned to the billing item category and the appropriate limits maintained in configuration.

Procedure – Define a max number of line items in the IMG and then force an automatic split based on this using a copy control routine, email me if you have any problems, details are below.

IMG
Sales & Distribution>Billing>Billing Documents>Country Specific Features>Maintain Maximum Number of Billing Items
Enter the country code creating billng document and the Max allowed number of billing items (note problem is on the FI side so I’d advise 450 items or less).

In the copy control routine from your Delivery Doc or Sales Doc to your billing type at item category level enter the following code to force a split based on the max number of items you’ve defined. Adjust to suit any other internal requirements. This is SAP standard and works fine.

*———————————————————————*
* Data transfer for delivery related billing *
*———————————————————————*

*———————————————————————*
* FORM DATEN_KOPIEREN_633 *
*———————————————————————*
* —> VBAK Order header KUAGV View Sold-to *
* VBAP Order item KURGV View Payer *
* VBKD Business data order KUREV View Bill-to *
* LIKP Delivery header KUWEV View Ship-to *
* LIPS Delivery item *
*———————————————————————*

DATA: BEGIN OF ZUK2,
MODUL(3) VALUE ‘006’,
VTWEG LIKE VBAK-VTWEG,
SPART LIKE VBAK-SPART,
VGBEL LIKE VBRP-VGBEL,
BILLNO LIKE TVKO-MAXBI,
END OF ZUK2.

DATA: BEGIN OF J_1B_SIZE_SPLIT2 OCCURS 0,
KUNRG LIKE VBRK-KUNRG,
KUNAG LIKE VBRK-KUNAG,
ZTERM LIKE VBRK-ZTERM.
INCLUDE STRUCTURE ZUK2.
DATA: ITEMNO LIKE TVKO-MAXBI.
DATA: END OF J_1B_SIZE_SPLIT2.

DATA: J_1B_SIZE_COPY2 LIKE J_1B_SIZE_SPLIT2.

*———————————————————————*
* FORM DATEN_KOPIEREN_633 *
*———————————————————————*
* This is a clone of routine 003. *
* It will ensure that *
* *
* — one billing document can only have one reference document *
* — the sum of item volumes will not exceed the amount *
* specified in the number of billing doc. items for the *
* sales organization (TVKO-MAXBI) *
*———————————————————————*

FORM DATEN_KOPIEREN_633.
CLEAR: VBRK-EXPKZ, VBRK-EXNUM.

VBRK-BZIRK = SPACE.
VBRK-KDGRP = SPACE.
VBRK-KONDA = SPACE.
VBRK-REGIO = SPACE.
VBRK-PLTYP = SPACE.

* If maximum number of billing items active
IF NOT TVKO-MAXBI IS INITIAL.

* Get billing doc. item number split data
READ TABLE J_1B_SIZE_SPLIT2
WITH KEY KUNRG = VBRK-KUNRG
KUNAG = VBRK-KUNAG
ZTERM = VBRK-ZTERM
VGBEL = VBRP-VGBEL.
IF SY-SUBRC <> 0.
CLEAR J_1B_SIZE_SPLIT2.
MOVE-CORRESPONDING VBRK TO J_1B_SIZE_SPLIT2.
MOVE-CORRESPONDING VBRP TO J_1B_SIZE_SPLIT2.
ENDIF.

* Check number of billing items against max. defined by tvko-maxbi
IF J_1B_SIZE_SPLIT2-ITEMNO < TVKO-MAXBI.
J_1B_SIZE_SPLIT2-ITEMNO
= J_1B_SIZE_SPLIT2-ITEMNO + 1.
ELSE.
J_1B_SIZE_SPLIT2-BILLNO
= J_1B_SIZE_SPLIT2-BILLNO + 1.
J_1B_SIZE_SPLIT2-ITEMNO = 1.
ENDIF.

* Store actual billing document counter and item counter
READ TABLE J_1B_SIZE_SPLIT2 INTO J_1B_SIZE_COPY2
WITH KEY KUNRG = VBRK-KUNRG
KUNAG = VBRK-KUNAG
ZTERM = VBRK-ZTERM
VGBEL = VBRP-VGBEL.
IF SY-SUBRC = 0.
MODIFY J_1B_SIZE_SPLIT2
TRANSPORTING ITEMNO BILLNO
WHERE KUNRG = VBRK-KUNRG
AND KUNAG = VBRK-KUNAG
AND ZTERM = VBRK-ZTERM
AND VGBEL = VBRP-VGBEL.
ELSE.
APPEND J_1B_SIZE_SPLIT2.
ENDIF.

* Add billing doc. number to split criteria
ZUK2-BILLNO = J_1B_SIZE_SPLIT2-BILLNO.

ENDIF.
* End of billing document split by number of allowed items

ZUK2-VTWEG = VBAK-VTWEG.
ZUK2-SPART = VBRP-SPART.
IF KURGV-PERFK = SPACE.
ZUK2-VGBEL = VBRP-VGBEL.
ENDIF.
VBRK-ZUKRI = ZUK2.
VBRK-KUNAG = VBRK-KUNRG.
ENDFORM.