Last week on the blog, Jackie Fry looked at communication around products changing hands — either the common scenario of a distributor picking up or losing a client, or the less common event of product ownership changing. In a nutshell, you should tell people who need to know (and who needs to know is covered beautifully in an infographic published by our UK sister agency, the Book Industry Communication (BIC) group). You should read it if you haven’t already because the whys it covers are important to understand the how-tos I cover here.
How-tos such as:
which ONIX fields you should update as a distributor;
which ONIX fields you should not update as a distributor; and
when and for how long these updates should be sent in the data when acquiring or divesting a line.
I'm only going to 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.
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
Code “43”
Description: No longer supplied by us
Notes: Identify new supplier in <NewSupplier> if possible
ONIX 2.1 also supports Code List 54 and the equivalent code is:
Code “EX”
Description: No longer stocked by us
Wholesaler or vendor only
The less common case, where the product’s ownership changes publisher, is handled in ONIX by
ONIX Code List 64 Publishing Status
Code “05”
Description: No longer our product
Notes: Ownership of the product has been transferred to another publisher (with details of acquiring publisher if possible in PR.19 (ONIX 2.1) OR P.19 (ONIX 3.0))
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
Code “08”
Description: Notice of sale
Notes: Notice of sale of a product, from one publisher to another: sent by the publisher disposing of the product
Code “09”
Description: Notice of acquisition
Notes: Notice of acquisition of a product, by one publisher from another: sent by the acquiring publisher
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
We are getting 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.
ONIX 3.0 offers ample means to improve accuracy about market definitions.
EDItEUR has released the Product safety requirements in ONIX 3 Application Note.