ABAP Development for Materials Management in SAP (第6页)

第 128 页 / 共 275 页

5 User Exits and BAdIs in Inventory Management

date is possible. For other goods deliveries, a delivery of up to three days prior to

the delivery date is permitted.

1. Create a new project in Transaction CMOD, and include the enhancement

MEFLD004.

2. Switch to the user exit EXIT_SAPLEINR_004, and create the include ZXM06U54.

3. In the interface of the exit, the purchase order header (EKKO) and the purchase

order item to be checked (EKPO) are transferred. Based on this data, you can

overwrite the earliest delivery date (parameter FRLFD). The field FRLFD already

contains the delivery date from the purchase order. You can therefore leave the

content unchanged, if no special rule applies.

Check whether the vendor (EKKO-LIFNR) has the number 1002 (look out for

leading zeros); if yes, the purchase order date (EKKO-BEDAT) will apply as the

earliest delivery date.

4. Check whether the purchase order item has the material group 003; if yes, a

goods receipt of up to seven days prior to the delivery date is expected to be

possible. Because the field FRLFD already contains the delivery date from the

purchase order, you can simply deduct seven days.

For all other items, the goods receipt can take place three days earlier. Also

carry out the respective calculation (see Listing 5.26). Don’t forget to activate

the project so that your user exit will run.

*&-----------------------------------------------------------*

*& Include ZXM06U54

*&-----------------------------------------------------------*

*“*“Local interface:

*“ IMPORTING

*“ VALUE(EKKO) TYPE EKKO

*“ VALUE(EKPO) TYPE EKPO

*“ CHANGING

*“ VALUE(FRLFD) LIKE EBEFU-FRLFD

*“------------------------------------------------------------

* Determine earliest delivery date dynamically

IF ekko-lifnr = ‘0000001002‘.

* Vendor 1002 is allowed to deliver earlier indefinitely,

* however, not before the purchase order date

frlfd = ekko-bedat.

128

© 2013 by Galileo Press Inc., Boston (MA)

第 129 页 / 共 275 页

Tolerance Limits for Scheduling Agreements 5.5

ELSE.

* Item for material group 003?

IF ekpo-matkl = ‘003‘.

* Goods receipt can take place seven days earlier

frlfd = frlfd – 7.

ELSE.

* Goods receipt can take place three days earlier

frlfd = frlfd – 3.

ENDIF.

ENDIF.

Listing 5.26 Coding on User-Exit EXIT_SAPLEINR_004

5.5 Tolerance Limits for Scheduling Agreements

Using the current date, the default quantity and tolerance check quantity are deter-

mined from the schedule lines when goods receipts are posted according to sched-

uling agreements. If no tolerances are permitted in the scheduling agreement, and

the vendor occasionally delivers a few days too early, you receive an error message

in the goods receipt (see Figure 5.8).

Figure 5.8 Exceeding the Tolerance Levels

If your vendor is allowed to deliver the goods, for example, up to three days ear-

lier, you may use the user exit EXIT_SAPLEINR_001 of the enhancement MEVME001

to determine the default quantity and tolerance levels dynamically.

5.5.1 Overwriting Overdelivery Quantity

Let’s first take a look at the scheduling agreement schedule in Figure 5.9. Items 1

and 2 have each a scheduled quantity of 10 pieces. A goods receipt of more than

12 pieces has already been posted. Item 1 is therefore complete; for item 2, there

is still an open quantity of 8 pieces.

129

Personal Copy for Yang Meteor, user id a8103f58-81fe-4f49-acf6-cfb58959c618

第 130 页 / 共 275 页

5 User Exits and BAdIs in Inventory Management

Figure 5.9 Scheduling Agreement Schedule

On July 6, 2010, another goods receipt of more than 43 pieces is now supposed

to be posted. The open quantity consists of the 5 pieces scheduled for delivery on

July 5, 2010, and also of the 8 pieces still open from the previous items. A total of

13 pieces are open. The goods receipt is therefore rejected due to an overbooking

of 30 pieces (43 pc – 13 pc). The vendor has already added the 30 pieces, which

are expected on July 8, 2010 — that is, in the future. Because this is within the 3

days for which you allow an earlier delivery, the goods receipt is expected to go

through.

1. To resolve this situation, you must program the aforementioned user exit EXIT_

SAPLEINR_001. Create a project in Transaction CMOD, and add the enhance-

ment MEVME001.

2. Switch to the user exit EXIT_SAPLEINR_001, and create the include ZXM06U28.

3. You get two parameters in the interface: The parameter POT contains the item

data from the scheduling agreement; the internal table CETT contains all sched-

ule lines. Based on this data, you can perform your own calculations and fill

the parameters according to Table 5.12. Keep in mind that these parameters

in the documentation on the enhancement MEVME001 are not completely and

uniquely defined. The parameters F3 and F4 have only been added with SAP

Note 737495; the documentation has not been customized, however.

130

© 2013 by Galileo Press Inc., Boston (MA)

第 131 页 / 共 275 页

Tolerance Limits for Scheduling Agreements 5.5

