- Article Type: General
- Product: Aleph
- Product Version: 19.01
In the GUI client for order number #3587250-2 both the order Arrival Status and the order Invoice Status display correctly as None (N) in the Order Info and the Order List since it has not been invoiced or arrived.
However in the z68 record for this order both the Z68_ARRIVAL_STATUS=P and the Z68_INVOICE_STATUS=P. Any ideas on how this happened?
Here's part of the record:
In addition all z79 order index records have the correct N for z79_filter_7 (Order Arrival Status) and z79_filter_8 (Order Invoice Status):
Z79_REC_KEY: ON 3587250-2 00358725000002
The order log for this record isn't showing anything unusual. And I think there are a group of records that have this same problem.
The pc_acq_c0504 program which produces the Order Info display calls ./pc_com/pc_edit_order, which, in turn, calls ./acq/correct_z68_status.
correct_z68_status checks to see if there's a z78 (arrival) record and, if not, overrides the z68_arrival_status:
IF BUF-Z78-NO-LINES = 0 AND
Z68-ORDER-TYPE NOT = "B"
MOVE "N" TO Z68-ARRIVAL-STATUS
Then it checks if there's a z75 (invoice line item) for this doc# and, if not, overrides the z68_invoice_status:
IF BUF-Z75-NO-LINES = 0
MOVE "N" TO Z68-INVOICE-STATUS
These overrides are temporary, just during the production of this display, and do not result in any actual update to the z68.
The one clear issue is during an implementation that involves conversion of the Z68 table. In order to display the correct Z68 information, both the Z75 and Z78 tables will also need to be converted. This information appears in the z-table documentation.
You should be able to use the following SQL's to locate cases of such order records:
SQL> select z68_rec_key from z68 where z68_arrival_status = 'N' and z68_order_type ^= 'B' minus select substr (z78_rec_key,1,14) from z78;
SQL> select z68_rec_key from z68 where z68_invoice_status = 'N' minus select z75_rec_key from z75;
and then, perhaps, determine what they have in common and why/how they got this way.
But, if there are no *actual* implications in your situation, it may not be worth spending too much time on this.
- Article last edited: 10/8/2013