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

Description:
On both our test server and production server, in the Acquisitions module, in the Order records, when we “Create a hold” by inserting an initiator ID and using the drop down box, Aleph does not always create the hold on the item when the item is checked in ( arrived ).

It seems that the orders for GOBI2 and YANK3 are not generating automatic holds.

Resolution:
The following SQL results show that, in the cases where there are z37's for BACH1, CASLI, JAPUB, LABSL, and UMI-M, all the order records have a z68_target_flag with a value of "H":

abc50@ALEPH20> select z68_vendor_code, count(*) from z68, z37 where z68_target_flag = 'H' and Z68_TARGET_ID is not null and substr(z68_rec_key,1,9) in (select substr(z37_rec_key,1,9) from z37) group by z68_vendor_code;
**** Hit return to continue ****

Z68_VENDOR_CODE COUNT(*)
-------------------- ----------
AMZN 5058
BACH1 1686
CASLI 1686
JAPUB 3372
LABSL 1686
UMI-M 1686


and that, in the cases where there are z37's for CALNEWS, GOBI2, PROCARD-ACQ, TOUZO, and YANK3, all the order records have a blank ("N") z68_target_flag:

abc50@ALEPH20> select z68_vendor_code, count(*) from z68, z37 where z68_target_flag = 'N' and Z68_TARGET_ID is not null and substr(z68_rec_key,1,9) in (select substr(z37_rec_key,1,9) from z37) group by z68_vendor_code;
**** Hit return to continue ****

Z68_VENDOR_CODE COUNT(*)
-------------------- ----------
AMZN 20232
CALNEWS 1686
GOBI2 6744
PROCARD - ACQ 1686
TOUZO 1686
YANK3 8430

(AMZN is a mixture, with 4/5 having no z68_target_flag value and 1/5 having one.)

So it seems that in order for a hold to be automatically created it is not enough for the order to have a value in the z68_target_id; it must also have "H" in the z68_target_flag ("ACTION").... (This makes sense since "H" means "Create hold request for the user for whom the material is intended (Z68-TARGET-ID)."

• Article last edited: 10/8/2013