| Jira Legacy | ||
|---|---|---|
|
...
|
| Status | ||||||
|---|---|---|---|---|---|---|
|
Problem(s):
- Monographic vendors often supply invoice data in 9xx fields of MARC bibliographic records.
- FOLIO can import invoice data from EDIFACT invoices, but not (yet) from MARC records. For some acquisitions methods (e.g. approval plan automatic purchases, PDA/DDA automatic purchases), importing invoice data from MARC records is simpler and requires fewer steps than importing MARC and EDIFACT data separately. This is very heavily used by some libraries from multiple vendors, especially large libraries with approval plans.
- This is one portion of a larger overall MARC-based workflow, where the MARC file is imported to create Orders, Invoices, SRS MARC Bibs, Instances, Holdings, Items, most especially with regards to purchases that do not previously have orders or Inventory records.
...
Requirement | Status | Use cases | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|
| Allow users create invoices and invoice lines based on invoice data supplied in MARC bibliographic records, and link to POLs that are created in the same import |
| Approval automatic purchases, DDA purchases | ||||||||
| Allow users create invoices and invoice lines based on invoice data supplied in MARC bibliographic records, and link to POLs have been created previously |
| Firm order shelfready workflow | ||||||||
| Allow users to create invoicing for volumes of monographic series, based on matching from individual monographic cataloging records to the POL for the standing order |
| Standing orders where pieces are cataloged separately with no link between the standing order POL and the monograph's MARC Bib or Instance; will match POs and Invoices based on POL or VRN. If Invoice and POL/VRN data comes in a MARC record, it would be covered by this feature. If Invoice and POL/VRN data comes in an EDIFACT invoice, it would be covered by the EDIFACT invoice feature. (from U Chicago) | ||||||||
| Allow users to match to the correct POL via Instance HRID |
| Vendor has the Instance HRID (not a POL or VRN); need to use the Instance HRID to link the Inventory records to an existing one-time POL, and to link a newly-created invoice (from MARC Bib) to that POL. Maybe put the Instance HRID in a VRN field of the POL, or maybe the Instance HRID is already known by the POL behind the scenes. Needs to be diagrammed to confirm the workflow and data flow. (from U Chicago) | ||||||||
| Allow users to create field mapping profiles, action profiles, and job profiles to support MARC-based invoicing data |
| |||||||||
| Firm orders - get the invoice and the order was not created | Sometimes with Order APIs or the wrong account number was assigned, and need to find the correct POL to link to |
Sample FOLIO Invoice Field Mapping screen
...
Question | Status | Conclusion | Comments | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| With MARC invoice data, invoice-level charges (such as shipping or sales tax) may not be available for import. Is that OK? |
| Since the FOLIO invoice is created with Status = Open, the user can manually add any invoice-level charges before review/approval | |||||||||
| What should be done with the Lock total field in MARC invoice field mapping profiles, since there's no "invoice total" available from the invoice data on individual MARC records? |
| Leave the lock total checkbox and lock total mapping field blank for MARC Invoice field mapping profiles? | |||||||||
| Are there any required fields for EDIFACT invoice field mappings that need to be handled differently for MARC invoices? |
| ||||||||||
| Sometimes data for one invoice is supplied in MARC records that are spread over multiple files. If additional invoice lines are imported in a separate MARC import, should the action be CREATE or UPDATE |
| Should DI assume that all MARC 9xx data referencing the same invoice number and date, and imported on the same day, belong to the same invoice? If no, how to decide which lines belong to which invoice? If yes, and all are added to the same FOLIO invoice, worst case scenario would have the user deleting some extraneous invoice lines from the FOLIO invoice before approval. If only using the Create action, no match profiles would be needed. | |||||||||
| What if invoice description comes from a 49x field, which is repeatable? |
| OK to just choose the first one? | |||||||||
| Are there other scenarios of MARC invoice data that have not been captured in the above examples? |
|
Developer Questions:
Question | Status | Conclusion | Comments | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| If vendor supplies invoice data in YYYYMMDD format, can we convert it to FOLIO YYYY-MM-DD default format? |
| We should not need additional logic for this. | We already do this for EDIFACT dates. | ||||||||||
| Would we be able to support other invoice date formats? |
| Best to require that vendors supply dates in YYYYMMDD format. Is that OK with the SMEs? | Devs would need to do some work to support other date formats. | ||||||||||
| Can we do cascade logic for MARC fields in the Invoice field mapping profile? |
| Per the devs, it should work fine. Clarify with SMEs if the MARC mapping is for a repeatable field (e.g.490$a) | |||||||||||
| For prices, FOLIO always wants an explicit decimal (e.g. 25.15, not 2516, correct?) |
| Yes, we always want explicit decimals | |||||||||||
| Are any changes needed to the invoice field mapping profile to support MARC data? |
| UI: probably no BE: Kateryna Senchenkoto review and add stories | |||||||||||
| Any changes needed to Action or Job profiles to support MARC invoice data? |
| UI: probably no BE: TBD | |||||||||||
| Will the field mapping work if there's just a VRN and no mapping for POL? |
| Probably yes. Would be good to test to make sure no issues. | Doublecheck - this would be the situation for approval plan and DDA invoices. | ||||||||||
| What if 2 9xx fields on the same MARC record (like vol 1 and vol 2 invoiced separately, but on the same MARC record) |
| Will need to make adjustment in the parser; not a situation that we see in EDIFACT invoices | We currently cannot create 2 FOLIO records based on 1 input record. Since it's invoice data, and broken out in 2 separate MARC fields, and only creation (not update), would it be possible without a lot of dev work? | ||||||||||
| For fund/expense class data, which is preferred? |
| Question for Dennis Bridges /Thunderjet Each value in separate MARC field e.g. $a USHIST $b Electronic Both values in same MARC field, separated by colon e.g. $a USHIST:Electronic Do we have to support both? (since the fund:expense class may have been consolidated during the order process) |