Parameter Description

F1 WE default quantity

F2 Open quantity on key date

F3 Underdelivery quantity

F4 Overdelivery quantity

Table 5.12 Output Parameter EXIT_SAPLEINR_001

4. Because the overdelivery quantity is customized, you need to determine a new

value for parameter F4. The calculation for this works very simply. The param-

eter contains the complete scheduled quantity, starting from the first item of

the scheduling to the last scheduling prior to the key data in total. The system

automatically deducts goods receipts already carried out, so you don’t need to

take this into consideration.

Calculate in a loop via Table CETT the total of all schedule quantities with one

vendor smaller than the date “today + 3 days”. You write the result of the calcu-

lation in the field F4 (see Listing 5.27).

*&-----------------------------------------------------------*

*& Include ZXM06U28

*&-----------------------------------------------------------*

*“*“Local interface:

*“ IMPORTING

*“ VALUE(POT)

*“ TABLES

*“ CETT STRUCTURE EKET

*“ CHANGING

*“ VALUE(F1)

*“ VALUE(F2)

*“ VALUE(F3) OPTIONAL

*“ VALUE(F4) OPTIONAL

*“------------------------------------------------------------

* Local declarations

DATA lv_menge TYPE eket-menge.

DATA lv_checkdate TYPE eket-eindt.

* Consider schedules until today + 3 days

lv_checkdate = sy-datlo + 3.

* Total all schedule quantities

131

Personal Copy for Yang Meteor, user id a8103f58-81fe-4f49-acf6-cfb58959c618

Parameter Description
F1 WE default quantity
F2 Open quantity on key date
F3 Underdelivery quantity
F4 Overdelivery quantity

第 132 页 / 共 275 页

5 User Exits and BAdIs in Inventory Management

LOOP AT cett WHERE eindt <= lv_checkdate.

lv_menge = lv_menge + cett-menge.

ENDLOOP.

* Transfer of the calculated value as maximum limit

f4 = lv_menge.

Listing 5.27 Coding for EXIT_SAPLEINR_001

5.5.2 Overwriting Default Quantity

After the goods receipt that includes 43 pieces has been posted, the new situation

in the scheduling agreement is shown in Figure 5.10. As you can see, if there is no

longer any quantity open until and including July 8, 2010, the next goods receipt

is not expected again until July 11, 2010.

Figure 5.10 Scheduling Agreement Schedule following Goods Receipt

If you now receive a new delivery of more than 15 pieces on July 11, 2010, and

these are supposed to be posted as goods receipt, you receive the message “Docu-

ment contains no selectable item” if the user hasn’t activated the Propose All

Items option. You can react using the user exit: If an open scheduling exists within

the next three days, the first open quantity found is suggested. In the example

given, this quantity refers to the 15 pieces from July 11, 2010.

1. Navigate again to the user exit EXIT_SAPLEINR_001, and enhance the coding for

the current case. The field F2 contains the quantity of all schedulings up to and

132

© 2013 by Galileo Press Inc., Boston (MA)

第 133 页 / 共 275 页

Tolerance Limits for Scheduling Agreements 5.5

including today, minus the goods receipts already carried out. If this value is

zero, the line is not suggested. Check the value F2. If no quantity is suggested

here, you must calculate a new value.

2. Because the system has already checked all schedulings up to and including

the current date, you must check Table CETT again in a loop only from the day

“today + 1” until “today + 3”. The schedule quantity, as before in the field MENGE,

was carried out in the goods receipts in field WEMNG. Calculate the open quantity

from this. As soon as you find an open quantity, you can leave the loop.

3. You don’t need to assign the result of the calculation to the field F2. In fact,

the field F1 again contains the complete schedule quantity from the first day of

the scheduling agreement until today. The system deducts the goods receipts

already carried out only later from this figure. Simply add the result of your

calculation to the field F1. The line with your determined quantity is therefore

suggested (see Listing 5.28).

...

* Additional determination of the default quantity

* Further data declarations

DATA lv_morgen TYPE eket-eindt.

IF F2 = 0.

* No default quantity available, check whether an open

* schedule exists in the period today + 1 until today + 3

lv_morgen = sy-datlo + 1.

clear lv_menge.

LOOP AT cett WHERE eindt <= lv_checkdate AND

eindt >= lv_morgen.

lv_menge = cett-menge – cett-wemng.

IF lv_menge > 0.

* Open schedule available, exit loop

EXIT.

ENDIF.

ENDLOOP.

* Increase expected quantity for found value

F1 = F1 + lv_menge.

ENDIF.

Listing 5.28 Further Coding for EXIT_SAPLEINR_001

133

Personal Copy for Yang Meteor, user id a8103f58-81fe-4f49-acf6-cfb58959c618

第 134 页 / 共 275 页

5 User Exits and BAdIs in Inventory Management

4. Based on the situation from Figure 5.10, if you post a goods receipt on July 10,

2010, an item with a quantity of 15 pieces is suggested to you, which is the

value of the schedule of July 11, 2010.

