In sommige gevallen zou je van een uitgeleverde en/of gefactureerde order een zending bij de vervoerder in het online portaal verwachten en is dit toch niet het geval.
Of er komt niet automatisch een verzendlabel uit de label-printer rollen, terwijl dit normaal gesproken wel het geval is vrij kort na het uitleveren / factureren van de order.
We zullen hier de meest voorkomende fouten beschrijven in mate van hoe vaak ze voorkomen, zodat duidelijk wordt waar de “kink in de kabel” gezocht moet worden en hoe dit op te lossen is:
Track & trace gegevens uitleverhistorie helemaal leeg
In verreweg de meeste gevallen zal de zending(-data), waarvan jij dacht dat hij automatisch “opgepikt” zou worden, toch niet helemaal compleet.
Hierbij kan je denken aan het feit dat de gekozen vervoerder(naam) niet overeenkomt met wat geconfigureerd is, bijvoorbeeld dat daar PostNL staat in plaats van DHL.
Of het zou kunnen zijn dat er, om wat voor reden dan ook, geen collo-regel aanwezig was tijdens het uitleveren van de order. Dit ziet er dan zo uit in de uitleverhistorie:
Op de plek van de pijl zou normaal gesproken collo-data aanwezig moeten zijn, wat als trigger dient voor het aanmelden van de zending bij de vervoerder. Mocht deze missen, wordt deze zending “gewoon” genegeerd.
Zending-data foutief
In verreweg de meeste gevallen zal de zending-data, zoals aanwezig in de uitleverhistorie,
foutief zijn. Bij het desbetreffende uitlevernummer in de uitleverhistorie zal je dan de volgende melding zien staan:
Dit is altijd een generieke / basale melding, namelijk: FOUT BIJ AANMELDEN – Het aanmelden van de zending bij vervoerder ‘naam vervoerder’ is mislukt. Loop de ordergegevens nog eens goed na.
Kijken we bij deze order in de uitleverhistorie wat verder, bijvoorbeeld door naar het tabblad Algemeen te gaan, dan zien we het volgende:
Zoals te lezen is in de omschrijving van de collo-type in King en ook in de documentatie van PostNL zelf wat betreft product code 3085 zou dit een binnenlandse zending (NL -> NL) moeten zijn.
In dit geval zie je dat het verzendadres in China ligt (de landcode is CN). Deze zending voldoet daarom niet aan de eisen van PostNL en zal niet goed aangemeld kunnen worden.
Ook kan het goed voorkomen dat de postcode niet overeenkomt met wat de vervoerder verwacht qua opbouw. Als de postcode van een adres in België bijvoorbeeld opgebouwd is in King door landcode en postcode aan elkaar te plakken met een midden streepje ertussen, bijvoorbeeld BE-9800, zal dit in de meeste gevallen niet geaccepteerd worden door de vervoerder.
De koppeling wordt over het algemeen zo ingesteld dat fouten periodiek (elke 15, 30 minuten et cetera) een nieuwe poging wordt gedaan om de zending aan te melden bij de vervoerder, maar die functionaliteit zal bij dit soort fouten geen soelaas bieden. Ook niet wanneer je later / achteraf de postcode of het land goed noteert bij dat verzendadres.
Dit komt vanwege het feit dat de data in de uitleverhistorie, een kopie is van de gegevens zoals ze op dat moment bekend waren in King. Een wijziging die je naderhand doet, zal dus pas worden toegepast wanneer je opnieuw een order / zending gaat uitleveren.
Foutieve zendingen vanwege tijdelijke verbindingsproblemen (bij jezelf of bij de vervoerder) zullen bij een eventuele tweede poging daarentegen wel goed aangemeld kunnen worden.
API van vervoerder is niet beschikbaar
Het kan voorkomen dat de API van de vervoerder tijdelijk niet beschikbaar is. Elke synchronisatie controleren we op de beschikbaar van deze API en als we een succesvol resultaat terugkrijgen, gaan we door met de verwerking van de nog niet aangemelde zendingen.
Bij een fout zal een item in de uitleverhistorie deze melding weergeven:
Track & trace gegevens uitleverhistorie gevuld, maar geen verzendlabel
Een succesvolle zending zal eruit zien als volgende figuur:
Toch kan het daarna voorkomen dat er alsnog geen verzendlabel geprint is, terwijl het automatische printer wel aanstaat. In dit geval zou je naar de volgende (mogelijke) oorzaken kunnen kijken:
- Staat er een bestandje om te printen klaar in de map waar normaal gesproken de print-bestanden neergezet worden? Met extensie *.zpl of *.pdf?
- Staat de printer aan?
- Heeft de printer een fout gehad of staat hij in storing?
- Bekijk de openstaande afdruktaken via Afdruktaken weergeven,
zie onderstaande figuur:
- Bekijk de openstaande afdruktaken via Afdruktaken weergeven,
API van King is niet beschikbaar
Natuurlijk kan het ook voorkomen dat de King Webservices tijdelijk niet beschikbaar is. Net als dat we de API van de vervoerder elke synchronisatie controleren op beschikbaar, doen we dit ook bij de API van King. Dit is noodzakelijk omdat we deze King Webservices nodig hebben om data terug te schrijven in King en als we dit niet kunnen ligt in feite de hele koppeling lam!
Gelukkig komt dit praktisch niet voor, maar als het gebeurt, zullen een van de onderstaande redenen hoogstwaarschijnlijk de oorzaak zijn:
- Er is onderhoud op de King-server uitgevoerd;
- Internet Information Services is wellicht (tijdelijk) stopgezet;
- De King Webservices maken hier gebruik van.
- Er is een King-update geïnstalleerd;
- De toegangscodes voor de King Webservices zijn gewijzigd in King.
