Create invoices by importing MARC Bibliographic Records

UXPROD-663 - Getting issue details... STATUS

IN ANALYSIS

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.

Use Cases & Requirements:

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	IN ANALYSIS	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	IN ANALYSIS	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	IN ANALYSIS	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	OPEN	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	IN ANALYSIS
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

Sample MARC file with Invoice data

LDR 04480cam a2200469 i 4500
001 1163961969
003 OCoLC
005 20210715143631.6
008 201230t20212021ncua\\\\\b\\\\001\0\eng\\
010 \\$a 2020028571
040 \\$aNcD/DLC$beng$erda$cDLC$dOCLCO$dOCLCF$dUKMGB$dYDX
020 \\$a9781478010746$qhardcover
020 \\$a9781478011996$qpaperback
020 \\$z9781478013211$qelectronic book
020 \\$z9781478091691$qelectronic book
035 \\$a(OCoLC)1163961969$z(OCoLC)1163962689
042 \\$apcc
050 00$aGN345$b.E974 2021
082 00$a305.80072/1$223
245 00$aExperimenting with ethnography :$ba companion to analysis /$cedited by Andrea Ballestero and Brit Ross Winthereik. <=== Invoice line description
264 \1$aDurham :$bDuke University Press,$c2021.
264 \4$c©2021
300 \\$axi, 301 pages :$billustrations ;$c24 cm.
336 \\$atext$btxt$2rdacontent
337 \\$aunmediated$bn$2rdamedia
338 \\$avolume$bnc$2rdacarrier
490 1\$aExperimental futures
504 \\$aIncludes bibliographical references and index.
650 \0$aEthnology$xResearch$xMethodology.
650 \0$aAnthropology$xResearch.
650 \7$aAnthropology$xResearch.$2fast$0(OCoLC)fst00810227
650 \7$aEthnology$xResearch$xMethodology.$2fast$0(OCoLC)fst00916157
700 1\$aBallestero, Andrea,$d1975-$eeditor.
700 1\$aWinthereik, Brit Ross,$d1973-$eeditor.
776 08$iOnline version:$tExperimenting with ethnography$dDurham : Duke University Press, 2021.$z9781478013211$w(DLC) 2020028572
830 \0$aExperimental futures.
935 \\$a 12345-01 <=== FOLIO POL
980 \\$a 40030704058 $b ANTHRO $c KU/CC/DI/M $e GOBI $g 8910-10 $h 19935 $i 20210920 $j 25.16 $l Paper $m 27.95 $q 1 $v v.1
980: $a Vendor ref num $b Fund (expense class TBD) $c Location $e Vendor $g Account number $h Invoice number $i Invoice date $j Net price $l Binding $m List price $q Quantity $v volume

Other examples from MARC files with Invoice data

Invoice data for 2 invoices lines (e.g. 2 volumes or copies invoiced separately, in the same MARC record)

935 \\$a 12345-01 <=== FOLIO POL
980 \\$a 40030704058 $b ANTHRO $c KU/CC/DI/M $e GOBI $g 8910-10 $h 19935 $i 20210920 $j 25.16 $l Paper $m 27.95 $q v.1
980 \\$a 40030704058 $b ANTHRO $c KU/CC/DI/M $e GOBI $g 8910-10 $h 19935 $i 20210920 $j 25.16 $l Paper $m 27.95 $q v.2
980: $a Vendor ref num $b Fund (expense class TBD) $c Location $e Vendor $g Account number $h Invoice number $i Invoice date $j Net price $l Binding $m List price $q Quantity $v volume

What Backend stories are needed?

TBD

What UI stories are needed?

TBD; none identified so far, except some testing & review

SME Questions:

Question	Status	Comments
With MARC invoice data, invoice-level charges (such as shipping or sales tax) may not be available for import. Is that OK?	OPEN	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?	OPEN	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?	OPEN
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	OPEN	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?	OPEN	OK to just choose the first one?
Are there other scenarios of MARC invoice data that have not been captured in the above examples?	OPEN

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?	RESOLVED	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?	IN PROCESS	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?	IN PROCESS	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?)	RESOLVED	Yes, we always want explicit decimals
Are any changes needed to the invoice field mapping profile to support MARC data?	IN PROCESS	UI: probably no BE: Kateryna Senchenkoto review and add stories
Any changes needed to Action or Job profiles to support MARC invoice data?	IN PROCESS	UI: probably no BE: TBD
Will the field mapping work if there's just a VRN and no mapping for POL?	IN PROCESS	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)	OPEN	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?	OPEN		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)