5.6 Enhancement of Reservations

For reservations, you can’t use Transaction MIGO. As previously stated, reserva-

tions are created or changed in Transactions MB21 and MB22. Therefore, you

can’t use any enhancements for reservations, for example, the BAdI MB_MIGO_BADI,

to prepopulate fields or to carry out input checks. Even here there is some assis-

tance — the BAdI MB_RESERVATION_BADI.

This BAdI is essentially suitable for two situations. First, there is the method DATA_

MODIFY, which is called when an item is entered before the detail screen view (see

Figure 5.11) is displayed. You can use this method to prepopulate individual fields

with values. The method DATA_CHECK is then called. Here you have the option to

carry out custom checks and display, if applicable, a warning or error message.

Figure 5.11 Detailed Entry in the Reservation

134

© 2013 by Galileo Press Inc., Boston (MA)

第 135 页 / 共 275 页

Enhancement of Reservations 5.6

For both cases, a small example will help you implement these enhancements.

5.6.1 Prepopulating Fields

The prepopulation of fields via the method DATA_MODIFY works relatively simply.

However, you can’t overwrite all of the fields of the document. All fields of Table

5.13 can basically be overwritten. However, this list is further restricted by the

current field status. Fields that haven’t been integrated may also not be overwrit-

ten by the BAdI method. Therefore, internal Table IT_CHANGEABLE is transferred as

a parameter that contains all changeable fields. All changes you make in the BAdI

to fields not contained there are subsequently not copied.

Field Description

RESB-MATNR Material number

RESB-WERKS Plant

RESB-LGORT Storage location

RESB-CHARG Batch

RESB-SAKNR GL account number

RESB-ERFMG Quantity in unit of entry

RESB-ERFMG Unit of entry

RESB-BDMNG Requirement quantity

RESB-FMENG Characteristic: Fixed quantity

RESB-KZEAR Characteristic: Final issue of the reservation

RESB-XLOEK Item deleted

RESB-WEMPF Ship-to party

RESB-ABLAD Unloading point

RESB-SGTXT Item text

RESB-BDMNG Requirement date of the components

RESB-XWAOK Characteristic: Goods movement to the reservation

permitted

Table 5.13 Fields of the Reservation that Can Be Overwritten

Furthermore, the parameter I_NEW_ITEM exists, which means that this item will

run the first time in the method. If your prepopulation is only supposed to be a

135

Personal Copy for Yang Meteor, user id a8103f58-81fe-4f49-acf6-cfb58959c618

Field Description
RESB-MATNR Material number
RESB-WERKS Plant
RESB-LGORT Storage location
RESB-CHARG Batch
RESB-SAKNR GL account number
RESB-ERFMG Quantity in unit of entry
RESB-ERFMG Unit of entry
RESB-BDMNG Requirement quantity
RESB-FMENG Characteristic: Fixed quantity
RESB-KZEAR Characteristic: Final issue of the reservation
RESB-XLOEK Item deleted
RESB-WEMPF Ship-to party
RESB-ABLAD Unloading point
RESB-SGTXT Item text
RESB-BDMNG Requirement date of the components
RESB-XWAOK Characteristic: Goods movement to the reservation permitted

第 136 页 / 共 275 页

5 User Exits and BAdIs in Inventory Management

suggestion that can be overwritten by the user at any time via other values, then it

makes sense to check this parameter and to overwrite the field content only when

it is run for the first time.

You can find the complete parameter interface of the method DATA_MODIFY in Table

5.14.

Parameter Description

IT_CHANGEABLE Table of the changeable fields.

I_NEW_ITEM Current item is new and is handled the first time in the

method.

CS_RKPF Header data of the reservation. The fields of this structure

cannot be changed.

CS_RESB Structure on an item of the reservation; the fields

contained may be overwritten if the field is contained in

Table IT_CHANGEABLE.

Table 5.14 Parameters of the Method DATA_MODIFY

In a small example, the field GL account (RESB-SAKNR) is populated for all reserva-

tions in plant 1000 with the GL account number 400000.

1. Create an implementation for the BAdI MB_RESERVATION_BADI in Transaction

SE19. You can choose, for example, ZMB_RESERVATION_BADI as the name of the

implementation.

2. Now navigate to the method DATA_MODIFY. The GL account is only a default

value that can be overwritten by the user at any time. For this reason, the meth-

od is executed for an item only on the first run (i.e., before the detail screen for

an item may have been displayed the first time). Therefore, check the content

of I_NEW_ITEM, and exit the method if necessary.

3. Next, you must check whether the field may at all be changed. For this, check

whether the field is available in Table IT_CHANGEABLE.

This internal table is defined via a table type TDTAB_C132 in the ABAP Dictionary;

however, this is done without using a structure but instead via an integrated

data type. For this reason, the only field of this internal table doesn’t have any

defined name. However, you can always access the internal table via the field

name TABLE_LINE .

136

© 2013 by Galileo Press Inc., Boston (MA)

