Wijzigingshistorie | ||
Datum | Onderdeel | Wijziging |
| Prize | Toegevoegd aan de voor gedefinieerde lijst:
|
| Subject Thema | Ondersteuning van Thema versie 1.5 in gebruik genomen |
| Subject Bisac | Op 16-05-2022 implementatie Bisac versie 2021 |
| P.26 SupplyDetail - SupplierName BS (Bookshelf) | Met ingang van 01-07-2022 zal CB Bookshelf niet meer ondersteunen, daarmee verdwijnt SupplierName BS uit het bericht. |
| ONIX upgrade 3.0.8 | ONIX upgrade 3.0.8, Code lists versie 54. Toegevoegd xsd schema's. |
| P.26 SupplyDetail composite | Uitbreiding van distributieplatforms met IMMR - Immer t.b.v. beschikbaar stellen (activeren) en terugtrekken dé-activeren) e-books bij deze platforms |
| P.3.2 ProductForm | Met ingang van 29-07-2021 worden Spiraalboek (Codelist 150 waarde BE) en Puzzel (Codelist 150 waarde ZJ) toegevoegd. Spiraalboek, code BE, werd al geaccepteerd maar in Titelbank omgezet naar Paperback / Softback (code BC), Deze omzetting wordt met ingang van 29-07-2021 niet meer uitgevoerd. |
| P.26 SupplyDetail composite Audioboeken | Eerder kondigden wij aan dat CB de mogelijkheid gaat ondersteunen om de beschikbaarheid van audioboeken voor webwinkels en verkoopplatformen via ONIX door te geven, zoals dat nu al het geval is voor e-books. Bij het ontwikkelen is echter gebleken dat het onderhouden van de beschikbaarheid voor de verkoopplatformen vanwege een nog niet volledig afgeronde transitie van audioboeken dermate omslachtig zou worden. Om die reden is dan ook besloten om enkel de beschikbaarheid van webwinkels via ONIX te gaan ondersteunen. Opname van het P.26 SupplyDetail composite met Supplier CB zal leiden tot het activeren van de beschikbaarheid van de retailers die bij CB Luisterhuis als retailer zijn geregistreerd. Desgewenst kan voor een specifieke webwinkel via CB online de beschikbaarheid gedeactiveerd worden. Het onderhouden van de beschikbaarheid voor de Verkoop- én Abonnement platformen dient in CB Online te gebeuren. |
- Berichtdefinitie ONIX 3.0 (aanleveren) - Publisher to CB
- Non-boeken (niet bibliografische werken) aanmelden via ONIX 3.0 - Publisher to CB
- Onderhouden en registreren audioboeken
- Overzicht foutmeldingen uit verwerking aangeleverde ONIX berichten
- Voorbeeld van een bibliografische aanmelding via ONIX (niet commercieel)
Inleiding
Dit document beschrijft de aanlevering van artikelgegevens van de uitgever naar Bureau ISBN en CB, deze is gebaseerd op de internationale ONIX 3.0 standaard die wordt beheerd door EDItEUR. Beschreven worden de verschillende aspecten van de gegevensuitwisseling tussen uitgevers en CB met betrekking tot:
- Interpretatie van het ONIX bericht. Welke gegevens zijn nodig om welke artikelgegevens op te nemen in het artikelbestand van Bureau ISBN en CB (fysieke artikelen en e-books)
- Omgaan met mutaties. Welke soorten mutaties kan een uitgever doorsturen op zijn titels en wanneer moet dat gebeuren
- Verwerking en foutafhandeling. Op welke manier worden de ONIX berichten verwerkt en gecontroleerd en hoe vindt hierover terugkoppeling plaats, zowel over de technische als de inhoudelijke verwerking.
- Afspraken over de aanlevering. Op welke wijze en via welk communicatiemedium worden de berichten aangeleverd.
- Welke activiteiten rondom het onderhouden van artikelgegevens kunnen niet worden aangeleverd via ONIX.
Gebruik document
De volledige ONIX 3.0 berichtdefinitie is zo opgebouwd dat de geneste structuur, met blocks, composites en elementen (tags) zichtbaar is in de inhoudsopgave. Hiermee wordt tevens de volgorde van de composites en elementen weergegeven. Vanuit de inhoudsopgave kan eenvoudig worden doorgeklikt naar het betreffende onderdelen.
Zoekadvies
Zoeken kan het best vanuit de inhoudsopgave op hoofd- en sub-pagina of door gebruik te maken van de functietoets F3 of CTRL + F op de betreffende pagina en niet het zoekveld rechts bovenaan in het CB Wiki scherm (zie onderstaande schermprint). Het document is opgebouwd uit diverse componenten, bij zoeken via het zoekveld wordt er gezocht in de componenten database en verlaat u het document en daarmee ook het overzicht op de structuur van de gebruikershandleiding en berichtdefinitie.
Uitgangsdocumentatie
De volledige documentatie betreffende de ONIX 3.0 standaard is te vinden en te downloaden op www.editeur.org. In de ONIX 3.0 bericht standaard is een zeer groot aantal gegevens opgenomen. De gehele standaard wordt aanvaard. Voor ontwikkeling van de berichtuitwisseling gaan we uit van de onderstaande versie van de ONIX standaard:
ONIX for Books Product Information Format Specification Release 3.0 revision 8, Juli 2021
Versie ONIX Code Lists 54
Opbouw Product record
Een Product record bestaat uit 1 of meerdere blokken en bevat :
<Product> | ||
Record metadata | Group P.1 | Deze blokken geven aan wat het type wijziging is er over welk ISBN de volgende gegevens uit het ProductRecord betrekking hebben |
Product numbers | Group P.2 | |
<DescriptiveDetail> ...............</DescriptiveDetail> | Block 1 | Bevat de verschijningsvorm van het ISBN en de basistitelgegevens zoals titel, reeks, auteursvermeldingen, druk/editievermeldingen, de taal waarin de publicatie is uitgegeven, de omvang, en de verschillende onderwerpcoderingen zoals NUR, BISAC en AVI leesniveau (voor kinderboeken) |
<CollateralDetail> ...............</CollateralDetail> | Block 2 | Bevat vermeldingen van cover, backcover, flapteksten en andere promotionele teksten, verwijzingen naar bestanden met leesfragmenten, filmpjes, gesproken teksten die gerelateerd zijn aan de publicatie |
<ContentDetail> ...............</ContentDetail> | Block 3 | Bevat vermeldingen over individuele hoofdstukken uit een publicatie, wordt volgens de afspraken van de ONIX Werkgroep niet gebruikt in Nederland/Vlaanderen. |
<PublishingDetail> ............... </PublishingDetail> | Block 4 | Bevat gegevens over de imprints, de eigenaar, het stadium levenscyclus en de verschijningsdatum van het artikel in de markt. |
<RelatedMaterial> ............... </RelatedMaterial> | Block 5 | Bevat gegevens over NSTC, vervangende ISBN’s en ISBN’s van een fysiek boek, waarvan een ebook is afgeleid |
<ProductSupply>............... </ProductSupply> | Block 6 | Bevat alle commerciële gegevens rondom de dienstverlening van de distributeur, zoals stadium dienstverlening, prijsgegevens, BTW en boeksoorten . |
</Product> |
Beschrijving van een Data element
Ieder Block is opgedeeld in één of meer composites, een composite is een groepering van verwante velden (data elements). Een composite kan ook andere onderliggende composites bevatten. Elk veld (data element/composite) wordt als volgt beschreven:
Element of composite - de naam van het veld | |
---|---|
Uitleg - beschrijving waarvoor het veld dient. | |
Format/Posities | Alfanumeriek of Numeriek. Voor de individuele velden wordt verklaard welke gegevens deze moeten bevatten en het formaat van het veld, numeriek, alfanumeriek. In Onix zelf worden slechts zeer beperkt veldtypes gedefinieerd; binnen CB gelden hierop echter wel bepaalde beperkingen. Wanneer CB afwijkt van een richtlijn wordt dat opgemerkt bij het veld. In velden waar getallen worden ingevuld mogen in ONIX 3.0.3. geen 0-waardes of negatieve getallen meer voorkomen. Als die er wel staan, dan is het ONIX bericht niet XSD valid. |
Reference name | Naam van het veld/element zoals gebruikt binnen het bericht |
Short tag | De codering van het veld/element zoals gebruikt binnen het bericht |
Code list | Verwijziging naar een waarde uit Code list nummer in 'ONIX Book Product Code Lists' van Editeur |
ONIX M/O | Verplicht (Mandatory) of optioneel (Optioneel) volgens ONIX 3.0 |
CB M/O | Verplicht (Mandatory) of optioneel (Optioneel) volgens CB Verplichtheid geldt op twee niveaus; een composite kan zelf optioneel zijn, maar indien toegevoegd in het bericht, moeten specifieke velden binnen die composite wel ingevuld worden. Daarom staat bij deze composite een ‘O’, maar voor velden binnen de composite een ‘M’. Ditzelfde geldt voor de waarden 'M' en 'O' van het CB. |
Aanlevering ONIX 3.0 metadata en content via FTP
De uitgever krijgt bij CB de beschikking over een FTP account, via een gebruikersnaam en wachtwoord krijgt de uitgever toegang.
Een ONIX 3.0 bericht met metadata en eventueel daarbij behorende content wordt aangeleverd als een zip bestand. In het zip bestand zitten de metadata in de vorm van het ONIX bericht en de bijbehorende bestanden (content) waarnaar wordt verwezen in het ONIX bericht.
Voor Cover afbeeldingen geldt dat naast het originele aangeleverde formaat door CB nog in drie formaten worden opgeslagen, 1400 x 1400 pixels, 800 x 800 pixels en 150 x 150 pixels (tumbnail)
Voorgeschreven bestandsnaam ONIX 3.0 metadata inclusief de content (bijbehorende bestand) | |||
---|---|---|---|
De maximale lengte van de bestandsnaam is 40, inclusief _onx.zip of onx.xml Indien de bestandsnaam de maximale lengte overschrijdt zal het bericht niet verwerkt worden. | Bestandsnaam | ||
1 | voor ZIP file | ............_onx.zip | |
2 | Voor het ONIX bericht wat in het zip file zit Indien er per ISBN één *_onx.xml wordt gemaakt dienen deze tezamen in één zipfile te worden aangeboden. Het is zeer ongewenst om per ISBN een ZIP file aan te bieden. | ............_onx.xml | |
3 | Voor de content bestanden waarnaar wordt verwezen in het ONIX bericht | E-book bestand | <ISBN>_ebfc.pdf |
<ISBN>_ebfc.epub | |||
<ISBN>_ebfc.xps | |||
<ISBN>_ebfc.mp3 | |||
Inkijktekst | <ISBN>_hfd.pdf | ||
<ISBN>_hfd.epub | |||
<ISBN>_hfd.mp3 | |||
Cover | <ISBN>_cvr.jpg | ||
Backcover | <ISBN>_bcvr.jpg |
Covers en e-book bestanden zonder bijbehorend ONIX bericht indienen
Het is ook mogelijk om covers en e-book bestanden als losse bestanden in te sturen. Om dit te kunnen doen dient het ISBN aanwezig te zijn in de CB systemen en dat de commerciële aanmelding voor het CB assortiment succesvol is verwerkt. Tijdens de verwerking van de bestanden moet het ISBN kunnen worden herkend.
Voorgeschreven bestandsnaam bestanden indienen zonder ONIX bericht | |
---|---|
Afbeelding | Bestandsnaam |
Cover | <ISBN>_covr.jpg |
Backcover | <ISBN>_bcovr.jpg |
E-book bestand | Bestandsnaam |
EPUB | <ISBN>_eboek.epub |
<ISBN>_eboek.pdf | |
Downloadable luisterboek | <ISBN>_eboek.mp3 |
Verwerking van het ONIX bericht en de content
De content en het ONIX bericht met de metadata worden opgehaald van de FTP server en gescheiden verwerkt, maar in dezelfde queue geplaatst qua prioriteit.
Zodra het *_onx.zip bestand geplaatst is op de FTP server wordt er een ontvangstbevestiging teruggeplaatst in de out-map van het ftp account.
<?xml version="1.0" encoding="UTF-8" ?> <ONTBEV xmlns="http://www.cbonline.nl/xsd"> <bericht> <cb_bericht_nr>0</cb_bericht_nr> <afzender_bericht_id>0</afzender_bericht_id> <type>ONIX30</type> <file>aanmeldingebook_onx.zip</file> <ftp_dir>6003401\in</ftp_dir> <relatie_id>6003401</relatie_id> <ontvangen>20190711 0901</ontvangen> </bericht> <melding> <line> Bericht aanmeldingebook_onx.zip is correct ontvangen en zal binnen enige tijd verder verwerkt worden </line> </melding> </ONTBEV>
Vervolgens wordt het *_onx.zip bestand uitgepakt en vindt er direct een syntactische controle plaats. Het resultaat van deze controle wordt teruggekoppeld in de vorm van een .err of een .ok bestand wat in de out-map van het ftp account van de uitgever wordt geplaatst.
Door middel van dit .ok bericht is het verband te leggen tussen de berichtidentificatie die het systeem van de uitgever heeft toegekend aan het bericht en de berichtidentificatie die het systeem van CB heeft toegekend aan het bericht.
Na de syntactische controle zullen de afzonderlijke Product records individueel verwerkt worden in de CB processen. Iedere 10 minuten wordt door het verwerkingssysteem de status van verwerking van het Product record gecheckt en waar nodig bijgewerkt. De status wordt via een O30AMLDNG (xml) bericht teruggekoppeld, wordt teruggeplaatst in de out map van het FTP account van de klant. In dit .xml bericht wordt de koppeling met het originele ONIX 3.0 bericht gelegd door de interne berichtidentificatie van CB.
XSD validatie
ONIX berichten moeten qua structuur voldoen aan de algemene standaard voor XML berichten, dat wil zeggen, de berichten moeten valide XML bevatten. Bijvoorbeeld, de ‘ampersand’ en het ‘kleiner-dan’ teken hebben een specifieke betekenis binnen XML. Wanneer deze in een tekst worden gebruikt, zoals bijvoorbeeld in de titel van een boek of bij een boekbeschrijving, leidt dit tot niet valide XML.
Een ONIX bericht is opgebouwd uit voorgeschreven dataelementen in een voorgeschreven volgorde. Veel van deze dataelementen worden gevuld met waardes uit voorgeschreven codelijsten. Codelijsten kunnen worden gezien als eenduidige vocabulaires waardoor wordt bewaakt dat er bij het doorgeven van artikelgegevens in het gehele kanaal geen interpretatieverschillen en misverstanden ontstaan.
Om te garanderen dat een ONIX berichten aan de voorgeschreven opbouw van de dataelementen en inhoud voldoet zijn er schema’s ontwikkeld waarmee de validiteit van het ONIX bericht gecontroleerd kan worden. Deze schema’s zijn gratis te downloaden vanaf de website van EDItEUR, www.editeur.org. Door deze schema’s te plaatsen in een directory waar ook het te valideren bericht wordt neergezet kan met behulp van een XML editor de validatie worden uitgevoerd. Vanaf ONIX 3.0 zijn er 3 verschillende schema’s in omloop waarmee het bericht gevalideerd kan worden, RNG, DTD en XSD schema. RNG en XSD valideren op basis van de combinatie van structuur van het bericht en codelijsten en hebben daarom de voorkeur.
Codelijsten
CB valideert de binnenkomende ONIX 3.0 berichten op basis van het XSD schema. Dat wil zeggen dat de volledige set met codes die voorkomen in de laatste issue van de codelijsten die CB heeft geimplementeerd "technisch" worden toegelaten. Dat wil niet zeggen dat CB ook al die codes actief gebruikt in de CB-systemen. De partij die het ONIX 3.0 artikelbericht genereert voor het melden van artikelgegevens bij CB wordt verzocht om zelf ook een validatie uit te voeren.
Reference names/long tags of short tags
Er zijn 2 systematieken om de naam van de diverse elementen in een ONIX 3.0 bericht aan te geven die equivalent aan elkaar zijn maar niet door elkaar zijn te gebruiken. Voor elk van deze 2 systematieken bestaat een specifiek validatieschema. Iedere partij die gegevens aanlevert in ONIX formaat moet een van deze twee systematieken kiezen en doorvoeren in het volledige bericht. De voorkeur van CB gaat uit naar ‘reference names’ bij deze systematieken wordt in tekst aangegeven wat de inhoud van de tag is. Het is echter ook mogelijk om gebruik te maken van ‘short tags’, hierin wordt d.m.v. een voorgeschreven codering aangegeven wat de inhoud van de tag is. CB zet ONIX 3.0 berichten met 'short tags' direct na binnenkomst om in 'reference names'.
Bij EDItEUR is desgewenst een script verkrijgbaar om long tag berichten te converteren naar short tag berichten vice versa.
Validatie schema's
Voor informatie over het DTD schema zie: XML Standard: W3C Recommendation Extensible Markup Language (XML) 1.0 (Fourth Edition) – see http://www.w3.org/TR/xml/
Voor informatie over de XML Schema Definition (XSD) format zie W3C Recommendation XML Schema Part 1: Structures (Second Edition) – see http://www.w3.org/TR/xmlschema-1/
Het RELAX NG (RNG) format is gedefinieerd in een ISO standard: ISO/IEC 19757-2:2008, published by ISO,Geneva
Nieuwe issues van codelijsten en XSD validatie
4 x per jaar publiceert EDItEUR een nieuwe issue van de codelijsten en ook een nieuwe issue van de XSD validatie waarin de nieuws codelijsten zijn verwerkt.
CB gaat hier als volgt mee om:
Bij nieuwe codelijst
- Binnen 2 weken kijkt CB naar de impact
- Vervolgens gaan we binnen 3 tot 6 maanden over
- Aankondiging 2 maanden van te voren
- Wij ondersteunen altijd 2 XSD versies voor inkomend bericht
- Voor het uitgaande bericht kiezen we de meest recente
Wie mag wat indienen?
In het ONIX bericht wordt op twee plaatsen informatie meegeleverd die in de verwerking wordt gebruikt om te controleren dat de indiener van het bericht mag optreden namens de eigenaar van het ISBN. In het Message Header record zit de relatie die het bericht indient. In het Product record zit de relatie die de eigenaar van het artikel is of wordt.
Prefixhouder en commerciële eigenaar van het artikel
We kennen twee relaties tussen een uitgever en een artikel, de twee relaties hoeven niet hetzelfde te zijn:
- Aan een artikel is altijd een prefixhouder gekoppeld. De prefixhouder is eigenaar van een prefixrange waarbinnen ISBN’s worden uitgegeven. Deze prefixhouder wordt geregistreerd door Team ISBN.
- Als een artikel tot het CB assortiment behoort, is er tevens een artikel eigenaar. De artikeleigenaar heeft het artikel in eigendom en is degene voor wie CB dienstverlening verricht.
In principe is het zo dat alleen de prefixhouder een ISBN registratie mag aanmelden. De prefixhouder moet bij CB aangeven wie eigenaar wordt van het artikel. In de praktijk blijkt dat met name binnen concerns artikelen worden aangemeld door uitgevers die niet zelf de prefixhouder van het ISBN zijn.
Voorbeeld: Uitgeverij A en B vallen beide binnen concern Z. Een artikel valt binnen de prefixrange van uitgeverij A, maar wordt door uitgeverij B als artikel in het assortiment opgenomen en verkocht aan de boekhandel. Om het artikel automatisch te kunnen verwerken moet vastgelegd worden wat de relatie is tussen uitgever A en uitgever B.
Bij de verwerking van de ISBN registratie en de aanmelding voor het CB assortiment is voor de volgende oplossing gekozen:
- Uit het ISBN is de prefix af te leiden en daarmee de prefixhouder.
- Een ISBN registratie mag alleen door de prefixhouder worden uitgevoerd, of als de indiener van het bericht met de prefixhouder van het artikel een commissionairrelatie heeft.
- Een uitgever mag een titel bij CB aanmelden indien hij prefixhouder is, of als hij met de prefixhouder van het artikel een commissionairrelatie heeft.
- Een uitgever mag artikelgegevens wijzigen indien hij eigenaar is van het artikel, of met de eigenaar van het artikel een commissionairrelatie heeft.
- Bij het indienen van het bericht wordt per artikelrecord gecontroleerd of de registratie en/of aanmelding of de wijziging door de betreffende indiener mag worden uitgevoerd. Indien dit niet het geval is, wordt het productrecord niet verwerkt.
De controles zijn:
- Mag de indiener van het bericht ISBN’s aanmelden voor deze prefixhouder?
- Mag de indiener van het bericht titels aanmelden voor deze eigenaar voor het assortiment van CB?
- Mag de eigenaar die bij het product record is aangegeven titels aanmelden voor het assortiment van het CB van de prefixhouder van het ISBN?
Een titel enkel aanmelden voor ISBN registratie
Om een titel enkel aan te melden voor ISBN registratie en niet op te laten nemen in het CB assortiment dienen de blokken DescriptiveDetail, PublishingDetail en het blok ProductSupply te worden opgenomen in het ONIX ProductRecord. In het blok ProductSupply dient element SupplierName een andere waarde dan CB te bevatten, bijvoorbeeld <SupplierName>@@</SupplierName>.
Samenhang Levenscyclus en verschijningsdatum - Statusovergangen
Uitgevers kunnen via ONIX 3.0 artikelmutaties doorgeven op o.a. de prijs en het stadium levenscyclus (de beschikbaarheidsstatus) van een titel. Als een uitgever een titel voor het eerst aanmeldt voor opname in het CB assortiment wordt deze altijd opgenomen met stadium levenscyclus Aangekondigd en stadium dienstverlening In voorbereiding, ongeacht de meegegeven ProductAvailability.
Daarbij controleert CB in de verwerking op een aantal zaken:
De waarde voor ProductAvailability moet identiek zijn aan het actuele stadium levenscyclus van de titel, of moet een toegestane statusovergang van het actuele stadium levenscyclus aangeven
Bij aangekondigde titels en herdrukken moet de SupplyDate in de toekomst liggen
Bij een prijswijziging moet de ingangsdatum van de prijs in de toekomst liggen
Als er geen prijswijziging wordt doorgegeven moet de ingangsdatum van de prijs overeenkomen met de ingangsdatum van de prijs die in het assortimentssysteem van CB zit.
ONIX kent geen element/tag voor de ingangsdatum van een statusovergang in de toekomst. CB zal een statusovergang daarom standaard laten ingang op 1 dag na de systeemdatum.
De PublicationDate en de SupplyDate moeten bij een aangekondigde titel in de toekomst liggen. Bij een herdruk moet de SupplyDate in de toekomst liggen.
Doorgeven van akkoord voor vrijgave
Voor het vrijgeven (= beschikbaar stellen voor uitlevering) van zowel fysieke boeken als e-books is toestemming nodig van de uitgever. Deze toestemming heet vrijgave-akkoord. Dit vrijgave-akkoord kan direct worden meegegeven bij de commerciële aanmelding of kan ook achteraf door de uitgever worden gegeven.
Het doorgeven van een vrijgave-akkoord kan plaatsvinden d.m.v. een mutatierecord in het ONIX bericht. De werkwijze daarvoor is als volgt:
Nog geen vrijgave-akkoord | titel aanmelding voor het CB assortiment en eventuele assortimentsmutaties op deze titel doorgeven met een PriceStatus 01 in de SupplyDetail composite |
Vrijgave-akkoord aanwezig | assortimentsmutatie op de titels doorgeven met PriceStatus 02 in SupplyDetail composite |
Vrijgeven op een specifieke datum vanwege embargo en pre-sales
Het is mogelijk om ook via ONIX 3.0 aan te geven dat een fysiek boek of e-book pas mag worden uitgeleverd vanaf een door de uitgever bepaalde, specifieke datum. Dit gebeurt door het aangeven van een “MarketDate” in block 6 Product Supply. (P.25)
Overzicht met de samenhang tussen PriceStatus, SupplyDate, MarketPublishingDetail en CB online Vrijgeven artikel
Fysiek artikel | In CB Online Assortiment tabblad Planning en voorraad | ProductAvailability | PriceStatus 01 = Default | Verwachte verschijningsdatum Datum = groter dan 'vandaag' |
---|---|---|---|---|
Aangekondigde titel - Geen vrijgave |
| 10,12 | 01, 00 of niet aanwezig | Datum uit:
|
Aangekondigde titel - Vrijgeven op specifieke datum Géén automatisch akkoord voor vrijgave |
| 10,12 | 01, 00 of niet aanwezig | Datum uit:
Voor activeren van 'Uitleveren op specifieke datum' dient tevens MarketPublishingDetail met:
groter of gelijk aan 'vandaag' te zijn |
Aangekondigde titel - Vrijgeven op specifieke datum Automatisch akkoord voor vrijgave zodra de de specifiek geplande datum aanbreekt |
| 10,12 | 02 | Datum uit:
Voor activeren van 'Uitleveren op specifieke datum' dient tevens MarketPublishingDetail met:
groter of gelijk aan 'vandaag' te zijn |
Aangekondigde titel - Direct vrijgeven |
| 10,12 | 02 | Datum uit:
|
E-book | In CB Online Assortiment tabblad Commercieel | ProductAvailability | SupplierName | PriceStatus 01 = Default | Verwachte verschijningsdatum | |
Aangekondigde titel - Geen vrijgave | Het boek mag niet verschijnen | 10 | CB | 01, 00 of niet aanwezig | Datum uit:
| |
Distributieplatform, IBS, KOBO, AZON etc. | 01, 00 of niet aanwezig | Datum uit:
| ||||
Aangekondigde titel - Vrijgeven op specifieke datum | Het boek mag verschijnen vanaf een specifieke datum | 10 | CB | 01, 00 of niet aanwezig | Datum uit MarketPublishingDetail:
| |
Distributieplatform, IBS, KOBO, AZON etc. | 01, 00 of niet aanwezig | Datum uit MarketPublishingDetail:
| ||||
CB Online tabblad Beschikbaarheid | Kolom Presales | Waarbij geldt dat: | ||||
Nee | Toekomstige datum = Géén presales | |||||
Ja | Datum 'vandaag' of datum in verleden = Presales mogelijk. ('Vandaag' is datum van inzenden ONIX30 bericht) | |||||
Aangekondigde titel - Direct vrijgeven | Het boek mag direct verschijnen | 10 | CB | 02 | Datum uit:
| |
Distributieplatform, IBS, KOBO, AZON etc. | 02 | Datum uit:
|
Audioboek | In CB Online Assortiment tabblad Commercieel | ProductAvailability | SupplierName | PriceStatus 01 = Default | Verwachte verschijningsdatum | |
Aangekondigde titel - Geen vrijgave | Het boek mag niet verschijnen | 10 | CB | 01, 00 of niet aanwezig | Datum uit:
| |
Aangekondigde titel - Vrijgeven op specifieke datum | Het boek mag verschijnen vanaf een specifieke datum | 10 | CB | 01, 00 of niet aanwezig | Datum uit MarketPublishingDetail:
| |
Aangekondigde titel - Direct vrijgeven | Het boek mag direct verschijnen | 10 | CB | 02 | Datum uit:
|