RFBIDE00: Batch Input Interface for Customers

The RFBIDE00 batch input program is used for:

  • Creating and changing customer master data
  • Creating and changing credit limit data
  • Creating bank master data

Note

Structures:

  • Information that affects the entire batch input session is defined in the session prefix.
  • Information that applies to an entire transaction is defined in the header record. For example, this is the transaction code and key.
  • Finally, a batch input structure was created in the Data Dictionary for every customer table for which batch input is possible.

Every structure is identified by record type and possible table name.

The structures are:

  • BGR00  record type 0 session prefix
  • BKN00  record type 1 customer header data
  • BKNA1  record type 2 general data for customers
  • BKNVA  record type 2 unloading points
  • BWRF12 record type 2 receiving points
  • BWRF4  record type 2 departments
  • BKNVK  record type 2 contact partner
  • BKNBK  record type 2 bank details, including new bank master data
  • BKNB1  record type 2 company code data
  • BKNB5  record type 2 dunning data
  • BKNEX  record type 2 foreign trade
  • BKNKA  record type 2 central credit limit
  • BKNKK  record type 2 control area credit limit
  • BKNVV  record type 2 sales area data
  • BKNVD  record type 2 messages
  • BKNVI  record type 2 taxes
  • BKNVL  record type 2 licenses
  • BKNVP  record type 2 partner functions
  • BKNZA  record type 2 alternative payer
  • BKNBW  record type 2 withholding tax

Country-specific structures:

  • BKNAT  record type 2 tax categories (South America)

Address structure for consumers (account group 0170):

  • BIADDR2 record type 2 consumer address

Special character NODATA:

For every field which is transferred in batch input structure, you must be able to decide whether the value of the field is initial (for example, the field should be reset to the initial value), or whether no batch input at all is necessary for this field.

This means that, a special character must be specified which has the function:  “No batch input for this field”.

This special character is the character / by default.

If the special character ‘/’ is not to be used, you can specify another special character to carry out this function in the session prefix in field BGR00-NODATA.

Before filling the batch input structure, every field of the structure (with the exception of the session prefix BGR00) must be filled with this special character at the beginning of the field.

The fields of the structures refer to data elements of the fields of the original tables. However, numeric and packed fields are an exception. These need separate data elements of category CHAR for batch input, since packed fields cannot be preset with a special character.

That means that amounts with a decimal point can be transferred to the interface.

End of record marker:

If a batch input structure is later extended, the new end of the structure is indicated by a special field (SENDE). If you are already working with the new, extended structure, you must also supply this field with the NODATA indicator when “initializing” the structure. As a result, the system can recognize whether the data is based on the old or the new structure when the structure is imported.

Old structures can no longer be processed and the system terminates with an error message if the following prerequisites are fulfilled:

  • You are using the modification-free enhancement of the customer/vendor master either directly or indirectly via an SAP solution.
  • Either you or an SAP solution extends the structure.

Special fields in the session prefix:

The batch input session name (BGR00-GROUP) must been given in the batch input session. Sending a second session prefix closes the current session and opens an additional session.

In the session prefix, the special character NODATA can be transferred (see above).

A block date can be transferred in the session prefix (BGR00-START). If this date is set, it must have the format “YYYYMMDD”.

Additional address fields:

There are additional address fields available due to linking the customer and vendor master and the respective contact person to central address management. This additional address information is stored in central address management’s own tables not in the actual master tables (KNA1 for the customer master, LFA1 for the vendor master, KNVK for the contact person).

A separate transfer run via the ALE interface is needed to transfer this additional address information. This run should be before the transfer run for master data.

If you use number ranges with internal number assignment when creating new customer and vendor masters, the number which is used to identify the master object in the system must be determined beforehand due to address information and master data being transferred separately.

You can determine the numbers using the following BAPIs:

  • BAPI_VENDOR_GETINTNUMBER (for the vendor master)
  • BAPI_CUSTOMER_GETINTNUMBER (for the customer master)
  • BAPI_PARTNEREMPLOYEE_GETINTNUM (for the contact person)

Master data fields for which there is a counterpart in central address management (such as name, street, or telephone number) continue to be filled in the actual master tables. The formatting for these fields within central address management is different from the original formatting of the fields without the link to central address management. We therefore recommend that you only transfer the data for such fields when transferring central address management address information.

