Supplemental Information for POS Providers

North American suppliers support X12 for EDI ordering, but US and Canada suppliers are generally on different versions. Depending on which suppliers your retailers wish to order from, you would need to support one or both standards. An exception to the rule is that Random House US is on 3060 for most documents but sends ASNs using the 4010 standard.

• US EDI Standards (3060).
• Canadian EDI Standards (4010).

The most important difference between v3060 and v4010 is the date format. In 3060, the date is almost always a 6 character date field (YYMMDD) and if the century is is included anywhere it has its own separate field. IN 4010, they extended it to be an 8 character date in most places (NOT in the ISA!), so the date format comes out to be CCYYMMDD.

The other differences tend to be in the codelists.

In addition to supporting X12 EDI ordering, many POS providers also support stock-checking with major suppliers by implementing our Pubeasy findProducts SOAP API without including a supplier mailbox, which is documented here under Retailer | Product Information Service in Section 10.1. Per 9.2.1, Find products allows to search for products on base of the ISBN or EAN of the product and returns worldwide results. The response can be one product or, if the product is available at several suppliers, a list of products in which different supplier names are listed. Complete Pubeasy SOAP technical information is available here.

When implementing the product information service, we prefer your system use a generic user that we create instead of requiring each retailer to register with us separately.

A SAN (Standard Address Number) is tied to a single physical address and to a unique supplier account number (though a SAN can be moved from one supplier account to another in cases where the bookstore transfers ownership).

A SAN can indicate a billing or a shipping address. Some booksellers with a single location may have a billing SAN/account and a shipping SAN/account. Bookstores shipping to multiple locations would definitely need separate SANs (and supplier ship-to account numbers) for each shipping address, but could choose to consolidate billing under a single account/SAN. SANs are issued by Bowker.com and cost $150. MVB can provide a single SAN for free if needed for Pubnet registrants with an EDI-compatible POS system.

X12 allows address information in the PO but in the book industry this information is disregarded (thus no drop-shipping capabilities through X12) and suppliers instead use the SAN to identify the customer in their systems and pull the shipping address from their internal systems. It is possible for the shipping address in the supplier’s system to differ from that officially associated with the SAN as suppliers have not necessarily integrated the SAN database into their systems as a single source of truth. Retailers who move their store thus need to email san@bowker.com and each of their suppliers with their new address.

The store's SAN (without a dash) will become their Pubnet username.

SANs sent in X12 should be sent as numbers only.

Our Supplier Lists include most, but not every Pubnet supplier. Those listed are generally amenable to allowing any qualifying retailer to trade over Pubnet. Unlisted suppliers may allow a Pubnet connection only for specific retailers because they are paying a third-party for EDI and it's not cost-effective for them to open the channel to smaller retailers. A basic tenet of Pubnet is that each supplier has to approve Pubnet as an ordering channel for each individual retailer.

We update our supplier lists as contracts are signed/expire, distribution contracts change, or due to merger and acquisition activity.

The presence of a supplier on the list indicates that they CAN support X12 through Pubnet, but not that they WILL specifically allow it for a particular retailer. Suppliers generally require that the retailer's account be in good standing and established on credit terms (PRH and Hachette are exceptions). Additionally not every supplier supports all X12 docs for every retailer.

An important part of the Pubnet retailer setup process is for retailers to email their suppliers prior to placing their first Pubnet orders to make sure they are approved. Thus, prior to placing their first Pubnet order with a new supplier, the retailer needs to request approval and configuration from the supplier by providing their SAN, their ship-to account number, and whether they desire additional response documents beyond POAs. Otherwise, orders placed will usually not receive a POA and will not be fulfilled. The first POA from a supplier may take longer to receive than subsequent ones due to the required configuration steps. Contacts and a template email are here.

Determining the direct distributor of a particular title or imprint may be beyond the capabilities of the POS and require the buyer's expertise. Distribution also changes frequently due to contract expirations and industry mergers and acquisitions. If not managed by the POS, retailers will need the ability to manually set a distributor for a title, make bulk distribution edits, and view a history of vendors a title has been ordered from to help them choose the correct vendor for their current order.

• The pipe (|) is the preferred element separator in the US market. Even though other separators are legal, some of the smaller vendors on this side may require a pipe.
• While it's not technically prohibited in the spec, we do not recommend including the same product on multiple line items because this may cause the purchase order to be caught in a supplier PO duplicate check and it's not always predictable how the suppliers will react. Some may cancel the line items, but it's possible that they would fulfill one, the other, both, or it could cause the entire PO to be rejected. MPS, for example, checks for uniqueness of PO/SAN/ISBN, accepts the first entry and cancels any subsequent ones even if quantities were different.
• The AC code in the BEG07 is not actually a required field in the current version of the spec, but some of the vendors on older systems won't send responses without this code so we recommend including it.
• The N2, N3 and N4 segments are defined in the spec but they are not used frequently, especially if there is no data included in them. I would recommend not including them if they are going to be vacant.
• IB should only be used for the qualifier in the PO1 segment if you are sending an ISBN10, which is becoming less frequent. The correct qualifier for the ISBN13 is EN.
• Make sure to include the CTT02 field.