Parameter Description
IT_CHANGEABLE Table of the changeable fields.
I_NEW_ITEM Current item is new and is handled the first time in the method.
CS_RKPF Header data of the reservation. The fields of this structure cannot be changed.
CS_RESB Structure on an item of the reservation; the fields contained may be overwritten if the field is contained in Table IT_CHANGEABLE.

第 137 页 / 共 275 页

Enhancement of Reservations 5.6

4. When the checks are successful, you can overwrite the field value in the struc-

ture CS_RESB. A suitable example is given in Listing 5.29.

METHOD if_ex_mb_reservation_badi~data_modify .

* Prepopulate GL account

* Prepopulation is only to be a default value, therefore

* only execute item on first run

CHECK i_new_item IS NOT INITIAL.

* Check whether GL account is changeable

READ TABLE it_changeable WITH KEY table_line = ‘RESB-SAKNR’

TRANSPORTING NO FIELDS.

* Suggest GL account for plant 1000

IF sy-subrc = 0 AND

cs_resb-werks = ‘1000’.

cs_resb-saknr = ‘400000’.

ENDIF.

ENDMETHOD.

Listing 5.29 Coding on the Method DATA_MODIFY

5.6.2 Checking Entries

Custom input checks are also simple to implement. To implement your checks,

the header and item data are provided. To trigger a warning or error message, you

can work perfectly normally with the MESSAGE command, but you must trigger the

exception EXTERNAL_MESSAGE.

You can find the parameter interface of the method DATA_CHECK in Table 5.15.

Parameter Description

IT_CHANGEABLE This internal table again contains the list of current

changeable fields. This doesn’t usually play any major role

for this method.

IS_RKPF The header data of the reservation.

IS_RESB Structure on an item of the reservation.

I_NEW_ITEM Current item is new and is handled the first time in the

method.

Table 5.15 Parameters of the Method DATA_CHECK

137

Personal Copy for Yang Meteor, user id a8103f58-81fe-4f49-acf6-cfb58959c618

Parameter Description
IT_CHANGEABLE This internal table again contains the list of current changeable fields. This doesn’t usually play any major role for this method.
IS_RKPF The header data of the reservation.
IS_RESB Structure on an item of the reservation.
I_NEW_ITEM Current item is new and is handled the first time in the method.

第 138 页 / 共 275 页

5 User Exits and BAdIs in Inventory Management

As an example, the fields are supposed to be checked for the ship-to party (RESB-

WEMPF) and the unloading point (RESB-ABLAD). The specification of a ship-to party

is mandatory. If this specification is missing, it must be confirmed by an error

message. If there is no entry in the unloading point field, this is indicated by a

warning message.

1. Navigate to the implementation of the BAdIs that you created in the previous

example on method DATA_MODIFY. Then, switch to the method DATA_CHECK.

2. The method is only called for an item when the item is new or has been changed.

Therefore, the evaluation of the parameter I_NEW_ITEM isn’t absolutely neces-

sary. Check whether the ship-to party is filled, and display an error message. To

trigger the exception, you need the addition RAISING EXTERNAL_MESSAGE.

3. So that the message only appears for the unloading point, which is just a warn-

ing when the item is entered, but not in the case of each subsequent change,

you can at this point also check the parameter I_NEW_ITEM. If the parameter is

set, and the unloading point hasn’t been completed, a warning message is dis-

played. You must also use the addition RAISING EXTERNAL_MESSAGE with regard

to warning messages.

By displaying the warning message, you can always navigate to the detail screen

in which the unloading point can be entered. This is usually only shown when

an important piece of information is missing. You can find the relevant example

in Listing 5.30.

METHOD if_ex_mb_reservation_badi~data_check .

* The ship-to party must be filled.

IF is_resb-wempf is initial.

* Message: “Please specify a ship-to party“

MESSAGE e100(ZMM) RAISING external_message.

ENDIF.

* The unloading point should be filled

* Check only on initial run of item

IF i_new_item is not initial AND

is_resb-ablad IS INITIAL.

* Message: “Unloading point was not entered!“

MESSAGE w101(ZMM) RAISING external_message.

ENDIF.

ENDMETHOD.

Listing 5.30 Coding on the Method DATA_CHECK

138

© 2013 by Galileo Press Inc., Boston (MA)

第 139 页 / 共 275 页

6 User Exits and BAdIs in the Valuation

and Account Assignment Area

The settings for the valuation and account assignment aren’t part of any spe-

cial area in MM, but they are commonly used. The main topics at this point are

how stocks are valued and how transactions are posted to accounts in Financial

Accounting (FI).

The current enhancements in the valuation area and account assignment area are

rather simple and are used to influence the balance sheet valuation or the determi-

nation of lowest value. The possible customizations are so customer-specific here

that it hardly makes any sense to present one of these enhancements in detail.

However, the enhancement used to individually control the GR/IR account (clear-

ing account between goods receipts and invoice receipts) is frequently required by

customers, so we’ll be working with this enhancement in this chapter.

6.1 GR/IR Clearing Account

The GR/IR clearing account is posted to a purchase order upon goods receipt and

