Support "blanket" orders in acquisitions via direct charges

[Bill Erickson]

For the purposes of this ticket, a "blanket order" is one where an order is created and encumbered for a collection of items, the exact contents of which may be unknown, which is paid off (and dis-encumbered) over time as items are received and invoiced.

Here is a proposal for supporting blanket orders in Evergreen via direct charges. No lineitems are created and no bib/item details are added to acquisitions. In the described work flow, acquisitions staff do not concern themselves with the contents of the items delivered (apart from maybe confirming the invoice matches the items), only the amounts billed and paid along the way.

http://evergreen-ils.org/~erickson/docs/blanket_po.html

Comments appreciated.

[Bill Erickson (berick)]

Implementation pushed:

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/berick/lp1440114-acq-blanket-orders

Release notes are included and contain an updated sample work flow.

[Jennifer Pringle (jpringle-u)]

We at the BC Libraries Cooperative really like the look of this new functionality based on the sample workflow and see how it could be useful for our libraries.

 I'm a little concerned though that the following charge related bugs will prevent this functionality from working as it should: https://bugs.launchpad.net/evergreen/+bug/1436906 and https://bugs.launchpad.net/evergreen/+bug/1272515

[Bill Erickson (berick)]

Thanks for the feedback, Jennifer.

I actually worked on #1436906 with this bug in mind. It's not exactly a prerequisite, but makes direct charges more friendly to use in general. I'm not anticipating any negative interaction here, but we should definitely test to be sure.

Frankly bug #1272515 appears invalid. When I add a direct charge to a PO, then invoice it, the direct charge does appear in the PO. I added a comment to the LP entry.

[Bill Erickson (berick)]

Rebased to current master and pushed some pgtap tests.

[Kathy Lussier (klussier)]

I'm still testing this branch, but noticed a couple of things in my testing this morning:

If you have a PO with a mix of lineitems and a blanket charge, when all of those lineitems are received, the PO state will change to receive, even if the standing order charge has not been finalized. I would expect the PO state to remain as on order until all lineitems are received and the standing order charges are finalized. It also looks like you lose the ability to finalize the standing order charges.

The second issue is more of a quibble than a concern. You mentioned in the release notes that a direct charge type cannot have the prorated and standing order flags. If the user tries to create a charge type with both flags and clicks Save, the charge type will not save with no feedback to the user as to why it isn't saving. Would it be possible to handle this situation a little differently? Maybe with a message telling the user why the direct charge hasn't saved. Another approach might be to disable the prorated/standing order checkbox if the other is already selected.

Those acq Save buttons can be very persnickety, and it's difficult to know if something isn't saving because there's a problem with the input or if the button just needs another click.

Everything else looks great!

[Bill Erickson (berick)]

Both good points. Thanks, Kathy. I'll do my best to address those quickly. -b

[Kathy Lussier (klussier)]

I have another question as I wrap up testing.

Let's say I create a blanket charge for $1,000 and then invoice $100 of it. The next time I create an invoice from this PO, the displayed estimated cost is still $1,000. Should it display the origin amount here or should it be displaying what's currently encumbered. I was expecting to see the total that was remaining in the blanket charge, but I could see it working the other way too.

[Bill Erickson (berick)]

Kathy, what you are describing is what I would expect. The goal is to present 3 separate pieces of information: how much we expect to spend in total, how much is left to spend, and how much we have spent so far. The purpose of each summary field hasn't changed with this branch, but it should be more accurate now.

[Bill Erickson (berick)]

I pushed a commit to warn and prevent saving an invoice item type when both prorate and blanket flags are selected.

[Bill Erickson (berick)]

Pushed another commit to prevent a PO from going on-order => received when blanket charges exist on the PO which are still encumbered.

[Kathy Lussier (klussier)]

This looks great Bill! I resolved a minor conflict and pushed a signoff branch at:

 http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/kmlussier/lp1440114-acq-blanket-orders

Thanks Bill!

[Bill Erickson (berick)]

Thanks for all the attention, Kathy! I have merged the code to master.