Order simulation for test purpose

In order to test the web service independently as much as possible, a test order based on a few characteristics, that the customer provides, must be processed fully automatically. The functionality described here is available on CB's test environment, but not on the production environment.

Operation of order simulation web service MediaOrderB2C

The order simulation functionality is built into the order handling and processing. 

Management

An order is included in the order simulation on the basis of a test characteristic in the order. The attribute identifier is:

The customer can specify this attribute in one of the two order reference fields:

• customer order reference 
• owner command reference

The customer can choose which field is used for the characteristic. The other field remains available for the customer's reference. A customer who wants to use both order reference fields in production for his own references must, in order to apply the order simulation, choose which of the two fields is “sacrificed” for the characteristic.

Aansturing

Een opdracht wordt meegenomen in de ordersimulatie aan de hand van een test-kenmerk in de opdracht. De kenmerk identificatie is:

test-kenmerk

$CB*TST

De klant kan dit kenmerk meegeven in een van de twee opdracht-referentie velden:

• afnemer-opdracht-referentie
• eigenaar-opdracht-referentie

Beide velden zijn beschikbaar in alle kanalen. De klant kan zelf kiezen welk veld gebruikt wordt voor het kenmerk. Het andere veld blijft beschikbaar voor de referentie van de klant. Een klant die in productie beide opdracht referentie velden wil gebruiken voor eigen referenties moet, om de ordersimulatie toe te passen, kiezen welk van de twee velden “opgeofferd” wordt voor het kenmerk.

Het kenmerk is 7 posities lang. De maximale lengte van de opdracht referentie velden die door alle kanalen ondersteund wordt is 10 posities. De resterende 3 posities zijn gereserveerd voor aanvullende opdracht instructies.

Opdracht instructies

Standaard wordt er voor elke opdracht één levereenheid aangemaakt, onafhankelijk van het aantal opdrachtregels, bestelde exemplaren en afmetingen van de artikelen. We simuleren dat alles in één levereenheid past waarmee de klant een duidelijke verwachting heeft van het resultaat van de opdracht.

In de praktijk past niet alles in een levereenheid en daarom kan de klant in de opdracht aangeven hoeveel levereenheden we moeten aanmaken. 

test-kenmerk aanvulling t.b.v. meedere levereenheden

Dit is optioneel en wordt meegegeven achter het test-kenmerk met:

Cnn

Waarbij nn staat voor het aantal levereenheden (2 t/m 99). Bijvoorbeeld:

• $CB*TSTC3                         => Test kenmerk + verzoek voor 3 levereenheden
• $CB*TSTC05                       => Test kenmerk + verzoek voor 5 levereenheden
• $CB*TSTC15                       => Test kenmerk + verzoek voor 15 levereenheden

Het maximaal aantal aan te maken levereenheden is gelijk aan het aantal bestelde exemplaren (dus 1 exemplaar per levereenheid). Als er meer levereenheden gevraagd worden dan er bestelde exemplaren zijn in een opdracht, dan wordt er per besteld exemplaar een levereenheid aangemaakt. Er wordt geen foutmelding of warning gegeven.

Opdrachtregel instructies

Standaard wordt voor elke regel het aantal bestelde exemplaren ook als geleverd in de levereenheid opgenomen. In de praktijk zijn er verschillende scenario’s mogelijk waardoor er een afwijkend aantal exemplaren geleverd wordt. De ordersimulatie ondersteunt één scenario, namelijk manco. De klant kan bij de opdrachtregel aangeven hoeveel exemplaren er manco gemeld worden. 

Scenario 'Manco'

Dit is optioneel en wordt meegegeven met het manco-kenmerk:

$MANCO;n

Waarbij n staat voor het aantal levereenheden (1 t/m 9). Bijvoorbeeld:

• $MANCO:1                           => Verzoek voor 1 exemplaar manco bij deze orderregel
• $MANCO:5                           => Verzoek voor 5 exemplaren manco bij deze orderregel

Het maximaal aantal manco is het aantal bestelde exemplaren. Als er meer manco gevraagd wordt dan er bestelde exemplaren zijn in een opdrachtregel, dan worden er 0 exemplaren geleverd gemeld. Er wordt geen foutmelding of warning gegeven. 

