How do I communicate divestment in ONIX? What are common problems?

In either the common scenario of a distributor picking up or losing a client, or the less common event of product ownership changing, you should tell people who need to know. And ONIX 3.0 offers ample means to improve accuracy about market definitions.

Who needs to know is covered beautifully in an infographic published by our UK sister agency, the Book Industry Communication (BIC) group:

This documentation will cover the most common case of distribution change as a detailed workflow, but please read the common problem section below as there are some practices in North America that work against this simple and clear method.

Change of distribution

There are so many options possible when a publisher sells a product line to another publisher (starting with whether the ISBN is being maintained or not) that a workflow chart would get unnecessarily complex. Suffice it to say here, changing ISBNs is simple and maintaining the previous publisher’s ISBNs requires trading partners who understand what the expected outcome should be.

The common case, where distribution changes, is handled in ONIX by

Code list 65 Product Availability

ONIX 2.1 also supports Code List 54 and the equivalent code is:

The less common case, where the product’s ownership changes publisher, is handled in ONIX by

ONIX Code List 64 Publishing Status

Optional consideration: There is a way to use the mandatory ONIX record’s notification codes to make a clear statement of selling or acquiring a product BUT the use case it supports is publisher to publisher communication and it’s not clear how many are prepared to use it. It’s noted here for reference and consideration, as better support of notification codes may help solve issues.

ONIX Code List 01 Notification or update type

A typical workflow for the common use case of a change in distribution

Notices

• As covered in the previous post, the publisher works with the incoming and outgoing distributors in advance to set various dates to be publicized, the most important of which are:

  • the date when the distribution changes; and

  • dates for when and how returns will be accepted by both parties.

• The terms for the new distributor agreement should be clear, particularly if there are any changes.

• Highlight any special considerations, especially concerning the handling of forthcoming titles that will appear after the date of the change.

• Ideally this information is distributed to trading partners well in advance but it should at least be as soon as possible.

ONIX metadata

• The outgoing distributor continues to show the books with appropriate availability up to the date of the distribution change.

• This is a good time for the publisher to clean their lists and declare books out-of-print if they do not plan to move them to the new distributor.

• On or just before the date of distribution change

  • The outgoing distributor lists ALL of the product line showing all active, forthcoming, or out-of-stock books whose data they had been distributing with a Product Availability code of “43” to show the books are “Not Our Product” (NOP). There should be no need to update out-of-print codes but all codes should be associated with a not-accepting-order status (read the code list “Notes” if you’re unsure).

• On or just after the date of distribution change

  • The incoming distributor lists ALL of the product line they are selling with an appropriate List 65 code showing the books as available for order.

• After the date of distribution change

  • Ideally the outgoing distributor should no longer reference these books in their delta feeds, but trading partners loading data should be aware that full data distribution can take time.

  • Companies loading full or complete files issued by the outgoing distributor should expect to find the NOP references in the data and should ensure that they do not overwrite active data from the new distributor.

  • The outgoing distributor should drop the records from their active feeds (including complete files) once the return period is past and they no longer have a business relationship with the client.

  • The outgoing distributor should maintain the records in case of a request from a trading partner.

  • The incoming distributor should continue to support their data normally after the initial file, but it’s strongly recommended that they continue to issue a full set of records for their new client in several delta files over the next month or two. This will ensure that retailer processing logic will have several opportunities to catch up to the new client’s data as well as correcting the data left or created by activity in the outgoing distributor’s feed.

  • In the case of very large clients, the incoming distributor should work with their trading partners to solve issues as repetition of all available data in delta files might not be practical.

Common problems

Forthcoming books

In a well-planned change of distribution (or a change of ownership), there will be forthcoming books that will never be handled by the outgoing distributor (or publisher) and they represent a potential for extra costs. A common solution is for the incoming distributor to list these forthcoming books and accept orders in advance of the distribution change. This is an excellent solution if this information is announced in advance of any records appearing for these products. Your trading partners often have associations linking publishers and distributors and, if they aren't prepared, these forthcoming records can cause problems. It’s probably best if the outgoing distributor never carried the records. If the publication dates are months in the future, the outgoing distributor might work with their trading partners on accepting an early transfer to the new distributor.

