• Article Type: General
• Product: Aleph
• Product Version: 19.01

Description:
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:

Z68_REC_KEY: 00358725000002
Z68_ORDER_TYPE: M
Z68_ORDER_NUMBER: 3587250-2
Z68_OPEN_DATE: 20091113
Z68_ORDER_STATUS: SV
Z68_ARRIVAL_STATUS: P
Z68_INVOICE_STATUS: P
Z68_LAST_TOUCH_DATE: 0
Z68_SUB_LIBRARY: ABCCI
Z68_METHOD_OF_AQUISITION: PU
Z68_ORDER_DATE: 20091113
Z68_MATERIAL_TYPE: MO
Z68_SEND_METHOD: EDI
Z68_EDA: 20100113
Z68_VENDOR_CODE: 0000003605
Z68_NO_UNITS: 1
Z68_TOTAL_PRICE: 95.00
Z68_ORDERING_UNIT: ABOR1

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
Z79_ALPHA: L
Z79_TEXT: 3587250-2
Z79_ORDER_KEY: 00358725000002
Z79_FILTER_1: ABCCI
Z79_FILTER_2: SV
Z79_FILTER_3: A1
Z79_FILTER_4: M
Z79_FILTER_5: AC
Z79_FILTER_6: N
Z79_FILTER_7: N
Z79_FILTER_8: N
Z79_FILTER_9: 20091113
Z79_FILTER_10: 20091113

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.

Resolution:
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"
THEN
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
THEN
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