Er wordt geen nieuwe opdrachtregel voor het manco aantal gemaakt. De beoogde situatie is minder leveren dan gevraagd. Naleveren wordt niet ondersteund in ordersimulatie.

De klant kan dit kenmerk meegeven in een van de twee opdrachtregel-referentie velden:

• afnemer-regel-referentie
• eigenaar-regel-referentie

Beide velden zijn beschikbaar in alle kanalen. De klant kan zelf kiezen welk veld gebruikt wordt voor het kenmerk. Het andere veld blijft beschikbaar voor de referentie van de klant. Een klant die in productie beide regel referentie velden wil gebruiken voor eigen referenties moet, om manco toe te passen, kiezen welk van de twee velden “opgeofferd” wordt voor het kenmerk.

Proces

Een opdracht met het kenmerk wordt altijd aan verwerkingsplaats HE (Handmagazijn Eentjesverwerking, bordes) toegekend. Deze verwerkingsplaats zit in Astro en wordt niet of nauwelijks gebruikt. Er is bewust gekozen voor een Astro verwerkingsplaats omdat het berichtenverkeer met Astro eenvoudig gesimuleerd kan worden.

Om te voorkomen dat de order daadwerkelijk naar Astro gaat wordt het OrderSync bericht bij aanmaken meteen op status Gereed gezet.

Vervolgens wordt het gewenste aantal levereenheden gesimuleerd door per levereenheid een set van PalletShow berichten aan te maken met status 50, 70 en 75. De verwerking van een PalletShow kan leiden tot een PalletSync bericht voor Astro, in die gevallen wordt de PalletSync direct op status Gereed gezet.

Tenslotte wordt het sluiten van de rit in Astro gesimuleerd door een OrderDeliveryReport aan te maken.

Het verwerken van de opdracht wordt volledig doorlopen, met uitzondering van de acties in Astro. Indien van toepassing worden ook de documenten aangemaakt (maar uiteraard niet geprint in Astro).

Artikel voorraad

De ordersimulatie kent geen technische beperkingen in artikelen of voorraad. Afgesproken is om een set van artikelen te “reserveren” voor de ordersimulatie en te zorgen dat er voldoende voorraad beschikbaar is voor deze artikelen. Het monitoren hiervan is handmatig en moet met enige regelmaat uitgevoerd worden.

Resultaten voor klant

Het informeren van de klant over de voortgang van de opdracht is afhankelijk van de manier waarop de opdracht ingediend is.

Webservices

Bij gebruik van het kanaal webservices wordt de klant vrijwel direct na het wijzigen van een status in de order geïnformeerd. Het onderstaande diagram geeft aan welke stadiums er gedefinieerd zijn en welke webservice-operaties gebruikt worden om informatie aan de klant te melden danwel beschikbaar te maken.

Beschrijving:

• Een eindklant (customer) plaatst een of meerdere artikelen in de winkelwagen van een webwinkel
• De webshop dient de opdracht in bij CB
• CB controleert de opdracht en indien geaccepteerd, dan stuurt CB een order notificatie met status event “In Progress”
• CB reserveert voorraad en geeft de order(regel) vrij voor logistiek. De orderregel kan vanaf dat moment niet meer geannuleerd worden. CB stuurt een order notificatie met status event “ProductionReady”
• De webwinkel kan de status van de order ophalen om te zien welke orderregels vrij gegeven zijn
• CB voert de ordersimulatie uit en stuurt per levereenheid een shipment notificatie met status event “Processed”
• De webwinkel kan de details van elke levereenheid ophalen en daarmee de eindklant informeren.

Digicom

Bij gebruik van het kanaal digicom wordt er een UITOPD bericht voor de klant klaargezet en indien niet alles geleverd is ook een NUITOP bericht. Het versturen van de berichten vindt plaats op een gescheduled tijdstip.

Saleskit

Bij gebruik van het kanaal saleskit wordt de klant geïnformeerd met de SHP-status (intern: ORDSTATUS bericht) en SHP-confirm (intern: LEVRESULT bericht) bestanden. Het moment van sturen alsmede het wel of niet sturen van deze berichten is afhankelijk van de configuratie van de klant.