In a less-well-planned change of distribution (no judgement!), where the advance notice is better measured in weeks, it might make the most sense to leave any existing “Not Yet Published” records with the outgoing distributor and add new ones to the first release of data by the incoming distributor.

Distributors supplying non-standard ONIX

The most common problem in North American data is created by distributors (often supported by similar retailer and publisher expectations) supplying data that does NOT recognize that the ONIX standard defines both Sales Rights and Publishing Status as describing the publisher’s relationship to the ISBN/product. These feeds usually feature the distributor using the publisher’s Sales Rights as a proxy statement for their territorial rights and supplying either incomplete or no territory statements defining their rights.

The logic ONIX uses to communicate change like this clearly depends on consistent use of its definitions. Maybe we all can get on without using Notification Type codes for Publisher Ownership but we have to rely on meaningful status codes to know what’s going on with other changes.

I’ll describe a particularly extreme example of the consequences of this practice. Please note that this list is based on an actual and real use of metadata in BiblioShare. It is neither enhanced for effect nor is it a good idea with good outcomes.

BookNet Canada received a notice from the outgoing distributor about the upcoming distribution change but we did not receive any advance notice concerning the data plans of the incoming distributor. Problems with the existing feed were traced to overwriting by competing records issued by the incoming distributor supplied as follows:

• Six months in advance of the distribution change the incoming distributor issued ONIX records that included the following:

  • Two forthcoming books not handled by the outgoing distributor (no advance warning notice but otherwise fine).

  • Most (but not all) active and in-print records still distributed by the outgoing distributor (!!! – overwriting the current accurate data). These records featured the following problems:

    • The Publishing status given as List 64 “02” “Forthcoming” – defined by its ONIX Note as “Not yet published; must be accompanied by the expected date in <PublicationDate>”. To be clear, they were changing the publisher’s, not their, relationship to the product here. It’s just wrong here and would be equally wrong if, as is more typically done, the change was made to “05” “No longer our product.” It’s the same error. This one looks worse but both are bad.

    • The Publication Date, though it was thankfully left alone, was in the past and made no sense paired with the Forthcoming status.

    • The Product Availability was given as List 65 Code “10” “Forthcoming” – defined by its ONIX Note as “Not yet available (requires expected date, either as <ExpectedShipDate> (ONIX 2.1) or as <SupplyDate> with <SupplyDateRole> coded ‘08’ (ONIX 3.0), except in exceptional circumstances where no date is known).”

    • No Expected Ship Date was found in sampled records.

    • No Territorial statements defined their relationship to the product.

This is an extreme example in the length of advance notice provided and its misuse of the definition of “Forthcoming”, but not atypical in adding the incoming books before the actual change and its lack of reference to, or apparent knowledge of, the published definition found in the Notes. Many companies use a proprietorial definition or subset list of status codes but refer to their data as “ONIX” because they use its format.

When questioned about these practices, if any reply is made, we’re normally told retailers understand what they mean and that this is the expected practice.

Food for thought

BookNet receives questions from Canadian publishers who are being questioned about these sorts of practices by US distributors. The US distributors need accurate statement to define markets. The above practices do not actually define Canada as a market consistently and certainly not well. Ill-defined Canadian data being compared to a US distributor claiming non-exclusive supplier rights to our market cannot be disputed (at least by the metadata or a set of business rules using it). Fully one-third of the Supply Details that carry a Supplier Role Code in BiblioShare’s ONIX 2.1 data (that’s “only” just over 100,000 in total because Supplier Role remains poorly supported) claim “Non-exclusive supplier rights.” Most are US distributors supplying metadata to Canada.

This originally appeared on the BNC Blog at https://www.booknetcanada.ca/blog/2020/1/27/communicating-divestment-in-onix-how-to-do-it-and-common-problems. Subscribe the the blog RSS at https://www.booknetcanada.ca/blog?format=rss.