Consumer address fields:

Since the consumer has a private address instead of a company address, the address fields cannot be filled from the customer master table (KNA1). Instead, structure BIADDR2 provides the consumer address fields with the information required. A central address management address is automatically created when you run the batch input session.

The personal data of the consumer (sex, date of birth, marital status) does not belong to the address structure and can be entered in structure BKNVK as follows:

  • Sex in field BKNVK-PARGE
  • Date of birth in field BKNVK-GBDAT
  • Marital status in field BKNVK-FAMST

The remaining fields in structure BKNVK must be filled with the special character NODATA.

Programs:

  • RFBIDE00   Executable batch input program
  • RFBIDE01   Basic program with processing logic
  • RFBIDEG0   Generation program

The generation program RFBIDEG0 uses the frame RFBIDE01 and writes the coding contained in it together with the newly generated coding to the batch input program RFBIDE00.

Source code for the “field transports” is generated by the generation program per screen and per input field.

Transactions supported:

The following central transactions are supported in the present version:

  • XD01 Create customer
  • XD02 Change customer
  • XD05 Block/unblock customer
  • XD06 Set/cancel customer deletion flag
  • FD32 Maintain credit limit

With the creation and change transaction, transferred block fields or delete flags are also processed. The system then goes to the additional screens provided for this.

Block fields can only be processed with block transaction XD05.

Delete flags can only be processed with delete transaction XD06.

For all bank details to be processed, the structure BKNBK must be transferred. If existing bank details are to be deleted, the field BKNBK-XDELE must be marked.

If the bank master data of bank details is new, the data for this bank can also be transferred in structure BKNBK. The new bank master data is then created when processing the session.

You can only change the key fields Bank country key (BANKS), Bank key (BANKL), and Bank account number (BANKN) for bank details (table KNBK) by deleting the old bank details and creating a new set of bank details.

For every unloading point/contact person/receiving point/department/tax /license/message/partner function to be processed, the structure BKNVA/BWRF12/BWRF4/BKNVK/BKNVI/BKNVL/BKNVD/BKNVP must be transferred. If a record is to be deleted, the XDELE field is to be marked in the relevant structure.

For unloading points, note that either a goods receiving hours ID (BKNVA-WANID) or goods receiving hours can be transferred (BKNVA-MOAB1, BKNVA-MOAB2, and so on).

For contact persons, note that you do not have to specify a partner number (internal number assignment). If you do specify a number, the number must not have already been assigned for a different customer (termination).

For taxes, only “valid” records may be transferred, that is, BKNVI-ALAND must be the country of the sales organization or one of the plants belonging to it, and BKNVI-TATYP must be allocated to this country via table TSTL. These two fields must be transferred. Furthermore, note that the tax classification BKNVI-TAXKD for the tax type is permitted (table TSKD).

When transferring tax data using batch input, you should also note that the data is always transferred to the step loop screen 1350 of module pool SAPMF02D. This is also the case if there is only one relevant tax rate (country/tax type/tax classification). In this case, screen 1350 would not apply online and the tax classification would be maintained on screen 0320 (billing document).

In batch input, however, tax data must never be transferred to screen 0320, otherwise a termination occurs.

Screen 1350 follows screen 0320 in the process flow. The complete datasets (KNVI-ALAND, KNVI-TATYP and KNVI-TAXKD) are to be transferred in each case. You should consider the tax determination, and in particular the contents of table KNVI before structuring the batch input process online.

For licenses, the same applies as for taxes on the validity of country and tax type (BKNVL-ALAND, BKNVL-TATYP).

The alternative payers can be transferred in the BKNZA structure as either company code-specific or cross-company code. By entering a BLANK in the BKNZA-BUKRS field or by selecting the NODATA indicator, you can define an alternative payer as cross-company code. By selecting the BKNZA-XDELE field, you can delete the alternative payer.

Generation of record layouts:

You can generate record layouts via the Tools in the Financial Accounting Customizing menu. Alternatively, you can go directly from here into customizing Proceed. For a description of this function, see the IMG of the menu bar option.

You May Also Like

Leave a Reply?