is again credited at a later point when posting the incoming invoice. Therefore,

you can view in this account how many incoming invoices are still outstand-

ing on already delivered goods. For this, you usually set a clearing account for a

transaction key WRX in the account determination that is used for all respective

postings.

You may want to use different GR/IR accounts due to specific dependencies. For

example, you might want to manage a custom GR/IR account for each of your

purchasing organizations to create differentiated evaluations. You can do this with

the enhancement LMR1M002, through which you can set the account modification

constant for the transaction key WRX, and choose the GR/IR account. The user exit

contained is called once with GR postings and incoming invoices for each purchase

order item; that is, you can have completely different GR/IR accounts within a

document.

139

Personal Copy for Yang Meteor, user id a8103f58-81fe-4f49-acf6-cfb58959c618

第 140 页 / 共 275 页

6 User Exits and BAdIs in the Valuation and Account Assignment Area

To use the account modification constant and several accounts, you must main-

tain the respective settings in the Customizing of the account determination. All

necessary customizing steps can be found in Transaction SPRO via the Materials

management • Valuation and Account Assignment • Account Determination •

Account Determination without Wizard path.

1. Choose the Customizing point Set Automatic Postings, and then click

Account Assignment. You can also directly access the maintenance via Trans-

action OBYC.

2. Scroll to Transaction WRX, and then double-click the respective line. You may

be asked for the chart of accounts for which the maintenance is supposed to

be carried out. Choose the chart of accounts that is assigned to your company

code.

3. If the column Gen. Modification (i.e., an account modification constant)

isn’t yet displayed, click Rules (make a note of the currently set accounts

beforehand).

4. Highlight the Gen. Modification option in the Accounts are specified depend-

ing on area, and save this change. You now get a warning message that the

current specification of accounts is deleted. Confirm this warning.

5. Enter the previously noted account settings again, and leave the Gen. Modifi-

cation column empty. This entry is used for the account determination when

the user exit doesn’t return any different account modification constant. You

will receive the same warning message as before.

6. You can now maintain other accounts by using different account modification

constants (see Figure 6.1).

Figure 6.1 Setting Different GR/IR Accounts

140

© 2013 by Galileo Press Inc., Boston (MA)

第 141 页 / 共 275 页

Overriding the Account Determination in the User Exit 6.2

6.2 Overriding the Account Determination in the User Exit

The purchase number (I_WRXMOD-EBELN) and the purchase order item (I_WRXMOD-

EBELP) are transferred to the user exit EXIT_SAPLKONT_011. Using these parameters,

you can read the complete purchase order data. You can then determine the account

modification constant depending on the purchase order data and then transfer this

to the output parameter E_KONTO_MODIF. You can also leave this output parameter

empty to use the standard account.

No Queries in the Transaction Code

You can specify the GR/IR account in this user exit depending on the purchase order

data in this user exit via the account modification. However, no logical check takes place

here, which means you are responsible for debiting the same account that is credited

with an incoming invoice for a purchase order item in the GR.

Therefore, you should not execute any queries in your coding in the transaction code;

that is, no other account modification constant is provided in transactions of Inven-

tory Management when you do this in transactions of Logistics Invoice Verification.

Otherwise, you don’t have any GR in an account that is never balanced, and you have

a negative balance in another account because this account was never debited with a

GR.

The user exits are programmed using the following steps. You can also see in List-

ing 6.1 how you can determine different data from the purchase order, even if not

all of the data determined is used for the specific example. You can see the listing

as a sample that you can customize for your own individual requirements. All pur-

chase order data are documented in detail in the coding.

1. Navigate to Transaction CMOD, and create a project, for example, ZMR1M002.

2. Assign the enhancement LMR1M002 to this project.

3. Now switch to components, and navigate to the user exit EXIT_SAPLKONT_011.

Overwrite the account modification constant with the desired value. You can

use Listing 6.1 as a sample for this.

*------------------------------------------------------------*

* INCLUDE ZXM08U18

*------------------------------------------------------------*

*”*”Local interface:

*” IMPORTING

*” VALUE(I_WRXMOD) LIKE WRXMOD STRUCTURE WRXMOD

*” EXPORTING

141

Personal Copy for Yang Meteor, user id a8103f58-81fe-4f49-acf6-cfb58959c618

No Queries in the Transaction Code
You can specify the GR/IR account in this user exit depending on the purchase order data in this user exit via the account modification. However, no logical check takes place here, which means you are responsible for debiting the same account that is credited with an incoming invoice for a purchase order item in the GR. Therefore, you should not execute any queries in your coding in the transaction code; that is, no other account modification constant is provided in transactions of Inven- tory Management when you do this in transactions of Logistics Invoice Verification. Otherwise, you don’t have any GR in an account that is never balanced, and you have a negative balance in another account because this account was never debited with a GR.

第 142 页 / 共 275 页

6 User Exits and BAdIs in the Valuation and Account Assignment Area

*” VALUE(E_KONTO_MODIF) LIKE T030-KOMOK

*------------------------------------------------------------*

