Capturing order cancellation details when cancelling an order in FOLIO

I was been brought to our attention that when cancelling an order we need to be able to capture additional details in order to prevent reword and provide valuable information for reporting.

This is a mockup of the model that will allow you to add context when cancelling an order.

04%20AM2264×1428 116 KB

Note: the system will also capture the user id of the user making the cancellation.

The list of cancellations is as follow, but please feel free to share your thoughts.

Ceased, Transferred to another publisher, Merged with another title, Split into other titles, Lack of funds, Lack of use, Duplication, Unresponsive vendor, Licensing terms (unacceptable), Low quality, Unpreferred format

The JIRA issue for this feature is UXPROD-722

Two use cases I don’t see represented on the list yet:

• Wrong title ordered: wrong edition, wrong platform, or a totally different work using a very similar title - human error happens.

• Technical error: actually, I don’t know what the best term for my particular use case would be, but I imagine “technical error” would cover a lot of bases. What we see sometimes in our ebook DDA/auto-upgrade workflows is that a purchase is triggered, and someone creates and approves a purchase order without noticing that it shouldn’t have triggered. The mistake gets caught further down the line, we report the bug and get the purchase reverted; it manifests in the system as cancelling that PO.

Although, maybe just “Error” would cover all of the above, and more. With the notes field, there’s plenty of room to describe what happened; maybe tags could be applied, if a library finds that a particular error is happening often enough that they want to track it?

I have some other use cases as well:

• title won’t be published this year
  Sometimes the date of publication changes, so the title won’t be published in this fiscal year but in one of the following years. In this case we cancel the purchase order to have a correct encumbrance for the current fiscal year.
• title won’t be published
• title is out of print
• title received as a gift / deposit copy / from exchange partner

Is it possible that each library can define their own reasons it wants to use?

I have another question (perhaps it is already somewhere answered or there will be information about it soon):
Is it planned that this app also sends a message to the vendor (via EDI, email, or even print a letter etc.) if you click on “submit” or do you have to use anything else to inform the vendor?
Background info: In our current system, cancelling the order in our system and informing the vendor about this cancellation (mostly via email) is one step/click.
How does Folio decide how the vendor will be informed (EDI, email, printed letter)? In the vendor app, I haven’t seen a field that is called “preferred way of getting orders, cancellations, etc.” or anything like this.

I’d like to back up and ask, what does “cancel” mean in the context of FOLIO? Is this only being using in reference to continuations with payments where we want to close the order for some reason? The example reasons that you give seem to imply this, but not strictly. I ask about this because in our current system (OLE), once a PO is approved, it can’t be deleted. I am assuming this is for auditing reasons. Honestly, this can be a pain because sometimes POs get created through errors, as @Heather implies. Whether by duplicate or mistake. Currently, we can void the POs, but they remain in the system. It would be nice, for genuine errors, to be able to clear these out and delete them entirely, assuming no payments have been posted against the PO. This permission could be limited to select individuals.

As for POs which are closed (cancelled) which have payments, it would be good if libraries could define their own dropdown of cancellation reasons. I can see if the PO was created for something that the library legitimately wanted to purchase, but was unable to (e.g., failed license negotiation), it would be good to maintain these POs in the system for institutional memory.

It’s great that there is a way to add additional context about why an order is cancelled or closed, so glad to see this is being added.

However, I am not comfortable calling all of these various reasons an order record is closed “cancellations.” It sounds like what we’re really getting at is reasons why orders might be closed, some of which involve cancellations of an order, some are cessations, some are order records that are opened for various reasons but then the orders are never placed. If I’m understanding how this will work (without seeing the larger context of it in the app), my preference would be to call this closing order records, not cancelling orders.

Either way, I agree that it would be ideal for libraries to be able to define their own values for cancellation reasons. I am agnostic on whether that is in a hardcoded dropdown, or if orders can just be closed and then tagged for reasons for the closing of the order.

Thank you all for your feedback on this! Let me do my best to clarify a few things and summaries the enhancements.

We have not yet determined how the vendor will receive cancelations. However, we will have the ability to communicate order data via EDI and thus should have that option. We can also discuss the inclusion of an email field that would pull an email from the vendor record and for cancelations and allow you to quickly send a notification.

The intention is indeed that once an order has been sent it can not be deleted but can be canceled. These cancellations are intended to apply to both one-time and on-going orders that have been “ordered”. The goal is certainly to have this list be easily adjustable. However, in the short term, they will be hardcoded and would need to be adjusted by a developer during implementation.

1. Before an order is sent it can be deleted. However, we could also allow the user to “Close” an order that has not been sent. This would essentially archive the unused order record, presumably for reporting purposes. Ideally, you would be presented a similar modal in this case and asked to specify a reason for cancelation.
2. When canceling an order we could allow users with certain permissions to “purge” the order record. This would allow you to effectively delete an order that has been sent in special circumstances.

I agree with @VirginiaMartin’s comments. I’d think of this more as closing an order. To me cancelling implies a specific decision that we do not want to keep purchasing a subscription, even if it remains available to purchase. I think libraries would want to have the option of customizing these choices if possible.

@dennisbridges, if closed orders remain in the system, is there a way to filter them out of searches? Or more specifically, would it be possible to filter out orders that were closed for a particular reason? I can think of searches where I would want to see most cancelled orders, except for those that were cancelled because they should never have been created in the first place – i.e., errors that we would delete in our current environment.

I would like to add another use case:

Title is overdue

