How do I include tax and discount codes?

It's hard to avoid that some of the ONIX standard is based on retailer need and that can be hard to know until you have a direct relationship with a number of them. Small publishers starting out don't have it easy. So for their benefit here are some general pointers in filling out your ONIX records:

Tax is easy: Ignore all tax related slots in ONIX for North American metadata (Europe is a whole different answer). Book tax in Canada and the US varies by province and state — there's no unified way to express it that would apply to every jurisdiction. It is the retailer's problem to charge the correct tax based on where the sale is made using the province's or state's individual laws.   A publisher really can't help them and in ONIX, if you have nothing to say, fill out nothing.

The ONIX manual will tell you that Class of trade is a "US only" field.  There was a time about a decade ago when Class of Trade was used to carry discount codes, that's no longer the case and if you fill out Discount Codes there's no need to use Class of Trade – unless your US distributor or Sales Reps request it for purposes in the US market.   No request, fill out nothing.

Discount Code is something that is expected and should be used

Typically the Discount Code Type (List 100) should be "02" for Proprietary and the Discount Code can be any value you choose, though "trd" would be a good neutral choice.

(Proprietary codes in ONIX are codes that you choose to represent yourself.  When you create one, make it a "code" and use it consistently: A "code" should be made of basic letters and numbers and ideally look like a code – a continuous string without spaces. It should not look like a discount or any value that would be expected by the end users.  For example, "40" may be your current discount but using 40 as a discount code will lead to problems.  Someday the discount will change and your new and different discount will still be represented by a code value of "40".   Don't be witty when creating codes and do make them easily read)

Having created the code(s) you should be prepared to tell any trading partner – a retailer who's agreed to do business with you – what it means for them.   The code should appear in association with every Price (that the retailer would reference) and represents the discount paid by that retailer on that product.

The idea here is that discounts should be both transparent and private — if you were a large company you might set different discounts on different products so that different trading partners have a unique relationship with you. For instance, bulk sales of textbooks sold to a college bookstores are treated differently than single sales by a trade retail store.  Using a code allows you to support the former and the latter at the same time while acknowledging different products may have a different discount. 

A large publisher may have a list as long as 40 or 50 codes – many of which might, for a given retailer who sells single copies, represent an identical discount, while for another partner, a wholesaler or a college bookstore, might vary wildly

How do they know?  You tell them – likely after negotiation – what it means in documentation you provide to them.

Discount codes provide:

  • Transparency: Different discount codes show your overall discount structure openly.  All your trading partners can see your books grouped by a code and know there can be variation under some circumstance
  • Privacy: What each code means is held outside the ONIX file.  Your trading partners only know what discount they get.
  • Flexibility: You can update the retailer by providing new definitions.  Your metadata can remain the same.

Reality check

Most Canadian trade publishers have a single discount code applied to all records and typically have a standard discount for all accounts.  The discount coding can be as complex as your business needs require but there's no reason to make it complicated.   

Take your most complex business partner – the one with the most discount variations that needs to be accommodated – and create a code list based on their needs.  Then assess other accounts: Do you need to create any extra variations?  Once you know all the possibly variations that need to be accommodated you can create the codes you need maintain accurate discounts. Then any retailer or other type of trading partner can get a defining table based on their discounts .  Again for most small publishers there is one code and one discount for all products