* Data collection to obtain data of purchase order:

DATA: ls_ekko TYPE ekko,

ls_ekpo TYPE ekpo,

ls_ekpa TYPE ekpa,

lt_konv TYPE TABLE OF konv,

ls_konv TYPE konv.

* Read purchase order header

SELECT SINGLE * FROM ekko

INTO ls_ekko

WHERE ebeln = i_wrxmod-ebeln.

* Read purchase order item

SELECT SINGLE * FROM ekpo

INTO ls_ekpo

WHERE ebeln = i_wrxmod-ebeln AND

ebelp = i_wrxmod-ebelp.

* Read partner data

* Example header — invoicing party (in ls_ekpa-lifn2)

SELECT SINGLE * FROM ekpa

INTO ls_ekpa

WHERE ebeln = i_wrxmod-ebeln AND

ebelp = ‘00000’ AND

parvw = ‘RS’. “Partnerrolle

* Read conditions

SELECT * FROM konv INTO TABLE lt_konv

WHERE knumv = ls_ekko-knumv AND

kposn = i_wrxmod-ebelp.

* Internal table lt_konv now contains all conditions

* for item:

* LT_KONV-KSCHL = Condition Key

* LT_KONV-LIFNR = Freight vendor with corresponding conditions

* Set account modification constant

* Example: dependent on purchasing organization

CASE ls_ekko-ekorg.

WHEN ‘0001’.

e_konto_modif = ‘999’.

WHEN ‘1000’.

142

© 2013 by Galileo Press Inc., Boston (MA)

第 143 页 / 共 275 页

Overriding the Account Determination in the User Exit 6.2

e_konto_modif = ‘ASN’.

WHEN OTHERS.

CLEAR e_konto_modif.

ENDCASE.

Listing 6.1 Sample for the User Exit EXIT_SAPLKONT_011

4. Don’t forget to activate your project so that the coding is implemented. If you

now perform a posting on purchasing organization 1000, the ASN account

modification constant is set, and the different account 191110 is therefore post-

ed (see Figure 6.2).

Figure 6.2 Posting to a Different GR/IR Account

143

Personal Copy for Yang Meteor, user id a8103f58-81fe-4f49-acf6-cfb58959c618

第 144 页 / 共 275 页

© 2013 by Galileo Press Inc., Boston (MA)

第 145 页 / 共 275 页

7 User Exits and BAdIs in Logistics

Invoice Verification

An extensive range of user exits and BAdIs are available in Logistics Invoice Veri-

fication, that is, the entry of incoming invoices in MM. However, for some time,

it wasn’t possible to connect custom fields to an invoice document in Transaction

MIRO without modifying the system (see the upcoming box: Custom Fields via

Modification). This has changed with the technical Basis SAP ERP Central Com-

ponent 6.0. There finally exists a proper solution to integrate a custom subscreen

in the form of a BAdI. Nevertheless, this also has its pitfalls. For this reason, the

usage of this BAdI will take up much of this chapter. This is described in Section

7.1, Custom Fields in Transaction MIRO.

In Section 7.2, Overriding Tolerance Checks, you can also find an enhancement

with which you can dynamically overwrite the settings of the tolerance check in

Customizing.

7.1 Custom Fields in Transaction MIRO

With the BAdI MRM_ITEM_CUSTFIELDS, there is an option from SAP ERP Central

Component 6.0 to integrate a custom subscreen at an item level in the invoice

document. This section describes step-by-step how to use this BAdI and how com-

munication with your subscreen works.

Custom Fields via Modification

If you use a release prior to SAP ECC 6.0, you can also implement custom fields via

modification. The procedure for this is described in SAP Notes 352701 (Document Item)

and 174413 (G/L Account Tab). These notes describe how a field can be added by modi-

fying the standard dynpros and ABAP Dictionary structures.

You must also pay attention to fields in the G/L Account tab — the field with an identi-

cal name must be attached as an append structure to Table BSEG or it can’t be saved in

the database.

145

Personal Copy for Yang Meteor, user id a8103f58-81fe-4f49-acf6-cfb58959c618

Custom Fields via Modification
If you use a release prior to SAP ECC 6.0, you can also implement custom fields via modification. The procedure for this is described in SAP Notes 352701 (Document Item) and 174413 (G/L Account Tab). These notes describe how a field can be added by modi- fying the standard dynpros and ABAP Dictionary structures. You must also pay attention to fields in the G/L Account tab — the field with an identi- cal name must be attached as an append structure to Table BSEG or it can’t be saved in the database.

第 146 页 / 共 275 页

7 User Exits and BAdIs in Logistics Invoice Verification

The field must also be included in some control tables. You can access this via Transaction

OXK3. Here you choose the Account Assignment Fields • Expert Mode menu. Then

expand the Customer-Defined Account Assignments • Customer Include Structure •

CI_COBL area. Now move the cursor on the field concerned and choose the Account

Assignment Field • Add Control Entries • Test Run or Update Run menu option.

7.1.1 Overview of the Solution via BAdI

To map custom fields in the invoice document (see Figure 7.1), you need several

