Bib records required in Inventory to create Orders?

In the Metadata Management Sig meeting today we had a long discussion about orders and whether they could be created in a “Free-living” state without requiring them to be attached to a bib record first, the idea being to avoid creating “dummy” bibs just so you can create an order.

Some examples of when people currently have to input dummy orders include standing orders for series where the series order has to be on a suppressed bib and the titles are cataloged individually, or a gift which is received en masse and then individually cataloged, or a large purchase where there it is not possible to load/create bibs for all the titles and you just need to get a payment in the system.

I want to clarify a few things from that discussion

1. Obviously, we would still want to associate/link/relate orders to bibs in the majority of cases
2. But, sometimes you want to do that after the fact, like in the case of having to make a PO to pay a huge order and then individually cataloging the books later.
3. But that would mean wanting/needing to associate multiple bibs to one order. I know this is not the norm, but think of it like an invoice. But it would be awesome and solve a lot of problems, like huge numbers of books not having any associated acquisition info because the order lives on the series record.
4. Most people would probably still want a traditional workflow of load bib, create order, check line item off of invoice
5. My concern was with being required to always create a bib record before creating an order.
6. And if we are required to create a dummy bib in all cases to start the order creation process, it would still be great to link multiple bibs back to one order post-cataloging.

I agree with all of the above. Dummy bibs (in our system) are notorious for being very difficult to search - they use made-up names, and half of them are titled [Membership], and it drives us nuts.

Some more use cases:

• One-line billing. Sometimes we can attach this to a beautiful OPAC database-level bib, but often what you’re buying all in one gulp doesn’t correspond to something you can describe and link to on a single record.

• When your order is for a P+E combo, and so you have two different bibs… which one do you attach the PO to? For us, it’s varied over the years, depending on which bib was in the system first, so we have to hunt multiple places to find the right payment. If you could associate it with both, that would be cool.

• A bunch of ebook vendors are happy to send you MARC records after you’ve placed the orders. Sometimes those MARC records are actually good! But we already had to get MARC elsewhere just to create the purchase order, so it doesn’t help.

Maybe some of the other aspects of FOLIO’s structure solve some of these problems already - particularly the KB knowing what titles are associated with particular standard packages that a vendor sells? But in general, I support having the option to create a purchase order first and attach it to its beautifully detailed particulars after.

Thanks for bringing up the point that in many cases our dummy bibs are already hard to search. I don’t think the idea of searching, in say an order data base, or having to execute a particular type of search in Inventory, to find a free living order that in a traditional system would be attached to a dummy bib is that much more onerous than the current situation in many of our ILSs. Plus, dummy bib cause all kinds of other reporting problems. Food for thought!

Dummy bibs being hard to search is one of the fundamental experiences of my life in e-resource acquisitions! We rely heavily on a spreadsheet outside of the ILS to be able to associate order #s with resources that we pay for but don’t have a good bib equivalent in the ILS and the order has been put on a dummy bib with a weird name by someone else 10 years ago and is impossible to find unless you have the order number.

In RM SIG we have discussed several times whether orders should have to be attached to a bib, and I think there is consensus that it shouldn’t be required, but we haven’t figured out if they should be “free-living” or attached to another record type. One suggestion that I am a proponent of is to use a “resource record,” an idea which comes from ERM-land, but could also be used for things like memberships that are used to acquire print periodicals.

Hi all,

Just to be clear - #5 in the original post is slightly misstated. If a library chooses to start an order without creating a bib in inventory, then our current planning involves the FOLIO order app automatically passing basic info to the inventory app to create a brief instance/holdings record, and possibly an item record. No one will manually have to enter an inventory record to begin an order. The library may then choose to upgrade that inventory record to a more complete record or ignore it when the electronic material is activated/paid and/or the physical material is received/paid. If the library is starting with an existing inventory instance record, or an instance record imported from an external source (e…g. vendor records, OCLC, national databases, etc), then the resulting order will be linked to that inventory record.

After MM SIG last week, I checked with a number of people involved in orders, codex, and inventory, as well as the overall FOLIO architecture, to make sure that my understanding of the structure was accurate. My understanding is as follows:

