Skip to end of banner
Go to start of banner

Create invoices by importing MARC Bibliographic Records

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 16 Current »

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 previouslyIN ANALYSIS


Firm order shelfready workflow
Allow users to create field mapping profiles, action profiles, and job profiles to support MARC-based invoicing dataIN 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

Conclusion

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 invoicesWe 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)

  • No labels