PO Numbers: allow duplicates or not?

Hi everyone,

We’d like to discuss and decide a very specific question about PO numbers at RM SIG on Friday. I’m posting this in Discuss to give people a couple days to think about it before the meeting.

This is NOT a question about the formatting of the PO number. FOLIO will automatically suggest a new PO number, but the user will be able to edit that suggested PO number or replace it entirely with their own. Thus, any FOLIO library could theoretically have a mix of FOLIO-assigned and user-assigned PO numbers in the Orders App.

Setting aside the formatting question, should FOLIO ever allow duplicate PO numbers? My inclination, and the developers’ inclination, is to disallow duplicate PO numbers, especially for FOLIO-assigned automatic ones. Would there ever be a need to allow the same PO number on different POs? Any use case over in the realm of user-assigned manual PO numbers?

Please add any comments, opinions, or use cases here, and we’ll review on Friday, with the goal of making a decision on Friday.

Thank you!

Duke’s current ILS (Aleph) doesn’t allow for duplicate PO numbers, or if it does, we don’t make use of the functionality. We don’t have any local use cases to share, and are inclined to agree that duplicate PO numbers should not be allowed. We rely heavily on automated loading of orders and invoices, a process that requires a PO number as the unique identifier for an order. Duplicate PO numbers seem like they could cause issues with this sort of automated batch loading in the acquisitions module.

I think Voyager (technically) allows duplicate PO numbers; its indexed field is an uneditable, hidden PO_ID instead. In practice, Cornell does not want to use duplicate PO numbers.

Also in practice, some vendors send us credit/refund invoices with the same dang invoice number as the original invoice. We generally tack on a suffix ("/cr" or somesuch) to the credit invoice to make a distinction between them. It’s kind of a pain.

We also have situations where we want to denote that one PO is associated with another - for example, maybe a new PO for a one-time perpetual archives purchase of a continuing subscription - in which case we start with the same PO number as the main subscription PO, but, again, add a suffix.

So, for example, to prevent duplication, we create POs something like -

Main PO: 123456
Refund: 123456/cr
Strongly-associated-purchase: 123456arch
Maintenance fees: 123456maint

I don’t think I’ve seen a case of what we would do when a duplicate PO is created, but I bet it would involve a lot of annoyance, and would be better to just prevent.

It would be nice to have some sort of functionality to indicate that one PO is related to another, though.

A couple possible use cases I have seen in some libraries:

1. Creating an order manually for something just ordered on Amazon or another external site, or for gift materials. Sometimes libraries use today’s date as the PO number, and are creating multiple orders like this on the same day. If POs had to be unique, that means they would need to add a prefix or suffix. Or they could just take the FOLIO-suggested PO and forget about using the date as a PO number. Since the order is not being sent out to a vendor, the PO may not be very relevant.

2. Having to cite an external system PO. This sometimes comes up with community colleges or with grant situations, where all materials purchased with particular funds, or in a particular timeframe, must bear the PO number assigned to track those purchases in the library’s external accounting system. If various materials are ordered over time, and all must bear the same PO, that will lead to problems, both in the FOLIO PO number and in invoice matching. I’m inclined to have FOLIO assign its own PO in the FOLIO PO field, and then park the external system PO someplace else, where it can be retrieved for accounting or reporting purposes as needed.

Our current ILS in Regensburg (SISIS SunRise) doesn’t allow duplicates of PO numbers (or better: if it has this functionality, we don’t use it). In fact the librarian chooses the first digits (which tells you the fund), but the next digits are automatically added by our ILS to get a PO number as unique identifier.

We use these unique PO numbers as identifier so that EDIFACT invoices etc. can be automatically connected to our POs. Like Virgina, I think, duplicates of PO numbers could cause some problems with this automated process.

I also think it would causes problems in the reporting area if you haven’t an unique identifier for each PO (or is it planned that each PO / POL has its own system generated number as unique identifier which is just stored on the database level and can be used to connect different apps etc.?)

Like others, I find value in having unique PO numbers and believe it would be problematic to have duplicate PO numbers for reasons of trying to reference the order, match up invoices, etc., that are already mentioned. As to your point #2, I agree having the external PO number go to a separate field would be the way to handle this. This is how we handle external invoice numbers in OLE. @ScottPerry, can you think of why we would want duplicate POs?

Like Chicago, Duke also uses other fields to track external PO numbers / order identifiers. Our order records have two “Additional Order No.” fields where we can put them. Since there aren’t enough fields for the various numbers we need to store, they don’t consistently store the same information. I know we are venturing away from the question of whether duplicate PO numbers being possible is necessary / desirable, but since it’s on my mind, I thought I’d jump in with this info about what we do want.

In this screenshot we are using the 1st additional order field to store a PO from our our previous ILS, since this order migrated from that system. The 2nd additional order field contains the PO number for this order again, not sure why (@debfields should be able to answer that!):

Here we have another order where the 1st additional order field is storing the PO number for an earlier order:

And on the “Vendor” tab of the same order, you can see that we keep EBSCO’s vendor reference number stored in the “Vendor Reference” field.

Perhaps a way to address our inconsistent use of these fields at Duke because we don’t have enough of them, as well as Heather’s request for a way to relate POs, would be to have a repeatable field called “Related identifiers” or something like that. Being able to add an identifier and then select a type from a locally customizable dropdown (e.g., additional vendor reference, related order, former order, future order, etc.) would be amazing. That could be in addition to whatever we decide needs to be hardcoded to drive functionality and automation.

I would prefer to have unique PO numbers (for the same reasons as already mentioned). Having a separate field to take care of external PO numbers seems a good idea to me.

“Related identifiers”, repeatable - brilliant. I want it.

I can come up with no reason to duplicate a po number. I think, as stated by others, it creates many difficulties.

Hi,
we don’t allow duplicate PO numbers. I would like to keep it like this to have a really reliable key for every PO in the database. Especially when I’m thinking of the necessary linking functionality between PO’s/POL’s and agreements, inventory, and more.

We have an additional feature in our recent LBS that means “assign order to another PO number and store the old PO number in a special field” to support a workflow of “re-ordering”". This is useful but really seldom used.

Having to store an external PO number, I would be in favor of doing it as an extra key, additional to the FOLIO internal number. Something like “foreign_id_nr” or “foreign_po_number”.
That would allow to have a relation between both numbers and a unquestionble connection.
Useful perhaps for order import functionality: order is imported with external PO number - during import / with saving an internal PO number is set and saved.

All good points, everyone - thank you!

One reminder: the PO that the user sees on the screen is the “human-readable ID” (aka HRID) that will be exchanged with vendors and show on printed orders/invoices as the PO number. Behind the scenes, FOLIO assigns a longer, more-complex, unique UUID (example: d7aba1ae-ab7b-46cf-b3ad-9a31bfa50aad) to every PO and PO Line. So no matter what the PO or PO Line HRID is, there will always be a unique identifier behind the scenes that FOLIO can use to ensure linking and reporting info is handled cleanly.

Quick follow up on my earlier post from my colleague, Deb Fields:

Additional Order No.1 usually refers to the previous order number. In the example below the order number .O1044540 is an old Innopac order number. This was very helpful after the migration from Innopac to Aleph as sometimes orders are hard to find on a title level. We are able to do a search on this field.

I was instructed early on to repeat the order number in Additional Order No.2. Not sure why we did this or whether it is necessary.

So one of those things that we do, but we don’t know why we do it