In Scope: as of August 2018

  • Functionality:
    • Retrieving files? Probably not for v1; interim solution: retrieve manually
    • Staging area? Yes
    • Matching & dup rules? Yes
    • Parsing the MARC files? Yes
    • Create, Overlay/Update, Delete? Yes
    • Loading files? Yes
    • Outcomes of those loads? Yes

  • FOLIO Records Affected:
    • MARCcat Bibliographic Record? Yes, via stored MARC Bib Record
    • MARCcat Holdings Record? Yes, via stored MARC Holdings Record
    • MARCcat Authority Record? Yes, via stored MARC Authority Record
    • Inventory Instance? Yes, via stored MARC Bib Record
    • Inventory Holdings? Yes, via stored MARC Bib or Holdings Record
    • Inventory Items? Yes
    • Inventory Container? TBD
    • Orders? Yes
    • Invoices? Yes, via MARC Bib Records and EDIFACT
    • ERM? No

  • Types of Source Records:
    • MARC-21 files? Yes
      • Binary? Yes
      • XML? Yes
      • JSON? Probably not for v1
      • UTF-8/Unicode character set? Yes
      • MARC-8 character set? Probably not for v1; interim solution: convert to UTF-8 before loading 
    • EDIFACT Invoice files? Yes
    • Delimited/flat files? Yes, but lowest priority; interim solution: convert to MARC before loading 
    • Order API data? Not through Batch Loader; will be handled in a different way

  • Miscellaneous
    • Load single records into FOLIO: TBD (needs further discussion); interim solution: use Batch Loader, but something more lightweight in the future

Out of scope: 

  • Exporting records from FOLIO
  • Complete bib/holdings/item data migration from previous system (may use some aspects of Batch Loader,  but probably more CLI/JSON oriented and less UI-oriented than Batch Loader)
  • No labels

4 Comments

  1. Leeda Adkins

    For the two Out of Scope items, Duke will need both for our go-live version. I understand we aren't coming up on version 1, but I feel like I should participate as if we were. We need "exporting records from FOLIO" in order to continue participation in print retention consortia partnerships.

    For MARC invoicing, I understand the difficulties of generating a header with additional charges; however if we can generate a header with a) just the line item charges, or b) line item charges where the vendor has added the shipping into each item, the user can then go in and edit the header, and line items if needed, to fill in the additional charges and total for the invoice before submitting it for payment. 

    I can't speak for Chicago, but right now the largest amount of MARC invoicing Duke does concerns EBSCO/GOBI monographs, both in print and electronic formats. If we have to go live without this capability, EBSCO will need to make allowance for us to be 90+ days late with payments.

    Thank you for listening and being willing to consider my concerns.

    Leeda

  2. Ann-Marie Breaux

    Hi Leeda,

    Thank you so much for your comments. 

    Export is out of scope for our group, not out of scope for FOLIO v1. I'm not sure who will be responsible for it, but our subgroup will have plenty to deal with just in terms of import.

    And as for MARC invoicing, having some sort of electronic invoicing is definitely in scope for FOLIO v1. Our group will discuss MARC-based invoicing, since that's part of your current batch loads. That said, the FOLIO community will likely need to make a strong case on why MARC-based invoicing is preferable to EDIFACT (assuming EDIFACT can be well-synchronized with the MARC bibliographic loads), and why it should be prioritized over something perhaps even more forward-thinking than MARC and EDIFACT, such as some sort of API-based real-time invoicing. One of our larger goals for FOLIO in general is to begin to de-emphasize MARC, and move toward more modern structures and processes for various kinds of library data.

  3. Leeda Adkins

    Thanks Ann-Marie, for your response, and for your reassurance that export is a priority for V1, and that we will discuss MARC invoicing in the group. I think it would be optimal for FOLIO to offer several methods of rapid-invoicing, in order to make the on-boarding for libraries much easier. They could come in with their current methods of MARC and EDI invoicing, and have the option to progress to newer forms once the migration is complete.

  4. Christie Thomas

    Thanks for bringing this up, Leeda. I agree with you that it is optimal to have the ability to ingest EDI and MARC invoices.  In many ways EDIFACT is a preferable format for invoicing but, practically speaking, we have vendors that can only supply EDIFACT invoices and we have vendors that can only supply MARC invoices. Without getting into which format should be prioritized for development first, I can only say that at Chicago we would need the flexibility of both options in order to implement. I cannot see us reverting to hand keying invoices that are not able to be delivered in one format or the other.