|
Introduction
Information on the archiving of shipments is in the expanded help andin the hints on archiving (reachable on the initial screen of shipmentarchiving via Go to-->Hints or here.
This information should be read first. Then the technical documentationwill be understandable since it is based on this information.Archiving and Shipment Chains
In contrast to archiving other SD documents, there is a peculiarity inarchiving shipments which must be clarified:
Shipments can connect with other shipments. This is identified as ashipment chain. Example:
- Preliminary shipment A from Walldorf to Hamburg via truck with delivery
L1
- Main shipment B from Hamburg to New York via ship with delivery L1 and
many other deliveries
- Final shipment C from New York to Chicago via rail with delivery L1
Shipments A, B, and C are connected because they ship the samedelivery. Main shipment B also contains other deliveries which arefurther shipped on preliminary/final shipments. A type of network isformed because many shipments connect, since they ship the samedeliveries.
This is a closed business transaction. It should only be archived wheneach individual shipment of this network can be archived. Parts of thisnetwork should not be archived (for example, only preliminaryshipments) since this can lead to inconsistencies in the system (forexample, the shipment management status of the delivery is notcorrectly determined if a shipment is missing).
Hence, if a shipment - as part of a shipment chain - appears in anarchiving run (that is, has the run indicator 'Preliminary', 'Main' or'Final' in the shipment header), then it must be checked with whichshipments of this particular shipment is connected and whether thesecan be archived.Reading from the Database with Cursor Technique
In the FORM PREPARE, after an initialization of global data (performglobal_data_init), the check logic table (TVARS) is read (performchecking_logic_read). Then, the archive file is opened (performarchive_open) and a cursor made ready in table VTTK (performopen_vttk_cursor).
Reading shipment header data must be done with a cursor technique,since not all shipments to be archived may not be read in one sweep.The data set would be too big and the internal tables would "burst".Hence, reading the database is carried out in a "swallow by swallow"fashion. For this, you open a cursor in the database (ABAP commandOPEN).
With FETCH, you can always import a certain number ofdata records (addition 'package size') and process them (formread_shipment_headers).
In FORM OPEN_VTTK_CURSOR, there are various ways to open the cursor.If, for example, you desire a detailed log, all VTTK records in thespecified area are read and then checked in the program. The result ofthe check lands in the log for each shipment.
This procedure is, naturally, inefficient under some circumstancessince much data is read from the database. Hence, in other cases, (nodetailed log), it is attempted to specify as many check criteria aspossible with the SELECT command. Then the database takes care of thesechecks and the data is not transported unnecessarily.
For this purpose, an internal check logic table (CHECK_LOGIC) is laidout containing the minimal status and entry/change date for each combi-nation of shipment type and shipment management center (formcreate_checking_logic_table). Table TVARS is differently structured,containing the residence times in days (and no date). Additionally,maskings can occur in the key. Hence, this check logic table must belaid out.
With this table, a SELECT FOR ALL ENTRIES can be made. This is evenmade simpler if all entries are the same.Reading the Shipment Network
After the first shipments are read (form read_shipment_headers), theitems for these shipments are read (i.e., the delivery numbers) (formread_shipment_items). In this routine, the respective shipment networkis then subsequently read (perform read_net). This happens via aninteractive reading of tables VBFA and VTTP. At the end, all remainingVTTK and VTTP entries are read.
The internal tables NVTTK and NVTTP (and NVBFA) now contain alllogically connected shipments and all associated items.
The next step is a consistency check (form check_consistency). Here, itis checked whether the previously read entries (VTTK, VTTP, VBFA) arealso consistent. For example, a shipment header should always exist forthe items in table NVTTP (table NVTTK). Checking Archivability
Checking archivability (form check_archivability) requires certainpreparation (form prepare_check). The most important step here is anassignment of a number for a shipment network (form net_set_numbers).All entries in tables NVTTK, NVTTP and NVBFA belonging to ONE shipmentnetwork contain a uniform number here (NETNUM).
A shipment network is not archivable if even one shipment of this net-work is not archivable. With this 'Network number', you can spareyourself a lot of checks:
After each check of a criterion, you can not only exclude the non-archivable shipments for further checks, but rather the entire network.This happens in FORM CHECK_ARCHIVABILITY via call-up of the routineNOT_ARCHIVABLE_NETS_DELETE. The next criterion to be checked has,therefore, significantly less to check, under the circumstances.
Only if you desires a detailed log is the network not immediatelyeliminated. ALL checks are executed for ALL shipments.
Checks:
- The shipment network may not 'range out of' the user-specified area of
the shipment number (form check_range).
- Overall status, creation and change date must, with respect to the
entries in TVARS, must be sufficient (formcheck_shipment_status_dates).
- The shipment must be completely calculated and the associated freight
chages documents must be already archived (formcheck_freight_cost_documents). The document chain recalculated from"front to back" at archiving.
- The shipment management status of the deliveries of the shipment must
be completed ('C'). Additionally, the goods movement status must be at'C' (or '_') (form check_delivery_status).
- Customer defined checks are executed (form user_defined_checks).
Left behind at the end in tables NVTTK, NVTTP and NVBFA are only thoseentries stemming from the archivable shipments. Finally, they arelogged in FORM PROTOCOL_ARCHIVABLE_SHIPMENTS.Reading Shipment Documents and Archiving of Data, Log Output
The data of those shipments to be archived is read via mass access(form read_dependent_tables).
Then, each shipment is transferred individually to the archive (formarchive_all_tables).
Finally, the cursor in the database table VTTK is closed in FORMCOMPLETE and the log is output. The last step is closing the archive. Log Management
When archiving, a log is collected and output at the end. This log isNOT realized with functional modules of the functional group V56P. Manymore form routines are called up in the INCLUDE RV56PRAR. This INCLUDEis also used by the two other archiving reports SDVTTKDL and SDVTTKRL.
INCLUDE RV56PRAR contains three global tables in which the log iscollected:
- PR_GN contains general messages ('Opening the archive', etc.)
- PR_SC contains success messages ('Shipment 123 is archivable')
- PR_FL contains error messages ('Shipment 124 is not archivable because
...').
Respectively, there are similarly named routines which append entriesto corresponding tables.
Additionally, this INCLUDE RV56PRAR contains routines for log output.Mandatory Archiving
Via a small modification to the source code, a so-called mandatoryarchiving can be activated.
For this, the INCLUDE RV56ZWAR in report SDVTTKWR must be linked. Atthe location provided in the source code of SDVTTKWR, an asterisk mustbe removed for this.
If this INCLUDE RV56ZWAR is linked, the the following happens:
|