elements. To gain a better overview, you find a rough view of the processes in this

sub-chapter.

Figure 7.1 Custom Fields in the Invoice Entry

Follow these steps:

1. Define the actual dynpro that is to appear as a subscreen in the invoice docu-

ment. Please note, however, that this subscreen must map all available document

146

© 2013 by Galileo Press Inc., Boston (MA)

第 147 页 / 共 275 页

Custom Fields in Transaction MIRO 7.1

items. This means that you must create a table control in a custom dynpro in a

Z-program together with the necessary flow logic.

2. The subscreen must then be announced to the invoice document, so you must

enter the name of the previously created program and the dynpro number in

the BAdI implementation. You must also specify a name for the tabstrip. This

takes place in the BAdI method TABPAGE_LABEL_SET.

If you activate the BAdI implementation now, these two steps are already suf-

ficient to allow the subscreen to appear on the screen, when, for example,

Transaction MIRO is started. Additionally, the new input fields wouldn’t have

any further function.

3. The fields that are copied from your subscreen to the invoice document must

be created in the ABAP Dictionary structure CI_DRSEG_CUST. This structure is

already a component of the structure DRSEG_CI, which in turn is assigned to

the structure DRSEG. DRSEG is the central structure that maps all item fields of an

invoice document.

To store the fields also in the database, the fields with an identical name must

be attached as an append to the respective database table.

4. Now it’s time to bring the BAdI methods to life. The main task of the methods is

to establish communication between the item structure DRSEG and your dynpro.

For this, the previously mentioned methods are automatically called in Table

7.1 in the called sequence.

Step Method/Time Description

1. CUSTOMDATA_MODIFY This is the first called method of the BAdI. It

is implemented as soon as the custom tabstrip

has been selected. You can use this method to

prepopulate custom fields with data.

2. INVOICE_DATA_ This method runs next. Here, you prepare the

TRANSFER data, which is to be displayed in the dynpro, in

the attributes of the class.

3. Display of the dynpro The dynpro is now displayed and can be

maintained by the user.

4. CUSTOM_DATA_GET As soon as the user triggers an action, this

method is called. Here, you must retrieve the

data prepared and possibly changed by the

dynpro and write back to the data model.

Table 7.1 BAdI Call in a Dialog Step

147

Personal Copy for Yang Meteor, user id a8103f58-81fe-4f49-acf6-cfb58959c618

Step Method/Time Description
1. CUSTOMDATA_MODIFY This is the first called method of the BAdI. It is implemented as soon as the custom tabstrip has been selected. You can use this method to prepopulate custom fields with data.
2. INVOICE_DATA_ TRANSFER This method runs next. Here, you prepare the data, which is to be displayed in the dynpro, in the attributes of the class.
3. Display of the dynpro The dynpro is now displayed and can be maintained by the user.
4. CUSTOM_DATA_GET As soon as the user triggers an action, this method is called. Here, you must retrieve the data prepared and possibly changed by the dynpro and write back to the data model.

第 148 页 / 共 275 页

7 User Exits and BAdIs in Logistics Invoice Verification

5. Finally, you must still customize the flow logic of your dynpro to transfer or

return the previously prepared data to the table control. To do this, call the two

remaining methods of the BAdI from the flow logic. These methods are not

automatically started at a specified place but are used for data exchange with

your dynpro. You can find the exact procedure for this in Table 7.2.

Time Description

PROCESS BEFORE OUTPUT As soon as this part of the flow logic is started, you

must retrieve the data to be displayed. To do this,

(PBO)

call the method INVOICE_DATA_GET from the PBO.

This method provides you with the data that you

have already prepared via INVOICE_DATA_TRANSFER.

PROCESS AFTER INPUT After the user has triggered a dialog step, check

whether there has been any change. You write back

(PAI)

the new data to the BAdI (to later further process

the data in CUSTOM_DATA_GET) by calling the method

CUSTOM_DATA_TRANSFER.

Table 7.2 Overview of Flow Logic of Your Dynpro

As soon as you’ve implemented these steps, you can use your custom fields and

save these together with your document. In the following sections, we’ll look at

this procedure in detail again.

7.1.2 BAdI in Detail — Customizations in the ABAP Dictionary

In the following example, the two fields ZZTEXT_1 and ZZTEXT_2 are entered and

saved per item. Fields in the customer namespace should always start with a dou-

ble Z. Both fields use the data element CHAR32 that is available in every system.

As already described, the fields must first be included in the work structure DRSEG,

which is used for all items in the invoice document. The structure DRSEG already

contains an include DRSEG_CI with three defined fields and the include structure

CI_DRSEG_CUST. You can include your custom fields in this structure.

1. Navigate to the ABAP DictionaryABAP Dictionary (Transaction SE11), and edit

the structure CI_DRSEG_CUST (select DatA Type). This structure isn’t usually

available yet. You need to create it. Switch to the edit mode.

148

© 2013 by Galileo Press Inc., Boston (MA)

