Orders, UX iteration 3

Working on video but here is the 3 iteration of the prototype.

Orders, UX iteration 2

http://ux.folio.org/prototype/en/orders

I started a thread yesterday, but since this was posted, I’ll just copy my comments into this one and delete the other thread.

=============================================================

I’m sorry I missed the last RM SIG meeting, where the order prototype was shown and discussed. I’m hoping it will be useful to start a discussion topic on it, to see what others think and perhaps gather feedback for Stacks in a centralized way. That’s the way Filip has talked about gathering feedback on the prototypes that he is releasing.

Here’s the link from the 30 June notes: http://folio.stacksdiscovery.com/, and the newest iteration that Charlotte posted a link for: http://ux.folio.org/prototype/en/orders

And some questions/feedback from me - apologies for the length and if this gets too far into the guts too early - this is the part of library operations that I am most experienced with, both good and bad.

•PO numbers: Is there any formal decision on how long PO numbers will be? The one in the prototype is very long, which may or may not be supported by all vendor systems. For example, GOBI Library Solutions can only support 16 characters in a PO field.

•PO numbers: Will users be allowed to assign their own PO numbers (and FOLIO defaults a PO number if the user does not assign), or will FOLIO assign all PO numbers automatically? For automatic assignment, will the library have any control over the default structure and sequencing of the PO numbers? (length, prefix, include date, etc)

•PO numbers: Will FOLIO include the idea of a batch PO, or will all POs be individual line items? The prototype looks like it’s batch PO-oriented. If FOLIO has batch POs, will FOLIO also include a separate line item control number? That is critical for any electronic invoice matching. Also, it would be good to have a systems option to default to single line POs, if a library prefers not to use batch POs.

•PO numbers: Will FOLIO include an option to use a vendor-assigned number as the PO, or maybe as a separate vendor control number? This is critical for orders or approval plan purchases that originate from the vendor site instead of from FOLIO.

•Currency: the order details need to show the ISO currency code, not just the symbol. For example, the $ symbol can stand for USD, AUD, CAD, NZD and many other “dollar” currencies.

•Currency: Orders should allow various currencies, not just the default currency. If the currency is different from the default currency the library uses in its fund accounting, it will be helpful to have an approximate exchanged currency show in the open order, so that the library knows how much was encumbered. The if the payment is made in a different currency from the library default, it will be important to have the final exchange amount shown in the closed order, so that the library knows how much was debited from the fund.

•Funds: if payment is to be broken across multiple funds, probably best to allow amount or percentage breakdown. Or if only percentage, then show the amount that the percentage represents, so that the library can manipulate the percentage to use a specific amount from a fund if necessary.

•Funds: I know there’s lots more work to be done on funds, but if there is going to be a long spelled-out version of the fund name, it will also be useful to have an abbreviated or code version of the fund.

•Notes: There need to be internal notes and vendor-facing notes at the batch PO and individual PO/line item level. I see general notes, but it’s important to be able to tag or differentiate different kinds of notes if they are to be actionable in different ways (e.g. keep track of all items requested by this person or department, notify a user when this is received, notify cataloging to do something special when this is received, notify the vendor to do something special with this order (which would need to be output in the order), don’t notify anyone - just some sort of note about the order, status update note from the vendor, etc.)

•Order mechanics: Good to see the created and sent dates. For tracking and troubleshooting purposes, I think it’s important to note or log somewhere how the order was created (created manually by User X, created automatically from EDI data, created automatically from MARC data, created automatically from API data, etc) and how the order was sent (paper, e-mail, phone, fax, EDI/FTP, not sent/created from vendor API, not sent/created from vendor EDI, not sent/created from vendor MARC, etc.)

•Order details: Within individual line items, it will be important for books to show which ISBN is the ordered ISBN, especially since the same cataloging record can include multiple ISBNs. If multiple ISBNs in the codex record or source record, then the order person needs to be able to pick which ISBN should be sent in the order.

•Order details: Need some tags or fields to allow for categorizing orders by type, department, subject, etc - for searching/reporting purposes.

•Order details: For physical items, it needs to be clear which location the copy/copies are being ordered for. If multiple copies, then the library may want to assign copies to various locations (in addition to various funds). For example, if I’m buying 3 copies of a nursing handbook, I want to use my nursing fund to pay for all of them, but I want to assign different locations to each copy: Main, Main Ref, and Hospital A. This has significant implications for any EDI and MARC transactions, especially if the vendor is providing cataloging and/or shelfready services to the library.

That is a first, very quick pass - definitely not everything, but the first stuff that comes to mind. Hopefully it will start some discussion and other feedback/comments. If it would be useful to organize the feedback/comments in other ways, please speak up about that too.

Thanks,
Ann-Marie Breaux