Ansicht
Dokumentation
RJKFTRSF - IS-M/SD: Transfer Orders on Hand from Legacy System to SAP System
General Data in Customer Master BAL_S_LOG - Application Log: Log header dataThis documentation is copyright by SAP AG.
Description
This program is used to transfer sales documents (subscriptions, external delivery orders, retail orders and internal orders) from an external system into the SAP System. Transfer does not take place using batch input. Function modules are used to check the data and transfer it to the SAP System. This technique is better for system performance than batch input processing. The System performs a Commit to the database after every n documents - you can specify the number n on the selection screen.
Interfaces
The sales documents that are transferred can be divided into three blocks:
- Subscriptions/external delivery orders
with the structures RJKIF_S_HEAD, RJKIF_S_ITEM, RJKIF_ITEMCC, RJKIF_S_ITEMWBZ and RJKIF_ADDRESS
- Retail orders
with the structures RJKIF_R_HEAD, RJKIF_R_ITEM, RJKIF_ITEMCC, RJKIF_SCHEDULE and RJKIF_ADDRESS
- Internal orders
with the structures RJKIF_I_HEAD, RJKIF_I_ITEM, RJKIF_SCHEDULE and RJKIF_ADDRESS
The data structure is different for each block, so that a separate data transfer file must be created for each block. See
Creating and transferring text files.
The interfaces are usually extended with each new release. Changes are documented at the end of this documentation.
What is not transferred?
In data transfer of subscriptions and external delivery
orders, only standard, free and trial items are transferred. Report RJKBJK01 is defined for transferring item changes (such as redirection or suspension).
Errored records
Errored sales documents are not updated but are placed in a batch input session (error session). The corresponding error message is listed for each record in the log.
Test run
The program can be started in test mode. If you do this, it does not update
the database or create an error session but simply produces an error log. To identify errors such as
incomplete customizing settings in advance, you can enter a number of documents for processing in test
mode. This enables you to test the transfer for a few orders first before having to create a file specifically for this purpose.
Restart procedure
The program can be restarted. This means that if data transfer
is cancelled (for example, due to tablespace overflow or system shutdown), it can be restarted. When
this happens, the program skips the records that have already been updated and continues at the appropriate point. In this case, you must select the 'Restart' switch when executing the program.
Requirements
When you start the program, you must enter the name of the file in which the data to be transferred
is stored. The file name is restricted to 22 characters due to the restart procedure. The path and the name of the input file must be maintained using transactions SF01 to SF06.
The records in the input file are so-called header records and item records. A record is interpreted by means of the field 'SATZART'. The following record types are possible:
Rec.ty. | Meaning | Relevance | ||
---|---|---|---|---|
'01' | Header record | (required) | ||
'02' | Item record | (required) | ||
'03' | Payment card record | (optional) | ||
'04' | WBZ record for item | (optional) | ||
'05' | Alternative delivery address record | (optional) | ||
'06' | Schedule line record | (not in subs./TP) | ||
'11' | Sub-item record | (optional) | ||
'12' | Template data for add.pyt | (optional) |
It is possible to transfer several schedule lines for each item in retail orders and internal orders. The schedule lines must then be appended after the item record with record type '06'.
Subscriptions and external delivery orders only have one schedule line per item, so record type '06'
is not used for them. The item records (in structure RJKIF_S_ITEM) already contain the schedule line data.
This means that n item records can be created for each header record. There can be a maximum of one
WBZ record, one payment card record and one alternative delivery address record for each item record. These record types (03-05) are optional.
The records must be in the following sequence:
Header record
Item record 1
Payment card record 1
WBZ record 1
Alternative delivery address record 1
Sch.line record 11 --- SLine record 12 --- ... --- SLine record 1n
(schedule line records only in retail or for internal orders)
Item record 2
Payment card record 2
WBZ record 2
Alternative delivery address record 2
Sch.line record 21 --- SLine record 22 --- ... --- SLine record 2n
The payment card records are optional and are only required if the payment method is 'Payment card'.
When transferring data on internal orders, there need not be payment card records in the file since
internal orders are free of charge. WBZ records are also optional and only required with WBZ orders. The alternative delivery address is also optional.
A new sales document is generated for each new header record. For each new item record, the System generates a new item with all the preceding records.
Live date
Before importing data from the legacy system, you must specify that system
is order administration is to take place in 'initial data transfer mode' in the general customizing
parameters for sales. You must also record a date from which the subscriptions in the system are assigned
delivery addresses and delivery viability sets. This does not necessarily have to be the live date. This means that the subscriptions do not have to be imported again if the live date is postponed.
The initial date of validity of the delivery viability set should be a few days before the live date,
since this is the date from which you can perform circulation planning for the orders on hand that have been transferred. This means you can perform planning for a period before going live and test shipping again.
Unloading points
If using direct delivery, the business partner unloading points must be created in the master data before initial data transfer.
Bank data
If the bank details are also to be transferred, the bank master records must be maintained first.
Formats
Dates in date fields in the interface must be entered in the format YYYYMMDD.
Amount fields can only contain digits. The plus or minus sign and decimal point are set by the System.
Recommendation
Presorting the orders on hand according to publication, edition, mix mix type, delivery type, invoice schedule and billing frequency reduces the number of times the database is accessed and thus improves system performance in data transfer.
Performance/runtimes
Buffering number range objects
The number range object KONV must be buffered during live data transfer or mass testing for data transfer. If you transfer orders with internal number assignment, you must also buffer the number range object ISP_BELEG. The number range object must be repaired in order to carry out buffering. Please do not forget to remove the buffer after data transfer, since otherwise gaps will appear in the number range.
Database indices
To increase the runtime, all database indices on the order tables on the database should be removed. However, when transferring WBZ orders, the index on field REFBELEG to table JKAP is required.
Defined fields
The interface description can be found in the program documentation on the following includes:
- RJKDFABO for subscriptions and external delivery orders
- RJKDFEVS for retail orders
- RJKDFINT for internal orders
General Material Data ABAP Short Reference
This documentation is copyright by SAP AG.
Length: 9893 Date: 20240531 Time: 114434 sap01-206 ( 152 ms )