• A title won’t be delivered within a reasonable period of time and then is no longer needed. This may apply to a title that is ordered as a patron request - maybe with a specific deadline till when it is needed. If the title won’t be delivered in time, the library would want to cancel the order.

If an order is cancelled because a title is transferred to another vendor and I would like to reorder the title with this new vendor: is it possible to reuse the order (after informing the former vendor about my cancellation and documentating the vendor change)? Instead of having two purchase orders for the same title (one without invoicing)? There could be an extra field like “former vendor”.
But maybe this is just complicating things …?

I feel like I’m struggling with a semantic/definitional issue here, and maybe this is what others are articulating as well?

For a one-time purchase, if the order has gone out to the vendor and then either can’t or won’t be filled for a variety of reasons (e.g., no longer wanted, no longer published, etc.), the Purchase Order is cancelled. There is no payment on the order.

For a continuing purchase, the subscription may be canceled but the Purchase Order is closed. There is a history of payment(s) on the Purchase Order for years to which the PO was active. Some example of reasons for closing the PO may be because the library chose to cancel the subscription for low use or lack of funds, or the title has ceased. In cases where the vendor/publisher has changed, I don’t know if all libraries would want to close one PO and open a new one, or edit the existing PO to reflect the current vendor? Assuming they want to close the existing PO and open a new one with the new vendor information, again using the term “canceled” seems misleading, as the subscription is still active, but with a different vendor.

I agree with @kmarti, that we’re struggling with a conflation of multiple situations that really need separated. Maybe:

Canceled for when you deliberately don’t want to order the thing anymore;
Closed for when the order is still good but you’re done with this PO for it;
??? for an error. (??? because I can’t think of a word for it that’s as concise and descriptive as canceled/closed. Kristin mentioned “Void”?)

I could see wanting to exclude any of these from a search for a PO, and a lot of the more detailed reasons we’ve listed are each a subset of one of those buckets.

You will certainly be able to filter by order status (Eg Closed) when performing searches. By the same token you could filter by reason for cancelation.

Thinking out loud a bit here but, it occurs to me that the common thread in these use cases is really the ability to stop an order without deleting it. In some cases that may be described as a cancelation and in some cases it may be more appropriately described as a closure, or something entirely different. What if we adjust the terminology such that an order can be marked as Archived (in stead of “closed” or “canceled”). The reason for it being archived would then offer the necessary context of cessation, technical error, Transferred to another publisher etc? You would then be able to see all archived orders and narrow them down by all the possible reasons they could have been archived for reporting or operational reference.

Please share your thoughts/concerns.

If we are going to continue to have a separate status for closed and cancelled. What, if any, are the differences in behaviour regarding related encumbrances, invoices and payments? Can anyone share a specific uses case in which they are different?

To my mind we could use ‘archived’ instead of ‘closed’ or ‘canceled’ and then give a reason that is filterable. This way things can be simplified. I cannot think of any differences as far as encumbrances, payments etc. are concerned.

Slight variations:

closed

• PO with related invoices and payments
• PO is ongoing, otherwise you wouldn’t close but cancel
  canceled
• not necessarily related invoices and payments
• if PO for monograph = no PO line, no invoice, no payment

In both cases:

• if there are related invoices, there will be no changes to them
• it is just necessary to set the expected deliveries on “expired”
• encumbrances will then be allocatable again

If you paid for items in advance you have to get them credited - but this can happen in both cases …

I agree with Martina that behavior would not be different. Whether an invoice is closed or cancelled, no further encumbrances or payments could be made against the PO. If it makes it easier to separate out the fields, we could go a route of PO=active/inactive, and then have a reason why the PO is inactive (canceled/made in error/unavailable/payment complete). Since this information is important for historical reasons, and perhaps for reporting, but not to be actionable within Acquisitions, that could be a good option.

So question from me - it seems like once an order has been sent to a vendor, an order (whether one-time or ongoing) is either open or closed. One 2 possible states.

If open, it may be not yet received at all, or ongoing, or partially received, or expecting an invoice, or whatever.

If closed, it may be because it’s complete (I’ve gotten and paid for everything I expected), or because the library or vendor cancelled it, or because it ceased, or because the vendor changed, or something else. Once closed, it seems important to understand the details of why it was closed.

But overall - 2 states for an order: open or closed.

What do you think?

I totally agree to you, @Ann-Marie. It is important to know the details of why an order is closed, but there are these to states: open or closed.

I’m glad we’re discussing this more as I think it’s resulted in a really good conversation! I agree with Kristin and Martina’s comments, and I think Anne-Marie is correct that it really comes down to two key statuses for invoices, whether we call it archived/unarchived, closed/open, or inactive/active. Even though I was the one who suggested we may need a workflow-driving difference between closures and cancellations, I spoke through it with a colleague and we reached the conclusion that we do not need that. Everything in the archived/closed/inactive status will need funds disencumbered but still allow for credits to apply to them. I waiver on whether they should be able to be reopened to apply a payment (perhaps you try to cancel but the vendor won’t let you until the next term) or if you should have to create a new order.

For reporting and historical record purposes, the archived/closed/inactive need to have an additional status or fixed field associated with them explaining the more detailed reason for that status. I’m not sure if we need the same options for the unarchived/open/active orders. We don’t use them in my department at Duke.

Additionally, as we have already discussed, what I’m going to call “substatuses” do need to be able drive workflows at some point. For example, a substatus of cancelled would kickoff a different workflow than a substatus of closed due to change in vendor or closed due to change in format.