Ansicht
Dokumentation

RFBIBLK0 - Batch Input for Requests

Addresses (Business Address Services)   CL_GUI_FRONTEND_SERVICES - Frontend Services  
This documentation is copyright by SAP AG.

Title

Transfer of requests from previous procedures

Purpose

The program RFBIBLK0 posts request documents that were entered outside the SAP system. The data to be transferred is stored in a sequential file 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 the documents 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 system immediately, precautions have to be taken that make it possible to restart the program after a program termination. This restart, in the following called restart mechanism, serves to prevent a double posting of documentse when you start the program again.

To use the restart mechanism, you proceed as follows:

• First create a variant for the program RFBIBLK0.
  Execute function

• Define a restartable JOB.
  Execute function.

• Start the restartable JOB.
  Execute function.

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 a termination due to a formal error. You then have to find out which documents were posted up to the termination and then reduce the file correspondingly.

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

You can use Direct Input without the restart mechanism for test purposes. In this case, however, the entry file may not contain more than 20 documents. However, a restart after a program termination is not then 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 possible to decide if the value of the field is initial (e.g. field is to be reset to initial value) or if no input is necessary for this field at all. You also have to agree a special character that has the function: 'No input for this field'. The default for this special character is the character '/'.

If the special character '/' is not to be used, you can specify in the session header record in the field BGR00-NODATA which other special character is to fulfil this function.

Before filling the structures, each of the fields (except the session header record BGR00) must be 'prepared' with this special character at the beginning of the field.

The fields of the structures refer to the data elements of the fields from the original table. However, the numerical and packed fields are exceptions. These need their own data elements of the type Typ CHAR for the input because packed fields cannot be 'initialized' with a special character. This means that amounts with a decimal point can be transferred 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 or internal 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 clearing request, the first document segment contains the line item of a sender or receiver FM account assignment.

If entry values exist for the following fields, you enter them on the first 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 be specified, then you enter the appropriate data likewise on the first document segment.

You enter the data of the offsetting entry on the remaining document segments. In the case of a clearing request, this is the posting data of receiver or sender FM account assignments.

You can specify application of funds and reservation documents for each subledger account item.

You also enter account assignment objects, commitment item, funds center and fund on the G/L account item. If a mask was defined in the system for the substructuring of the commitment item key, then you must note that the field 'FIPEX' has to be filled in with the commitment item without 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 be entered in the the structure BBTAX_FM. It is not possible to calculate the taxes automatically. You therefore have to enter the respective absolute tax amounts in the BBTAX_FM structure. Those tax codes are currently supported that are also allowed when posting requests manually.

Deferral, Short-Term Waiver and Remission

When posting a deferral, a short-term waiver or a remission, you must refer to the original document via the fields REBZG, REBZJ and REBZZ. The original document is imported first, then the fields are filled with new values that may be changed with deferral, or short-term waiver and remission. If there is a field status, it is also considered here.

With a deferral document, the posting keys correspond to those of an acceptance request. Several deferral requests can be grouped together in a deferral request using a uniform request number.

With short-term waiver and remission, you specify the same posting keys as with deduction of an acceptance request.

On the initial screen of program RFBIBLK0, you can specify the 'number of documents per Commit Work'. This means that a database transaction generally comprises posting of several documents. Due to corresponding block mechanisms, you should avoid the posting of a deferral document and the corresponding deferred document within one database transaction. The same applies to short-term waivers and remissions. If you create documents with invoice reference and use the follow-on document category "F", you must likewise ensure that the original document has already been posted.

Invoice Reference

If you create documents with invoice reference and use the follow-on document type 'F' for this, you must also ensure that the original document has already been posted.

Field Status

The ready for input status of fields when entering requests online can be controlled per document type via a field status. An existing field status is considered by the program RFBIBLK0.

With deferrals, short-term waivers or remissions, only those fields are filled in that are controlled as required or optional entry fields by the field status. For the remaining request, the fields marked as required 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 code variant, no request number is allocated, irrespective of whether retroactive bundling was selected in the global settings or not.

If the indicator Without request number is not set, the program evaluates 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 carried out 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 for which the field LOTKZ is filled in a uniform way, are bundled under the same internal request number, that is, the contents of the field LOTKZ serves 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 you to add a request subsequently to an already internally allocated request number.

Documents with errors processed further

Note: The program is not terminated if there are documents with errors 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 a batch input session; they can only be saved in an external file. You can then process the newly generated file subsequently using report RFBIBLK0.

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 table descriptions for other programming languages.

Activities

Example

Fill RESBD Structure from EBP Component Structure   Fill RESBD Structure from EBP Component Structure  
This documentation is copyright by SAP AG.

Length: 11631 Date: 20240601 Time: 055828     sap01-206 ( 188 ms )