1. The only place I can see all the things that my library has (owns, has access to, or are on order) is the codex.
2. The codex gathers search results from external KBs and local inventories. At the moment, there are no plans (that I’m aware of) to have the codex consume search results from any other FOLIO apps besides the local inventories.
3. Local inventory = instance records, and eventually may include other types of thing records, such as package records or perhaps resource records like Virginia mentions. Attached to those instance records may be holdings records and item records.
4. Item records are required to circulate physical things in FOLIO.
5. Item records cannot link directly to instances. They connect to holdings records, which in turn connect to instance records.
6. Right now, the instance records in the inventory are 1) created by loading MARC records, which are then converted to the FOLIO instance format, or 2) created manually. After MARC, the inventory will support other metadata formats, e.g. Dublin Core, EAD, BIBFRAME, etc - all of which will be converted into the consistent inventory format, and then consumable by the codex.

If there is intent to have local inventories stored in some other format or structure than what has been developed so far, that needs to be sorted ASAP, since it is foundational to so many aspects of FOLIO.

Likewise, if there is intent to have the codex consume metadata from any FOLIO app other than the inventory, then that needs to be sorted ASAP as well.

And I guess my one big outstanding question is this - if the system is automatically creating a brief inventory record for ordered materials, but those materials may eventually be cataloged in a different way, I’m not quite understanding why that is a problem. The inventory record provides an opportunity for the order to be discovered in the codex, and keeps the library from having to search multiple FOLIO apps to discern whether they have something. That inventory record can be suppressed from end user discovery, so it won’t confuse patrons. Orders can be retrieved in the orders app via PO number/other control numbers or vendor if the title of the inventory record is not helpful. If staff need to retrieve the inventory record, but the existing title of that brief auto-generated record is not helpful, then alternate titles can be added to the inventory record.

And to be clear, I’m not 100% invested in any of this being any particular structure. What I am 100% invested in is that if we intend any other sort of structure - whether that comes from the ERM work or from the SIGs or from the PC - then that has to be figured out right now, given how fundamental this is to the overall structure of FOLIO, how many apps are potentially affected, and how much development work needs to be completed in the next few months.

I could see there being more than one solution depending on the type of problem, for example, memberships and batch payments are very different situations.

Jessica

Will there be a way to associate an order with multiple bib records? See, for example Heather’s question about one payment that gets you P&E and in most systems you currently have to arbitrarily choose which bib (instance) to attach your order to. Or my example of a batch purchase, where you create a dummy bib to expedite payment of a one line invoice. Then those titles later get individually cataloged. Would there be a way to associate them with that original order after cataloging? In other words, a many to 1 relationship. That would perhaps be the most helpful.
Also, if dummy bibs (well, instances) are part of the FOLIO workflow, it would be great to have a way of tagging them as such. For many of us dummy bibs, even (or perhaps especially suppressed ones) are the bane of our existence. They clutter up reports, they lack items (or in Aleph they may lack holdings records–we can create items without holdings), they always look like errors. It would be great to 1) easily exclude them from searching or reporting of “real” bibs/instances or 2) only search among them, which would greatly aid people who are on the hunt for a dummy bib created for ordering.

Thanks for points 1-6 you laid out above. This is very helpful.

Ann-Marie, do you know if there is a plan for/has been discussion of a way to associate instance records with each other (other than the package option, which might work)? I’m thinking of the example of a brief instance record for a series standing order, which it would be nice to have associated with individual (full) instance records for titles in that series.

As much as I don’t like “dummy” records, I think your point about where information about what we actually own resides, potentially only in Codex, is salient.

What matters to me is that brief records can be generated fairly automatically and records should be able to be associated with each other in non-convoluted ways (and that this data can, ideally, be extracted as well).

There are some issues about this discussion that have me concerned, but I’ll try to represent what I’m thinking to the best of my ability.

