Title
Transfer of requests from previous procedures

Purpose
The program RFBIBLK0 posts request documents that were entered outsidethe SAP system. The data to be transferred is stored in a sequentialfile with the structure described below and imported by the program.

Features
Only the Direct Input Procedure is available as a data transfer type.With the Direct Input Procedure, no screens are processed, but thedocuments are posted directly by calling up function modules.
The transactions FB01 (posting documents) and FBV1 (parking documents)are supported.

Precautions in case of error
Because 'the Direct Input' posts the documents into the SAP systemimmediately, precautions have to be taken that make it possible torestart the program after a program termination. This restart, in thefollowing called restart mechanism, serves to prevent a double postingof documentse when you start the program again.
To use the restart mechanism, you proceed as follows:

• First create a variant for the program RFBIBLK0.

IF &DEVICE& = 'SCREEN'
Execute function
ENDIF

• Define a restartable JOB.

IF &DEVICE& = 'SCREEN'
Execute function.
ENDIF

• Start the restartable JOB.

IF &DEVICE& = 'SCREEN'
Execute function.
ENDIF
Prerequisites for the restart mechanism:

• The entry file may contain no formal errors. You can ascertain this by
the 'Check file' parameter. The restart mechanism cannot be used with atermination due to a formal error. You then have to find out whichdocuments were posted up to the termination and then reduce the filecorrespondingly.

• The program may only be imported in the way described above.

You can use Direct Input without the restart mechanism for testpurposes. In this case, however, the entry file may not contain morethan 20 documents. However, a restart after a program termination is notthen possible.

Structures


• Information affecting the whole file with the documents to be posted is
defined in the session header record.

• Information applying to a whole document is defined in the header
record.

• The document fields for the remaining document data (document item data,
document taxes etc) are defined in their own data dictionary structures.
Each structure is identified by record type and perhaps table name.
The individual structures are:

• BGR00 Record type 0 session header record


• BBKPF_FM Record type 1 header data


• BBSEG_FM Record type 2 document segment data (incl. CpD-Daten,
COBL-Daten)

• BBTAX_FM Record type 2 document taxes

For each field transferred in one of the structures, it must be possibleto decide if the value of the field is initial (e.g. field is to bereset to initial value) or if no input is necessary for this field atall. You also have to agree a special character that has the function:'No input for this field'. The default for this special character is thecharacter '/'.
If the special character '/' is not to be used, you can specify in thesession header record in the field BGR00-NODATA which other specialcharacter is to fulfil this function.
Before filling the structures, each of the fields (except the sessionheader record BGR00) must be 'prepared' with this special character atthe beginning of the field.
The fields of the structures refer to the data elements of the fieldsfrom the original table. However, the numerical and packed fields areexceptions. These need their own data elements of the type Typ CHAR forthe input because packed fields cannot be 'initialized' with a specialcharacter. This means that amounts with a decimal point can betransferred to the interface.

Which Data has to be Transferred?
For each document, a document header (BBKPF_FM) and for each line item,a BBSEG_FM -structure has to be transferred. You define the external orinternal number assignment in field LOTEXNO.
The first document segment BBSEG, following the document header data,usually contains the subledger account item. In case of a clearingrequest, the first document segment contains the line item of a senderor receiver FM account assignment.
If entry values exist for the following fields, you enter them on thefirst document segment: PSOEA, PSOOB, MABER, REBZG, REBZJ, ZFBDT, ZLSPR,UZAWE, SKFBT, WSKTO.
If you are posting to a one-time account or a different payer is to bespecified, then you enter the appropriate data likewise on the firstdocument segment.
You enter the data of the offsetting entry on the remaining documentsegments. In the case of a clearing request, this is the posting data ofreceiver or sender FM account assignments.
You can specify application of funds and reservation documents for eachsubledger account item.
You also enter account assignment objects, commitment item, funds centerand fund on the G/L account item. If a mask was defined in the systemfor the substructuring of the commitment item key, then you must notethat the field 'FIPEX' has to be filled in with the commitment itemwithout special character. The field 'FIPOS' is no longer used.