Time Description
PROCESS BEFORE OUTPUT (PBO) As soon as this part of the flow logic is started, you must retrieve the data to be displayed. To do this, call the method INVOICE_DATA_GET from the PBO. This method provides you with the data that you have already prepared via INVOICE_DATA_TRANSFER.
PROCESS AFTER INPUT (PAI) After the user has triggered a dialog step, check whether there has been any change. You write back the new data to the BAdI (to later further process the data in CUSTOM_DATA_GET) by calling the method CUSTOM_DATA_TRANSFER.

第 149 页 / 共 275 页

Custom Fields in Transaction MIRO 7.1

2. Enter the two fields ZZTEXT_1 and ZZTEXT_2, and use in each case the data ele-

ment CHAR32.

3. You can define the category Cannot be enhanced via the Extras • Enhance-

ment Category menu. It doesn’t matter too much if you don’t do this. You will,

however, receive a warning message on activation.

4. Save and activate your structure. It may take some time until it is activated

because all objects using the structure DRSEG are also regenerated.

5. Look at the structure DRSEG_CI. This should contain the fields as shown in Table

7.3. As you can see, besides your custom fields, the structure also contains the

item number to which your fields belong. Using the number, this structure

accurately describes a line of the document from your custom fields’ point of

view. You will therefore use this structure more frequently later on.

Field Name Description

C_RBLGP Item number of the document

C_KOART Account type:

EE A: Appendices

EE D: Debtors

EE K: Creditors

EE M: Material

EE S: GL accounts

C_MATNR Material number in account type M

ZZTEXT_1 Your first custom field

ZZTEXT_2 Your second custom field

Table 7.3 Structure DRSEG_CI

All prerequisites are now fulfilled to subsequently work with your fields within

the BAdI and in your dynpro. So that the data is also saved in the database, you

need to also attach the fields via append to the respective table. In Table 7.4, you

can see all the options provided for this.

149

Personal Copy for Yang Meteor, user id a8103f58-81fe-4f49-acf6-cfb58959c618

Field Name Description
C_RBLGP Item number of the document
C_KOART Account type: EE A: Appendices EE D: Debtors EE K: Creditors EE M: Material EE S: GL accounts
C_MATNR Material number in account type M
ZZTEXT_1 Your first custom field
ZZTEXT_2 Your second custom field

第 150 页 / 共 275 页

7 User Exits and BAdIs in Logistics Invoice Verification

Table/Structure Description

RSEG Database table to store the document items.

RBDRSEG Database table to temporarily store the document items in

the background check.

RBMA Database table to store the fields relating to the material.

COBL_MRM Structure of the account assignment fields (G/L Accounts

tab). Fields that you add to this structure are stored in the

database table RBCO.

Table 7.4 Tables for Storing Custom Fields

Because the fields ZZTEXT_1 and ZZTEXT_2 do not display any account assignment

information and aren’t material-related, they are to be saved in Table RSEG.

1. Display the database table RSEG in the ABAP Dictionary (Transaction SE11).

Then click the Append Structure button on the upper-right side.

2. In the selection window that appears, select the Create Append icon. You can

use, for example, ZZRSEG as the name for the append structure.

3. Specify the two fields ZZTEXT_1 and ZZTEXT_2. Make sure that the notation with

the field name of the structure CI_DRSEG_CUST is identical. You must also use

the same data element (CHAR32) for these fields (see Figure 7.2).

Figure 7.2 Append Structure ZZRSEG

4. Also maintain the enhancement category again here in the Extras • Enhance-

ment Category menu as cannot be enhanced.

150

© 2013 by Galileo Press Inc., Boston (MA)

Table/Structure Description
RSEG Database table to store the document items.
RBDRSEG Database table to temporarily store the document items in the background check.
RBMA Database table to store the fields relating to the material.
COBL_MRM Structure of the account assignment fields (G/L Accounts tab). Fields that you add to this structure are stored in the database table RBCO.

第 151 页 / 共 275 页

Custom Fields in Transaction MIRO 7.1

5. Save and activate the append structure.

When you use the background check and enter documents via Transaction MIRA,

which you then further process and schedule to the background check via Trans-

action MIR6 or MIR4, the item data is temporarily saved in Table RBDRSEG. Only

when the background check (Transaction MRBP) has been run with an error are

the records deleted again from Table RBDRSEG and saved in Table RSEG.

So that the custom fields can be entered at any time in this procedure, you should

also enhance Table RBDRSEG identically with Table RSEG custom fields.

7.1.3 Creating a Custom Dynpro with Table Control

Next, you also need the dynpro that will be integrated as a subscreen into the tab-

strip. You ideally pack this into a custom program in the form of a function group

or in a report of the type Module Pool.

1. Start Transaction SE80, and create a new program. For the sake of the example,

the name SAPMZMRM and program type Module Pool have been used (see Fig-

ure 7.3).

Figure 7.3 Module Pool for Inclusion of the Dynpro

151

Personal Copy for Yang Meteor, user id a8103f58-81fe-4f49-acf6-cfb58959c618

返回ABAP参考资料列表