• Each supplier has their own pickup frequency (at least 1x/day for smaller suppliers; larger ones usually have multiple pickups per day) and schedule and schedules can change.
• It is standard in the US to allow retailers a field to enter a promotional code for extra discount. These codes are supplied by sales reps and Pubnet passes them along but does not do any validation on them. It is up to the retailer to enter the code correctly and meet all of its requirements. The retailer should be able to tell by the cost information in the POA whether the additional discount was applied correctly or not.
• It is standard in the US to allow retailers the option to backorder an ISBN or not. There is a header-level setting in the CSH (Conditions of Sale) segment. The allowed options defined in the spec for this are the following, but a POS can implement a binary setting and does not have to support all the options. Note: If providing retailers with a binary option to backorder or not, the we recommend sending code O.
  
  For each line item, there is an optional segment called the IT8 (Conditions of Sale, line item level), where the same options exist.
  
  What we see most commonly is that POS software systems don't use the IT8, only the CSH. In cases where both are used, they generally contain the same value. BUT: If there are differing values in the CSH and IT8 code, the IT8 code should override for that line item.
  
  In rare cases, the retailer may have disallowed backorders on their account at the supplier and that setting would in turn override the IT8. The max amount of time an item will backorder before canceling is usually determined by the retailer's account settings with the supplier, but it is possible to optionally provide a shorter cancellation window.

• All suppliers should return POAs/855s. Other response documents are optional. If the vendor is able to send them, they are usually only provided on request (ask in configuration request) and not automatically for every retailer.
• Do not assume that supplier will or can send EDI response documents for purchase orders placed via a different channel.
• If a retailer uses Batch for Books to pay certain suppliers, those suppliers may not be able to send 810s to the POS (not yet confirmed).

• Every supplier supports POAs.
• POAs are usually returned by the supplier within 1-2 business days. Each supplier has their own frequency (at least 1x/day) and schedule and schedules can change.
• POAs often have line items in the same order as the original 850/PO, but this is not required by spec. A best practice is to use the ISBN to ingest POAs and not the Assigned Identification/PO101 field, since the spec states this field is only used within a transaction set, not across them.

• Not every supplier supports ASNs.
• Even if supplier supports ASNs, they may not agree to send to every retailer (retailer should request during configuration).
• Penguin Random House has currently implemented ASNs in only version 4010 of X12.
• US suppliers don't seem to be providing the UCC/EAN-128 Serial Shipping Container barcode data according to the spec or even consistently as a group.
  The specified format is to have a qualifier of GM in the MAN01, followed by the UCC/EAN-128 Serial Shipping Container Code in the MAN02. In the current US Pubnet spec (last updated in 2013), the only code defined for use is GM, but both PRH and MPS are using the qualifier CA, which is only defined in the Canadian version of the Ship Notice. CA indicates that the data in the following field is the "shipper assigned carton number", so PRH's use of the tracking number confirms to the qualifier whereas MPS's use of the SSCC-18 number from the bottom of the UPS shipping label does not since the SSCC-18 tracks the entire shipment, not an individual carton.

• Not every supplier supports Invoices.
• Even if supplier supports Invoices, they may not agree to send to every retailer (retailer should request during configuration).
• Some suppliers can send 810s to both Batch (a payment platform used by many book retailers) and the retailer's POS system, while other can only send invoices to a single recipient. If the latter, Batch has a solution in place to get around this issue. The publishers send the 810 files to them and they immediately pass it through to the POS (currently enabled only for Bookmanager).

• Please coordinate with our Support team for access for test credentials and access to our Sandbox environment.
• If you are implementing both X12 and Pubeasy productinfo APIs, we recommend using a separate user for each channel.
• Pubnet does not validate ISBNs, so you can test with any ISBN.
• Let us know what documents you plan to support (850s & 855s are mandatory) and what 850 features (promo codes, backorder options).
• The main test is for your POS to send us POs in X12 that we examine and validate.
• Once we have validated your X12, we can (with prior notice) respond to a test order with a POA and any other response documents you plan to support (Invoice, ASN).
• Once you pass Sandbox testing, you may want to run some production tests prior to inviting retailers. Please coordinate with us for production tests.
• Please do not invite users to beta test until we have certified your Sandbox test results.

• Once you have been cleared for user beta testing, please email us a list of your users and their contact information. We will handle their Pubnet registration & setup outside of our normal web registration process.
• To support your beta testers, MVB will need to know your process for entering their Pubnet login credentials (support docs or screenshots are helpful), what features you will be testing and any limitations on them (i.e., only testing with vendor x to start; not supporting promo codes yet).
• Your beta users will need existing, qualified supplier accounts. If they need help getting these, please have them contact Jill Hendrix, our Customer Support Specialist.