Notes on special functions of the request

Entering Tax Amounts
In order to consider sales taxes, the appropriate tax amounts can beentered in the the structure BBTAX_FM. It is not possible to calculatethe taxes automatically. You therefore have to enter the respectiveabsolute tax amounts in the BBTAX_FM structure. Those tax codes arecurrently supported that are also allowed when posting requestsmanually.

Deferral, Short-Term Waiver and Remission
When posting a deferral, a short-term waiver or a remission, you mustrefer to the original document via the fields REBZG, REBZJ and REBZZ.The original document is imported first, then the fields are filled withnew values that may be changed with deferral, or short-term waiver andremission. If there is a field status, it is also considered here.
With a deferral document, the posting keys correspond to those of anacceptance request. Several deferral requests can be grouped together ina deferral request using a uniform request number.
With short-term waiver and remission, you specify the same posting keysas with deduction of an acceptance request.
On the initial screen of program RFBIBLK0, you can specify the 'numberof documents per Commit Work'. This means that a database transactiongenerally comprises posting of several documents. Due to correspondingblock mechanisms, you should avoid the posting of a deferral documentand the corresponding deferred document within one database transaction.The same applies to short-term waivers and remissions. If you createdocuments with invoice reference and use the follow-on document category"F", you must likewise ensure that the original document has alreadybeen posted.

Invoice Reference
If you create documents with invoice reference and use the follow-ondocument type 'F' for this, you must also ensure that the originaldocument has already been posted.

Field Status
The ready for input status of fields when entering requests online canbe controlled per document type via a field status. An existing fieldstatus is considered by the program RFBIBLK0.
With deferrals, short-term waivers or remissions, only those fields arefilled in that are controlled as required or optional entry fields bythe field status. For the remaining request, the fields marked asrequired entry fields via a field status are checked.

Allocating a Request Number
In IMG activity Define Company Code Groups ,you can control whether you want to bundle requests in program RFBIBLK0.
If the indicator Without request number is set for a company codevariant, no request number is allocated, irrespective of whetherretroactive bundling was selected in the global settings or not.
If the indicator Without request number is not set, the programevaluates the global setting for the retroactive bundling.
You have the following options for allocating the request number,depending on the fields
LOTKZ (request number)
XLOTE (request number already exists)
LOTEXNO,,Number assignment internal or external
of the structure BBKPF_FM


• LOTKZ is filled, XLOTE = empty, LOTEXNO = 'X':

Request is created with the external request number

• LOTKZ is filled, XLOTE = 'X', LOTEXNO = 'X':

Request is created with the external request number; a check is carriedout to see if the request number already exists

• LOTKZ is empty, XLOTE = empty, LOTEXNO = empty:

Request is created with an internal request number

• LOTKZ is filled, XLOTE = empty, LOTEXNO = empty:

Request is created with an internal request number All requests forwhich the field LOTKZ is filled in a uniform way, are bundled under thesame internal request number, that is, the contents of the field LOTKZserves to group together requests under a uniform request number.

• LOTKZ is filled, XLOTE = 'X', LOTEXNO = empty:

Request is created with the specified request number. This enables youto add a request subsequently to an already internally allocated requestnumber.

Documents with errors processed further
Note: The program is not terminated if there are documents witherrors in the file. The faulty documents can be processed subsequently.You can save these faulty documents in a batch input session for this.
The clearing requests use a special solution. They cannot be saved in abatch input session; they can only be saved in an external file. You canthen process the newly generated file subsequently using reportRFBIBLK0.

Creating an enhanced log
If you select the indicator Enhanced log on the initial screen,the log file is displayed with all errors and success messages.Otherwise only the error messages are displayed in the log.

Generating table descriptions:
You can use transaction OBE8 to generate tabledescriptions for other programming languages.