Printer-Friendly

Payments Unit

Order Maintenance
Archiving Payment Information
Unicorn will not allow the vendor code on an order to be changed if at least one payment has been made in the current fiscal year. Unicorn will not allow the order type to be changed on an order at any time. When the vendor code and/or order type must be changed on an order before processing a payment, the existing payment and receipt lines must be "archived" before you can "re-create" the order with corrected information.

Here's a summary of what you want to accomplish:

A. Unicorn will not allow two orders with the same order # to exist in the same fiscal year unless they are "linked". [i.e. line 1, line 2, etc.] You first need to change the order # of all existing order lines to:  1) archive payment & receipt information and 2)  to create an new order [i.e. line 1] with the corrected information.
B. Now that the original order and all payment/receipt information have been archived, you can use the DUP ORDER command to create an order with the original order #, all original order information, and the corrected vendor code and/or order type. In effect, you are re-creating the original order with all necessary corrections.
C. Unfortunately, some original order information will not transfer to the DUPed order and must be copied over manually. This includes the original order date and any claim or cancel segments.
D. You need to let people know that some info pertaining to this order for a certain fiscal year is on another order #. This is especially helpful to payment staff when deDUPing payments and verifying receipt of materials.
E. You don't want the archived (and now duplicate) recurring order around to possibly confuse staff into continuing to use the archived order for further payments or receipts. However, before requesting that line 1 of the archived order be deleted, double check to see that the newly recreated order has all information that had to be manually transferred. Once the archived order with the original order information is gone ...it's gone.

Here's a detailed procedure:

A. Change the order #

1. Issue the command EDIT ORDER
2. Add the letter "V" to the end of the order # and ENTER.
3. Add an audit trail in the extended info NOTES field
4. See also <order#> -- <initials, date>

B. Create a new order using the original order # [i.e. without the "V"]

1. Issue the command DUPLICATE ORDER
2. On the 1st screen COPY the "existing ID" field except for the "V"
3. PASTE it into the "new ID" field
4. Fill in the "fiscal" field and ENTER
5. On the 2nd screen input the new vendor code and enter
6. On the 3rd screen add an audit trail in the extended info NOTES field
   Orig. vc = <original vendor code> -- For previous payments and receipts in fy<current fiscal year> see <Orig. order#>V -- <initials, date>

C. Restore all important information not carried over from original order that is now "archived"

1. Issue the command UPDATE ORDER for order with the "new" vendor code
2. Issue the command UPDATE ORDER for line 1 of the "archived" order
3. Switching back and forth between these screens, restore the original dates for the following fields by changing value to TODAY, ENTERing, then modifying the field with the correct date:
   date ready (on pre-Unicorn orders, this should be date created)
   date mailed
   date to claim
   date to cancel
   parts
   date rcvd
   packing
   loaded

D. Add a cross reference to the archived information in one of these formats:

DUPed to correct vendor code. Old vc = <old vendor code>
DUPed to correct order type
DUPed to correct vendor code & order type. Old vc = <old vendor code>

and

2002 pmt on <order #>, line <#>, fy<year>
Some pmts in fy<year> on <order #>

and

your initials and date

E. Request that "line 1" of the archived order be deleted.

• Library:  SUL
• Type:  UNKNOWN
• Home Location:  TECHSHADOW
• Current Location:  TECHSHADOW
• Call Number:  <autogenerated>
• Copy Number:  1
• 910:  ANCHORED <init., date>

EDIFIX
With the demise of the "copy 99"s, a vestige of our migration from NOTIS to Unicorn, a new problem has arisen with EDI invoices for serials classed together and unanalyzed or when the call # that the order is linked to is not unique. This occurs when the order is linked to:

• a title with a call # such as CALL # VARIES, NEWSPAPER, etc.
• a serial who's title has changed but retains the same call # of the former title
• a title for a co-ordinate library has been cataloged with the identical call #. [The title does not have to match SUL's.]

• Library:  SUL
• Type:  UNKNOWN
• Home Location:  TECHSHADOW
• Current Location:  TECHSHADOW
• Call Number:  <autogenerated>
• Copy Number:  1
• 910:  EDIFIX

Line 1 of the recurring order record will have "EDIFIX" in an extended COMMENT field. If "the order" [i.e. line 1] is being re-linked to another bibliographic record care must be taken to ensure that the order link remains unique. Please consult a supervisor if unsure. (see also ANCHORED)

NOTE:  The EDI program will also not "read" call #s past the first "space" of subfield Z causing some unique call #s to be non-unique.

Vendor Code Changes Due to Mergers, etc.
Occasionally, due to mergers or acquisitions, Payments staff may need to change the vendor code on an order. (see procedure Vendor Acquisitions & Mergers Policy for Unicorn RecordsJuly 7, 2006 code change for orders linked to a bibliographic record with a serials control record. ACCENTS to BERNAN changes should be sent to the Gov Serials Unit Team Leader. (Leona) . All other vendor code changes should be sent to the Operations Manager of the Serials Unit. (Brigitte)

Last modified: June 8, 2006