1. It seems clear, from @Ann-Marie’s explanation, that a bib record is not required to create an order. A bib record, to me, implies a MARC bibliographic record, which would reside in WeCat. So it does seem like for @Heather’s concern about having to bring in a record at the time of ordering is addressed. If you are are ordering an individual title, you can create the order, have an instance in Inventory, and then link up the bib record to the inventory record after the order has been placed.

2. That said, it seems that we are on a path where we have replaced the “dummy bib record” with a “dummy instance record,” and I hope that within the RM SIG, we have been clear that we don’t want to have instances in FOLIO that actually represent bundles of content, that we need something like a package/resource/e-resource record to represent those bundles of content that have relationships to each other. Otherwise, we are gong to need to have some sort of situation where either we have to relate instances to instances (and what does a package instances really mean anyway), or we’ll be relying on external spreadsheets, and finding tools to help us identify what bundles of content belong to what package and where the financial information (orders, invoices) for that bundle of content lies within the ILS.

A major problem that I have is answering the question, “Why do we have this?” Sometimes it is easy, but often times, we haven’t been consistent with the various ways we try to associate individual titles with a package, so I’m left asking questions like,

• Are we supposed to have access to this journal?
• Is this item owned in perpetuity or did we just lease it?
• What years are we supposed to have access?
• How are we paying for this?
• Did we pay for this already this year?
• Where is the payment information?

Have the Resource record, and having that Resource/Package record be directly associated with financial information, and with the individual instances that make up that Resource/Package is a critical component of an ERM, and has broad application for non electronic materials as well. When we worked on Kuali OLE, we set up an E-Resource record that would pull together all of the individual titles under a package, and if those titles had individual POs, they could get pulled together as well, and if there was a “top-off fee” that provides a bunch more access to a bundle of titles, that could get attached to the main E-Resource record. Then, in one location, you could see what you were paying for for a package of content.

I believe that harmonizing the data model to incorporate these ERM principles will take place at WOLFcon. I feel like what I don’t understand right now is whether some sort of Package/E-Resource/Resource record will be represented in Inventory. What I want to avoid is having to create an “instance” for package.

Thank you for so clearly articulating your concerns, which I share, and for also explaining how this was envisioned in OLE, which is the functionality I’d like to see in FOLIO as well.

I agree that we want to avoid creating “instances” for packages of content.

I am in complete agreement with Kristin as well. My simple summation for what we want is this: a purchase order should be attached to a record that represents the thing it pays for. If it pays for a single title, then it can be attached to a bib. If it pays for multiple titles, it can be attached to a package/resource. If it pays for a platform fee, it can be attached to a platform or organization record. This does mean that we need to make sure that we are appropriately modeling all the things that we will want to pay for. I agree that this should be a top priority at Wolf Con.

Great summation, Kristen!

Thank you for the clarification, @Ann-Marie! I’m a little more hopeful for the searchability of the “dummy” if they’re being automatically generated by FOLIO - that suggests to me that we can have the automation clearly mark them as such.

@kmarti’s post addresses things I’ve been flailing to find words for, particularly #2. (Thank you!!) I’m still word-flailing, but:

This, yes. Most of our “dummy” bibs exist because they describe a bundle of stuff that can’t be nicely cataloged, and might not even have a consistent “title”. And then once we’ve loaded nice metadata for the individual titles within the bundle, none of those titles are actually linked to their relevant payment. We need that connection to exist within FOLIO.

I had a meeting today with colleagues from three union networks (GBV/hbz/BSZ) and we discussed which method would work for us.

In the beginning a simpler solution with a dummy instance record would be okay with us. However, it would be ideal if an order could be attached to any object, depending on what is ordered. So, for a single bib record to the corresponding instance record in inventory. If there is an order for several bibs, then to a package/resource object in inventory. If you pay for a platform access, then the order should be associated to a platform. @kmarti summarized it all well.

Would it make sense to be able to link orders with holdings and/or items? Are there any considerations on how to deal with standing orders yet?

I would like to know more about how packages will work in order to understand if that model will always be a satisfactory solution to the one order, many bibs/instances situation, or if we might still want/need to associate one order with multiple instances/bibs directly rather than through a package.

Jessica