Description:
This module provides the ability to create and manage purchase orders for the purpose of acquiring both print and electronic resources.
Documentation:
Attached below you will find a data-flow model that describes what data is being passed between this module and other modules within FOLIO. You will also find an Entity Relationship Diagram that illustrates what specific data elements are being stored in this module and what data elements are being retrieved from other modules. Finally, there is a mockup of what fields the edit/create order screen may contain.
Interface fields:
| Data element | Accordion | Physical resource (creates 1 line item) | E-resource (creates 1 line item) | One-time order | Ongoing order | Repeatable? | Searchable | Filter on this? | Can Edit Once Open | Hardcoded/Editable? | Description (DRAFT) | Values | Comments | Past Note |
| Purchase Order | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| assigned_to | Purchase Order | Yes, optional | Yes, optional | Yes, optional | Yes, optional | N | N | Y | Y | API | User assigned responsibility for the order | This is user name as provided by user module | A-M: only needed if separate approval step, or always needed? | |
| created | Purchase Order | Yes, required | Yes, required | Yes, required | Yes, required | N | Y | Y (by date range) | N | date | date the order was created | |||
| created_by | Purchase Order | Yes, required | Yes, required | Yes, required | Yes, required | N | Y | Y | N | API | user tha created the order | This is user name as provided by user module | ||
| notes | Purchase Order | Yes, optional | Yes, optional | Yes, optional | Yes, optional | Y | N | N | Y | editable | Notes related to the order as a whole | |||
| po_number | Purchase Order | Yes, required | Yes, required | Yes, required | Yes, required | N | Y | N | N | system default, but editable | Order number generated by the system or added by the user | A-M: system assigned default, or library can specify; have system-level settings that allow for single-line or multi-line PO preferences - system will use this to link PO's in some situations eg. reorder | ||
| prefix | Purchase Order | Yes, optional | Yes, optional | Yes, optional | Yes, optional | N | Y | Y | N | Controlled Vocab | ||||
| suffix | Purchase Order | Yes, optional | Yes, optional | Yes, optional | Yes, optional | N | Y | Y | N | |||||
| workflow_status | Purchase Order | Yes, required | Yes, required | Yes, required | Yes, required | N | N | Y | Y | hardcoded | Pending, open or closed. These describe the general state of the order in it's lifecycle | Pending, Open, Closed | Pending, open, (cancelled, fulfilled - These statuses will be replaced by "Closed" and allow the user to select a reason). | |
| reason_for_closure | Purchase Order | Yes, required | Yes, required | Yes, required | Yes, required | Y | N | Y | N | hardcoded | A description of why the order is in the 'Closed' status. | 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, Error, title won’t be published this year, title won’t be published, title is out of print, title received as a gift | 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, Error, title won’t be published this year, title won’t be published, title is out of print, title received as a gift | |
| manual_po | Yes, optional | Yes, optional | Yes, optional | Yes, optional | N | N | N | N | checkbox | Manual orders are not included in any automated communication with vendors | checkbox; if checked, excludes the PO from any automated functionality, including being sent to the Vendor electronically; review later on in the interface | |||
| acquisitions_unit (formerly owner, team) | Purchase Order | Yes, optional | Yes, optional | Yes, optional | Yes, optional | N | Y | Y | N | hardcoded | Which acquisitions unit (Team) owns this order (and is responsible for dealing with its distribution). | Which acquisitions unit (Team) owns this order (and is responsible for dealing with its distribution). | ||
| approved | Purchase Order Summary | Yes, required | Yes, required | Yes, required | Yes, required | N | N | Y | N | checkbox | Indicates that an order has been approved by a user with the authority. | A-M: have option for automatic approval, if no separate approving step required | ||
| approvedBy | Purchase Order Summary | Yes, required | Yes, required | Yes, required | Yes, required | N | N | N | N | API | This captures the user who actually approved the order | This captures the user who actually approved the order | ||
| date_ordered | Purchase Order | Yes, required | Yes, required | Yes, required | Yes, required | N | Y | Y (maybe by date range?) | N | date | This marks the date and time that the purchase order was openned/sent or placed with the vendor | This marks the date and time that the purchase order was openned/sent or placed with the vendor | ||
| order_type | Purchase Order | Yes, required | Yes, required | Yes, required | Yes, required | N | N | Y | N | hardcoded | One-Time, On-Going, (On-Going Re-encumber?) | How do we accomodate the need to re-encumber or not in certain situations. Could it be on-going re-order or on-going standing-order? | ||
| re-encumber | Purchase Order | Yes, required | Yes, required | N/A | Yes, required | N | N | Y | N | Boolean | Indicates that the order should be re-encumbered in the next fiscal year if open during rollover. | Boolean (Default is unchecked) | indicates this purchase order should be re-encumbered each fiscal year. Only applies to ongoing orders | |
| Bill to | Purchase Order | optional | optional | optional | optional | N | N | N | N | API | This list of addresses found in folio settings describe where the library can be billed. | In the UI the will be a "lookup" plugin. Will need some way to populate a default | This list of addresses should be found in folio ideally a location where you can find. - If that is the case it will be a reference to a uuid else where in the system | |
| Ship to | Purchase Order | optional | optional | optional | optional | N | N | N | Y | API | This list of addresses found in folio settings describe where the library intends to receive the goods. | In the UI the will be a "lookup" plugin. Will need some way to populate a default | This list of addresses should be found in folio ideally a location where you can find. - If that is the case it will be a reference to a uuid else where in the system | |
| template | Purchase Order | optional | optional | optional | optional | N | N | N | N | editable | Template the pre populates order fields for the user | |||
| manual_renewal | Purchase Order - Ongoing (Renewals) | Yes, optional | Yes, optional | Not needed | Yes, optional | N | N | Y | N | checkbox | Indicates that a user must contact the vendor in order to acquire material for another term. | checkbox | ||
| renewal_date | Purchase Order - Ongoing (Renewals) | Yes, optional | Yes, optional | Not needed | Yes, optional | N | N | Y (maybe by date range?) | N | editable | date renewal was confirmed by vendor or sent to vendor | Date by which user must decied to renew or not (Soemtimes talked about as a cancellation deadline) | ||
| review_period | Purchase Order - Ongoing (Renewals) | Yes, optional | Yes, optional | Not needed | Yes, optional | N | N | Y | N | editable | Time prior to renewal where changes can be made to subscription | Time prior to renewal where changes can be made to subscription | ||
| renewal_interval | Purchase Order - Ongoing (Renewals) | Yes, optional | Yes, optional | Not needed | Yes, required | N | N | N | N | Calculated | Term of the renewal for which the lirary will be sent or have access to material at the end of which they will need to renew in or to acquire material for another term. | George: most renewals are annual (e.g. Jan-Dec, July-June, Oct-Sept, or irregular). Should this be subscription_interval? Possibly can be removed as subscription detail lives in the pol | ||
| reviewDate | Purchase Order - Ongoing (Renewals) | Yes, optional | Yes, optional | Not needed | Yes, optional | N | N | N | Y | Date | On this date the user will be notified that they are able to renew | Date picker | Could be used to trigger a notification or flag to remind user to review order (Not required) | |
| Subscription | Purchase Order - Ongoing (Renewals) | Yes, optional | Yes, optional | Not needed | Yes, optional | N | N | Y | N | Boolean | Indicates that this order will require renewal | Indicates that this ongoing order is also a subscription order which can include more detail: Renewal Interval (Required for Subscriptions, number of days) Subscription term end date (Previously labeled "Renewal date", Required for Subscriptions, date picker) Review period (Number of days) Manually renews (Boolean, Default unchecked) Notes | ||
| vendor (Use Existing Vendor) | Purchase Order Summary | Yes, required | Yes, required | Yes, required | Yes, required | N | N | Y | N | API | Name of the vendor that will fill this order | Start with filter by vendor, not search; see if we need to add search in the future | This should be at the PO level, not PO Line level | |
| total_items | Purchase Order Summary | Yes, required | Yes, required | Yes, required | Yes, required | N | N | N | N | number | Total number of items in order based on POL quatity information | Stacks: No PO with 0 items | ||
| total_estimated_price | Purchase Order Summary | Yes, required | Yes, required | Yes, required | Yes, required | N | N | N | N | number | total estimated price of order based the sum of POL cost information | Stacks: Can have N/A price or 0. | ||
| Purchase Order Line | ||||||||||||||
| currency | Cost Details | Yes, required | Yes, required | Yes, required | Yes, required | N | N | N | N | currency code | Currency in which cost information is reported | Currency options are controlled by the currencies allowed for the vendor. Make sure the system could encumber in one currency and pay in a different currency. Use the ISO currency codes. | ||
| list_price | Cost Details | Yes, required | N/A | Yes, required | Yes, required | N | N | N | N | number | Unit price of material | A-M: maybe add separate field for estimated net price? Use est net price for encumbrance. Est net price is calculated based on vendor discount/added fee percentages and the quantity. List price stays list price and is needed for informational and reporting. (I want to compare my final payment against list price) | ||
| list_price_electronic | Cost Details | N/A | Yes, required | Yes, required | Yes, required | N | N | N | N | number | Unit price of electronic material | A-M: maybe add separate field for estimated net price? Use est net price for encumbrance. Est net price is calculated based on vendor discount/added fee percentages and the quantity. List price stays list price and is needed for informational and reporting. (I want to compare my final payment against list price) | ||
| quantity_physical | Cost Details | Yes, required | Yes, required | Yes, required | N | N | N | N | number | Number of units being ordered | ||||
| quantity_electronic | Cost Details | Yes, required | Yes, required | Yes, required | N | N | N | N | number | Number of units being ordered | Ideally has an expanded view for detailed numbers | |||
| additional_cost | Cost Details | Optional | Optional | Optional | Optional | N | N | N | N | number | Lump sum that is added to the total estimated cost - not affected by discount | Lump sum that is added to the total estimated cost - not affected by discount | ||
| discount | Cost Details | Optional | Optional | Optional | Optional | N | N | N | N | number | Percentage or amount that is subtracted from the list price time quatities calculation before additional cost | Percentage or amount that is subtracted from the list price time quatities calculation before additional cost | ||
| po_line_estimated_price | Cost Details | Calculated | Calculated | Calculated | Calculated | N | N | N | N | Calculated | Calculated total cost of the purchase order line material | is this actually needed? we have a total at the PO level, and we have quantity at the line - should this be changed to estimated_price? | ||
| access_provider | e-resource_details | Not needed | Yes, required | Yes, optional | Yes, optional | N | N | Y | N | Populated by list of Vendors (with 'access provider' boolean = true) | Supplier for the electronic content. Defaults to order vendor, unless library changes. | Supplier for the electronic content. Defaults to order vendor, unless library changes. Free text field for now | ||
| activation_due | e-resource_details | Not needed | Yes, optional | Yes, optional | Yes, optional | N | N | N | Y | number | Number days after order when the resource should be activated - could be recurring). | (# days after order when the resource should be activated - could be recurring). Does this trigger a claim or needs attn on acq dashboard? George: what if activation is being handled outside of FOLIO? Does this activation type info need to be coordinated with the ERM work that the RM/Frontside folks are maybe handling? Does this really need to be part of the order? George & Steve: could be helpful, will vary by vendor; shouldn't be required | ||
| activated | e-resource_details | Not needed | Yes, optional | Yes, optional | Yes, optional | N | N | Y | Y | checkbox | The status of the resource - has it been activated on the platform. | The status of the resource - has it been activated on the platform? Does this really need to be part of the order? Part of workflow app or ERM? If the resource has already been activated by the point of order, then suppress activation_due. | ||
| create_inventory | e-resource_details | Yes, optional | Yes, optional | Yes, optional | Yes, optional | N | N | N | N | Selectlist | Describes how this POL will interact with inventory records for each material type | Relates to local inventory; needs more clarification with regards to how metadata for eContent will be handled: KB, local inventory, or both? Would this apply to ALL order lines, if we don't require creating inventory for physical materials any more? | ||
| expected_activation | e-resource_details | Not needed | Yes, optional | Yes, optional | Yes, optional | N | N | Y (maybe by date range too?) | Y | date | if you have been given an expected activation date by the vendor, you can use this date field to note it. | Start with filter only, per Aliaksei; see if we actually need a search in the future | if you have been given an expected activation date by the vendor, you can use this date field to note it. Link the 3 "activation" fields to each other and make them optional. Be very clear in FOLIO docs as to which fields will trigger notification to the library. Having 2 different fields may allow for monitoring and reporting of vendor responsiveness | |
| trial | e-resource_details | Not needed | Yes, optional | Yes, optional | Yes, optional | N | N | Y | N | checkbox | Identifies whether this is or included a trial or not. | checkbox for whether this is a trial or not. Would you even build a PO if it was a trial? Per Steve: would build a PO but not encumber any funds, if they will probably buy it. Per George: they may trial lots of stuff, but not order; would not enter order until after trial. Does this really need to be part of the order? Part of workflow app or ERM? Would it need an action date to go with it? (make decision at end of trial period to finalize/send a real order or close the order) | ||
| license | e-resource_details | Maybe | Yes, required | Yes, optional | Yes, optional | Y | N | N (would like to filter by orders that do or do not have filters) | N | link | link to a license ID or doc (licenses will be in separate app) | |||
| material_type_e | e-resource_details | Yes, optional | Yes, required | Yes, optional | Yes, optional | N | N | Y | N | API | Controlled vocabulary taken from the inventory app the identifies the type of material for each format of material being acquired | Referrence Inventory module material types | maybe this becomes po_line level; use for specific format info (e.g. for sound recordings: streaming, LP, CD) for textual: book, journal, eBook, eJournal, manuscript; have a default list, but allow the library to change the default list | |
| user_limit | e-resource_details | Not needed | Yes, optional | Yes, optional | Yes, optional | Y | N | N (may want to fitler by range) | N | number | Number of user that will be able to access concurrantly | would this be more appropriate in ERM? | ||
| fund_code | Fund Distribution | Yes, optional | Yes, optional | Yes, optional | Yes, optional | Y | Y | Y | N | string | Identifies the Fund(s) the will be charged value for this order line | fund-amount-percentage have to link together; if 2 funds, have to have 2 amounts and 2 percentages | ||
| amount | Fund Distribution | Yes, optional | Yes, optional | Yes, optional | Yes, optional | Y | N | N | N | number | Amount being distributed to the Fund | |||
| percentage | Fund Distribution | Yes, optional | Yes, optional | Yes, optional | Yes, optional | Y | N | N | N | percentage | Indicates that the distribution was originally reported as a percentage | |||
| product_id | Item Details | Yes, optional | Yes, optional | Yes, optional | Yes, optional | Y (if repeatable, how would EDI handle it? As it will not accept multiple) | Y | N | N | Editable | Identification number for material being acquired | Make sure we're allowing all kinds of product IDs, not just ISBN or ISSN. If multiple valid product IDs in the bib record, show a dropdown list and let the orderer choose which one to send. FOLIO should *not* require a product ID. | ||
| product_id_type | Item Details | Yes, required | Yes, required | Yes, required | Yes, required | Y | N | N | N | Editable | Type of indentification number being input | ISBN, ISSN, ISMN, EAN, Other Standard Identifier, Standard Technical Report Number, Publisher Number, CODEN, GPO Item Number Locally-defined identifiers Vendor Title Number Vendor Item Number | Required to identify what type of product id has been entered. Could be multiple per POL but can only send 1 per POL in EDI format | |
| productIdQualifier | Item Details | Yes, optional | Yes, optional | Yes, optional | Yes, optional | Y | N | N | N | Editable | Provides additional context to the product ID number. | Provides additional context to the product ID number. | ||
| receiving_note | Item Details | Yes, optional | Yes, optional | Yes, optional | Yes, optional | N | N | N | Y | editable | Note that is displayed at point of receipt | A-M: different from general note in that this can trigger actions or alerts at point of receipt? | ||
| subscription_from_date (Start) | Item Details | Yes, optional | Yes, optional | Yes, optional | Yes, optional | N if one-time order, Y if ongoing order? | N | Y | Y | date | Describes the initial date from which the material has been acquired | In the context of the ordre the most important element here is the Month and date. It may be paid for for many years. SOmetime the library will specify what volume they want to begin with and that will indicate what the start date will be to the Vendor. | subn start date; manually enter (or have renewal integration update these?); for one-time orders might be useful in EBA situations; for ongoing, optional because of mono series | |
| subscription_interval (Term) | Item Details | Yes, optional | Yes, optional | Yes, optional | Yes, optional | N if one-time order, Y if ongoing order? | N | N | N | number of days | Describes the number of days from the start date that the material can be considered acquired | # days; This would be automatically populated by the system based on from and to dates | ||
| subscription_to_date (End) | Item Details | Yes, optional | Yes, optional | Yes, optional | Yes, optional | N if one-time order, Y if ongoing order? | N | Y | N | date | Describes the final date on which the material can be considered acquired unless renewed | subn end date; manually enter (or have renewal integration update these?); for one-time orders might be useful in EBA situations; for ongoing, optional because of mono series | ||
| edition | Item Details | Yes, optional | Yes, optional | Yes, optional | Yes, optional | N | N | N | date | Edition of material being acquired | subn end date; manually enter (or have renewal integration update these?); for one-time orders might be useful in EBA situations; for ongoing, optional because of mono series | |||
| location | Location Detail | Yes, required | Yes, required | Yes, required | Yes, required | Y | N | Y | N | API | Location in the library that will receive the material. Can be multiple | 1 Location per set of quantities | A-M: may have multiple levels (e.g. building + collection). Assume that FOLIO will use locations for eResources. The URL *is not* the "location". Location would be "internet" or "online" or other things like that. What if ordering 20 copies of a book for 4 different locations; needed at the order phase because of vendor shelfready processing. Need to associate quantity and maybe fund with separate locations. | |
| quantity_physical | Location Detail | Y | N | N | N | editable | Quantity being received at that location | |||||||
| quantity_electronic | Location Detail | Y | N | N | N | editable | Quantity being received at that location | |||||||
| receipt_due | Physical Resource Detials | Yes, required | Not needed | Yes, optional | Yes, optional | N | N | Y (maybe by date range?) | Y | date | This applies to physical only (activation_due is the E equivalent). Date item should be received by according to agreement. | This applies to physical only (activation_due is the E equivalent). Date item should be received by; can be edited manually. Would this trigger a claim or show on a needs attn dashboard for acq? Could apply to one-time and/or ongoing; for onging, use the renewal interval or manually set (for mono series) | ||
| expected_receipt_date | Physical Resource Detials | Yes, required | Not needed | Yes, optional | Yes, optional | N | N | Y (maybe by date range?) | Y | date | Date the library is expecting the material to arrive | This would be manually entered by the users for situations where they have made an agreement with the vendor that they can expect the item prior to the Receipt Due date | ||
| volumes | Physical Resource Detials | Yes, optional | Not needed | Yes, optional | Yes, optional | Y | Y | N | N | editable | Integer between 1-99999 for physical pieces included, if multiple volumes (not multiple quantity of the same volume) | Integer between 1-99999 for physical pieces included, if multiple volumes (not multiple quantity of the same volume) | ||
| material_type_p | Physical Resource Detials | Yes, required | Yes, optional | Yes, optional | Yes, optional | N | N | Y | N | API | Controlled vocabulary taken from the inventory app the identifies the type of material for each format of material being acquired | Referrence Inventory module material types | maybe this becomes po_line level; use for specific format info (e.g. for sound recordings: streaming, LP, CD) for textual: book, journal, eBook, eJournal, manuscript; have a default list, but allow the library to change the default list | |
| create_inventory | Physical Resource Detials | Yes, optional | Yes, optional | Yes, optional | Yes, optional | N | N | N | N | Selectlist | This will indicate to the system how the interaction in inventory should behave. | Instance, Holding, Item', 'Instance, Holding', 'Instance' | This will indicate to the system how the interaction in inventory should behave. | |
| acquisition_method | Purchase Order Line | Yes, required | Yes, required | Yes, required | Yes, required | N | N | Y | N | f | Describes how the material is being acquired | Purchase: Resource is order either via an email to the vendor or via EDI. List and Fund are required. Purchase at Vendor System: The purchase is handled through an external vendor system. PO lines are NOT sent directly to the vendor: they are packaged into POs and marked as sent. List and Fund are required. Approval Plan: An agreement is in place that the vendor sends whatever the vendor determines is necessary to the institution, in EOD format. These PO lines are not sen to the vendor, but are packaged into POs and marked as sent. List and Fund are required. Depository: The institution agrees to host gov’t publications and make them freely available. List price and fund are optional. Exchange: Exchange of resources with another institution. List price and fund are optional. Gift: The resource is granted as a gift to the institution. Technical: Use for service subscription orders without inventory, or items that have migrated from an external system. List Price and Fund are optional. Demand Driven Acquisition (DDA): Evidence Based Acquisitions (EBA): | A-M: need to define default categories, plus have this list editable by the individual library | |
| isPackage | Purchase Order Line | Yes, required | Yes, required | Yes, required | Yes, required | N | N | Y | N | boolean | Indicates that this POL is for a package of material. Multiple titles may be received against it. | |||
| title | Purchase Order Line | Yes, required | Yes, required | Yes, required | Yes, required | N | Y | N | N | editable | Title of material or Name of Package | |||
| contributor | Purchase Order Line | Yes, optional | Yes, optional | Yes, optional | Yes, optional | Y | Y | N | N | editable | ||||
| publication_date | Purchase Order Line | Yes, optional | Yes, optional | Yes, optional | Yes, optional | N | N | N | N | date (could be a range) | Date of publication | May be a single date or a date range | ||
| publisher | Purchase Order Line | Yes, optional | Yes, optional | Yes, optional | Yes, optional | N | Y | N | N | editable | Publisher of material | |||
| cancellation_restriction | Purchase Order Line | Yes, optional | Yes, optional | Yes, optional | Yes, optional | N | N | N | Y | checkbox | IF true indicates that material can not be canceled immediately | checkbox if not cancellable; could apply to any type of order | ||
| cancellation_restriction_note | Purchase Order Line | Yes, optional | Yes, optional | Yes, optional | Yes, optional | N | N | N | Y | editable | Description of the resctriction on cancelation | |||
| checkin_items | Purchase Order Line | Yes, optional | Yes, optional | Yes, optional | Yes, optional | N | N | N | N | boolean | If true this will toggle the Checkin workfolw for details items being received against this PO line. Rater than creating a piece for each unit of quantity | If true this will toggle the Checkin workfolw for details associated with this PO line | ||
| claim | Purchase Order Line | Yes, required | Yes, required | Yes, required | Yes, required | N | N | Y | Y | checkbox | Should this be claimed or not (UI toggle:default true) if something is not correct | Should this be claimed or not (UI toggle:default true)? A-M: will there be defaults based on vendor or order template? Might be different claim cycles for P and E. Claim dates for subns usually based on subn date. For standing orders, often have to manually set it. | ||
| claim_grace | Purchase Order Line | Yes, optional | Yes, optional | Yes, optional | Yes, optional | N | N | Y (maybe by date range?) | Y | date (default from vendor value but editable) | date a claim will be sent; calculate from the expected claim date in vendor module, but allow it to be manually set/overridden as well | A-M: date a claim will be sent; calculate from the expected claim date in vendor module, but allow it to be manually set/overridden as well | ||
| claim_sent | Purchase Order Line | Yes, optional | Yes, optional | Yes, optional | Yes, optional | Y | N | Y (maybe by date range?) | Y | date | date a claim was sent | date a claim was sent | ||
| collection | Purchase Order Line | Yes, required | Yes, required | Yes, required | Yes, required | N | N | Y | N | checkbox | Flag to indicate whether the order is for a collection of items or not. | A-M: Flag to indicate whether the order is for a collection of items or not (does the line have multiple line items). Might be manually set; Default to No. May still be some questions around this data element, why it's needed, and how the system uses it | ||
| po_line_description (was header_description) | Purchase Order Line | Yes, optional | Yes, optional | Yes, optional | Yes, optional | N | N | N | Y | editable | free text about the order line; not intended to be a vendor note or internal staff instruction | free text about the order line; not intended to be a vendor note or internal staff instruction | ||
| po_line_number | Purchase Order Line | Yes, required | Yes, required | Yes, required | Yes, required | N | Y | N | N | editable | FOLIO PO number plus a "-" and a possible three digit number sarting at 1 | Will be viewed by Vendor (Alma = POL, Voyager = VLI) [system will also assign a UUID to the line] make sure we're clear on which order numbers are output to vendors in EDI & expected back in invoices. In succeeding FYs, the system would use the name PO Line Number, but assign a different UUID. | ||
| receipt_status | Purchase Order Line | N | N | Y | Y | hardcoded | Descripbes the status of this POL in relation to it's receipt lifecycle | Pending, awaiting receipt, partially received, fully received, receipt not required, cancelled. | ||||||
| payment_status | Purchase Order Line | N | N | Y | Y | hardcoded | Descripbes the status of this POL in relation to it's payment lifecycle | Pending, awaiting payment, partially paid, fully paid, payment not required, cancelled. | ||||||
| order_format | Purchase Order Line | Yes, required | Yes, required | Yes, required | Yes, required | N | N | Y | N | hardcoded | Physical, Electronic, P/E Mix or other. Determines what information is required. | Physical Resource, Electronic Resource, P/E Mix, Other | whatever formats the library wants to put in their list (Only P/E/Mixed at this level, with more granularity at the item level? (streaming audio, CD, audiocassette, LP, 8-track, etc) [do we need a column for mixed?] | |
| receipt_date | Purchase Order Line | Yes, required | Yes, required | Yes, required | Yes, required | N | N | Y (maybe by date range?) | Y | Calculated/editable | Date material is received by the receiving librarian | Should read "expected receipt date". Calculated base on order date and Vendor Reciept interval Start with filter only, per Aliaksei; see if we actually need a search in the future | may be set automatically when user receives an item (click "receive" button) or perhaps an automatic receipt when processing the invoice. May be multiples (if various quantities/volumes received on different dates) | |
| Created_date | Purchase Order Line | Yes, required | Yes, required | Yes, required | Yes, required | N | N | Y (maybe by date range?) | N | Date | the very first date/time the PO Line started to be built | Start with filter only, per Aliaksei; see if we actually need a search in the future | the very first date/time the PO Line started to be built | |
| rush | Purchase Order Line | Yes, optional | Yes, optional | Yes, optional | Yes, optional | N | N | Y | N | checkbox | Indicates this is a ruch order | |||
| source | Purchase Order Line | Yes, required | Yes, required | Yes, required | Yes, required | N | N | Y | N | Enumerated | What generated the orderline. (User, System etc.) | User, API, EDI, MARC | Manual created in FOLIO [eventually sent via e-mail or EDI], loaded from vendor [MARC-FTP, API, etc] - need to define the values better eventually. Ideally set by the system and not the user | |
| donor | Purchase Order Line | Yes, optional | Yes, optional | Yes, optional | Yes, optional | Y | Y | N | N | editable | Name of donor | Name of donor | ||
| requester | Purchase Order Line | Yes, optional | Yes, optional | Yes, optional | Yes, optional | Y | Y | N | N | editable | Name of requester associated with donation | Name of requester associated with donation | ||
| selector | Purchase Order Line | Yes, optional | Yes, optional | Yes, optional | Yes, optional | Y | Y | N | N | API | Name of selector | Should be populated by user id | ||
| tags | Purchase Order Line Tags | Yes, optional | Yes, optional | Yes, optional | Yes, optional | Y | N | Y | Y | editable | ||||
| vendor | Vendor | Yes, required | Yes, required | Yes, required | Yes, required | N | N | Y | N | API | Who the material is being acquired from of through | Start with filter by vendor, not search; see if we need to add search in the future | This should be at the PO level, not PO Line level | |
| note_from_vendor | Vendor | Yes, optional | Yes, optional | Yes, optional | Yes, optional | Y | N | N | Y | editable | Could be used for UPS tracking number, updates from vendor on open orders. | could be used for UPS tracking number, updates from vendor on open orders; will be manually added to FOLIO to start; maybe will be used for automatic status report updates in the future | ||
| instruction_to_vendor | Vendor | Yes, optional | Yes, optional | Yes, optional | Yes, optional | N | N | N | N | editable | This would be sent to the vendor as additional context (Instruction to Vendor) | This would be sent to the vendor as additional context (Instruction to Vendor) | ||
| vendor_ref_no | Vendor | Yes, optional | Yes, optional | Yes, optional | Yes, optional | Y | N | Y | editable | Specific indentifier used by vendor to indentify material being acquired | This will need to be a repeatable field to accommodate Title numbers, Orders numbers and other vendor numbers that need to relate to a single POL. | mostly will populate from vendor data, but need to allow manual editing by library (e.g. vendor Title ID) | ||
| vendor_ref_no_type | Vendor | Yes, optional | Yes, optional | Yes, optional | Yes, optional | N | N | Y | Harcoded | Type of indentification number being input | New Values: * Vendor continuation reference number - (replaces Library's continuation order number and Supplier's continuation order) * Vendor internal number - (replaces Internal vendor number) * Vendor order reference number - (replaces Supplier's unique order line reference number) * Vendor subscription reference number - (replaces Agent's unique subscription reference number) * Vendor title number - (new - does not replace anything) | This will need to be a repeatable field to accommodate Title numbers, Orders numbers and other vendor numbers that need to relate to a single POL. | A-M: require if there is a vendor_ref_no [categories - may need to review categories and tweak; may want to have a default list, but allow adjustments by individual library] | |
| vendor_account | Vendor | Yes, optional | Yes, optional | Yes, optional | Yes, optional | N | Y | N | N | editable | Account number with the Vendor under which the material is being acquired | Initialy populated by Vendor record Account Number |
Order Screen:
Data Flow(s):
ERD (Entity Relationship Diagram):
.png?version=1&modificationDate=1532634417000&cacheVersion=1&api=v2&width=383&height=250)
Mockup:
https://sketch.cloud/s/RMywj/all/page-1/orders