Use
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 mustbe able to decide whether the value of the field is initial (forexample, the field should be reset to the initial value), or whether nobatch input at all is necessary for this field.
This means that, a special character must be specified which has thefunction: "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 anotherspecial character to carry out this function in the session prefix infield BGR00-NODATA.
Before filling the batch input structure, every field of the structure(with the exception of the session prefix BGR00) must be filled withthis special character at the beginning of the field.
The fields of the structures refer to data elements of the fields ofthe original tables. However, numeric and packed fields are anexception. These need separate data elements of category CHAR for batchinput, since packed fields cannot be preset with a special character.
That means that amounts with a decimal point can be transferred to theinterface.
End of record marker:
If a batch input structure is later extended, the new end of thestructure is indicated by a special field (SENDE). If you are alreadyworking with the new, extended structure, you must also supply thisfield with the NODATA indicator when "initializing" the structure. As aresult, the system can recognize whether the data is based on the oldor the new structure when the structure is imported.
INCLUDE FI_APAR_RFBIDE00_RFBKR00 OBJECT DOKU ID TX
Special fields in the session prefix:
The batch input session name (BGR00-GROUP) must been given in the batchinput session. Sending a second session prefix closes the currentsession 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). Ifthis date is set, it must have the format "YYYYMMDD".
Additional address fields:
There are additional address fields available due to linking thecustomer and vendor master and the respective contact person to centraladdress management. This additional address information is stored incentral address management's own tables not in the actual mastertables (KNA1 for the customer master, LFA1 for the vendor master, KNVKfor the contact person).
A separate transfer run via the ALE interface is needed to transferthis additional address information. This run should be beforethe transfer run for master data.
See Transfer of address data
If you use number ranges with internal number assignment when creatingnew customer and vendor masters, the number which is used to identifythe master object in the system must be determined beforehand due toaddress 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 addressmanagement (such as name, street, or telephone number) continue to befilled in the actual master tables. The formatting for these fieldswithin central address management is different from the originalformatting of the fields without the link to central addressmanagement. We therefore recommend that you only transfer the datafor such fields when transferring central address management addressinformation.
Consumer address fields:
Since the consumer has a private address instead of a company address,the address fields cannot be filled from the customer mastertable (KNA1). Instead, structure BIADDR2 provides the consumer addressfields with the information required. A central address managementaddress 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 instructure 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 specialcharacter 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 thecoding contained in it together with the newly generated coding to thebatch input program RFBIDE00.
Source code for the "field transports" is generated by the generationprogram per screen and per input field.
Transactions supported:
The following central transactions are supported in the presentversion:

• 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 ordelete flags are also processed. The system then goes to the additionalscreens 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 mustbe transferred. If existing bank details are to be deleted, the fieldBKNBK-XDELE must be marked.
If the bank master data of bank details is new, the data for this bankcan also be transferred in structure BKNBK. The new bank master data isthen created when processing the session.
You can only change the key fields Bank country key (BANKS),Bank key (BANKL), and Bank account number (BANKN) forbank details (table KNBK) by deleting the old bank details and creatinga new set of bank details.
For every unloading point/contact person/receiving point/department/tax/license/message/partner function to be processed, the structureBKNVA/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 therelevant structure.
For unloading points, note that either a goods receivinghours ID (BKNVA-WANID) or goods receiving hours can betransferred (BKNVA-MOAB1, BKNVA-MOAB2, and so on).
For contact persons, note that you do not have to specify apartner number (internal number assignment). If you do specify anumber, the number must not have already been assigned for a differentcustomer (termination).
For taxes, only "valid" records may be transferred, that is,BKNVI-ALAND must be the country of the sales organization or one of theplants belonging to it, and BKNVI-TATYP must be allocated to thiscountry via table TSTL. These two fields must be transferred.Furthermore, note that the tax classification BKNVI-TAXKD for the taxtype is permitted (table TSKD).
When transferring tax data using batch input, you should also note thatthe data is always transferred to the step loop screen 1350 of modulepool SAPMF02D. This is also the case if there is only one relevant taxrate (country/tax type/tax classification). In this case, screen 1350would not apply online and the tax classification would be maintainedon screen 0320 (billing document).
In batch input, however, tax data must never be transferred toscreen 0320, otherwise a termination occurs.
Screen 1350 follows screen 0320 in the process flow. The completedatasets (KNVI-ALAND, KNVI-TATYP and KNVI-TAXKD) are to be transferredin each case. You should consider the tax determination, and inparticular the contents of table KNVI before structuring the batchinput process online.
For licenses, the same applies as for taxes on the validity of countryand tax type (BKNVL-ALAND, BKNVL-TATYP).
The alternative payers can be transferred in the BKNZA structureas either company code-specific or cross-company code. By entering aBLANK in the BKNZA-BUKRS field or by selecting the NODATA indicator,you can define an alternative payer as cross-company code. By selectingthe BKNZA-XDELE field, you can delete the alternative payer.
Generation of record layouts:
You can generate record layouts via the Tools in the FinancialAccounting Customizing menu. Alternatively, you can go directly fromhere into customizing Proceed. For a description ofthis function, see the IMG of the menu bar option.