Szállítási értesítés (ASN) a beszállítók számára: miért ez az egyik legnehezebb téma a logisztikában

A szállítási értesítés (ASN, Advance Shipping Notice) egy elektronikus üzenet, amelyet a szállító küld a címzettnek – a kiskereskedelmi hálózatnak vagy a logisztikai szolgáltatónak – még mielőtt az áru fizikailag megérkezne a helyszínre. Pontosan leírja, hogy mi, milyen mennyiségben és hogyan lett csomagolva. Az EDIFACT szabványban DESADV néven szerepel.

Mi is valójában a szállítási értesítés?

A szállítási értesítés pontosan megadja: mi, milyen mennyiségben, hogyan van csomagolva, és melyik logisztikai egységben (raklapon) szállítják az adott árut. Az egységes raklap – egy termék, egy tétel – nem jelent nagyobb problémát. A nehézségek a vegyes, réteges raklapoknál kezdődnek, ahol le kell képezni a csomagolás teljes sorrendjét: mi van az alsó rétegben, mi a középsőben, mi a felsőben.

Ezeknek az adatoknak elvileg közvetlenül a raktárkezelő rendszerből (WMS) kell származniuk – hiszen ez határozza meg, milyen sorrendben kerül az áru a raklapra. A gyakorlatban azonban a WMS-rendszerek általában saját, nem szabványosított módszerekkel rögzítik ezeket az információkat, ezért a cégek gyakran kihagyják ezt a folyamatot, és kézzel állítják össze a szállítási értesítést, a címzett vagy a logisztikai szolgáltató platformján.

Miért nincs egyetlen univerzális formátum?

A legnagyobb kihívás nem maga az értesítés ötlete, hanem az, hogy nincs egyetlen szabvány. A nemzetközi kommunikációban az EDIFACT dominál, ez a leggyakrabban használt szabványcsalád. Az autóipar gyakorlatilag kilép ebből a rendszerből, és saját szabványát, a VDA-t használja, amely a fix szélességű formátumon alapul. Itt a mezők közötti pontos szóközszám számít, nem pedig az elválasztójel vagy a mezőcímke, mint az EDIFACT esetében.

A szolgáltató számára ez konkrétan azt jelenti, hogy az egy adott szolgáltatóra vagy hálózatra épített integráció valószínűleg nem vihető át egy másik kapcsolatra. Egy új partner általában új parserrel, új mezőtérképpel, néha pedig teljesen más fájlformátummal jár.

Miért nem szabványosul a piac magától?

Minden logisztikai szolgáltató ragaszkodik a saját formátumához, és ez aligha véletlen. A szolgáltatók az EDI-kommunikációt saját igényeikre, ügyfeleik kiszolgálására építik ki, nem pedig továbbértékesítésre szánt termékként.

„Ha egy vállalatnak sikerült kidolgoznia a szolgáltatóval egy megfelelő integrációs modellt, az nem jelenti azt, hogy a megoldás közvetlenül átvihető egy másik szervezetre. Minden vállalatnak megvannak a saját üzleti folyamatai, követelményei és adatcsere-módszerei, ezért a bevezetés további testreszabási munkákat igényel.” – Jakub Kłębokowski, logisztikai kommunikációs szakértő, Infinite IT Solutions

Ez egyébként néha szándékos is: a szabványosítás hiánya megnehezíti a szállító számára a logisztikai szolgáltató váltását. Az a beszállító, aki több szolgáltatót is kiszolgál – mert új piacra lép, vagy a disztribúciót egy újabb hálózatra terjeszti ki –, végül számos, 1:1 arányban kiépített integrációval szembesül, ahelyett, hogy egyetlen leképező réteggel kellene beérnie.

Kiket érint leginkább ez a téma

Megfigyeléseink szerint a szállítási értesítés automatizálásának igénye leggyakrabban három típusú vállalatnál merül fel: a logisztikai szolgáltatóval (3PL) együttműködő beszállítók, a Nyugat-Európába exportáló szállítók (ahol az ASN egyszerűen piaci szabvány), valamint a Lengyelországban működő kiskereskedelmi láncok szállítói. Itt éppen a Lidlnél működik a legjobban ez a modell – más láncoknál gyakran „leegyszerűsített” szállítási értesítés van, amely csupán a termékek listájára korlátozódik.

A sajátosságok iparáganként jelentősen eltérnek – másképp néz ki a helyzet az FMCG, a kiskereskedelem, az autóipar, a SHE vagy a barkácsáruházak esetében.

Az e-számla katalizátor, nem pedig a probléma forrása

Ez a jelenség nem kizárólag Lengyelországra jellemző – minden kötelező e-számlázási rendszerre vonatkozik, függetlenül attól, hogy helyileg hogyan nevezik. Nálunk ez a KSeF: egy olyan rendszer, amely ellenőrzi a dokumentum formai helyességét, de nem a tartalmi helyességét.

„A KSeF nem ellenőrzi a fájl tartalmi helyességét. Még egy hibás vagy hiányzó kód a számlán sem akadályozza meg annak elküldését és nyilvántartásba vételét – az adókötelezettség ettől függetlenül keletkezik. A címzettnek kell megoldania, hogyan illessze össze az ilyen számlát a tényleges szállítással.” – Jakub Kłębokowski

Ugyanez a mechanizmus fog működni mindenütt, ahol az e-számlázás kötelezővé válik. A szállítási értesítés ilyenkor a számlától független szállítási visszaigazolásként működik – függetlenül attól, hogy az adott piacon milyen e-számlázási rendszer működik.

Rejtett költség: a munkavállalóval együtt távozó tudás

Sok vállalat meglehetősen egyszerű módon oldja meg az automatikus szállítási értesítés hiányosságait: kézzel, egy tapasztalt személy segítségével, aki egyszerűen tudja, mit igényel az adott üzleti partner.

„Ennek az ügyfélnek a beszállítójának ki kell töltenie egy adott paramétert, de az adott céget kiszolgáló munkatárs pontosan tudja, hogyan kell ezt megtenni. A probléma akkor jelentkezik, amikor ez a személy szabadságra megy, nyugdíjba vonul, vagy állást vált – az új munkatárs gyakran nem kapja meg ezt a tudást, és a hibák visszatérnek.” – Jakub Kłębokowski

Ez a kockázat a partnerek számával és a megjegyezendő kivételek számával együtt növekszik – a gyakorlatban pedig sehol sincs hivatalosan leírva.

Hogyan kezeli ezt az Infinite IT Solutions?

A mi szerepünk tulajdonképpen egy dologra korlátozódik: a leképezésre. Ahelyett, hogy minden új szabványhoz nulláról építenénk fel az integrációt, a szállító megtartja a saját formátumát, mi pedig lefordítjuk azt a másik fél követelményeire.

A gyakorlatban ez kétféle megvalósítási módot jelent: a rendszer-rendszer közötti integrációt, ahol az adatok automatikusan áramlanak a szállító WMS/ERP-rendszeréből, vagy a webes változatot – olyan helyzetekre, amikor a másik fél nem finanszírozza a teljes integrációt, de a szállítónak így is üzenetet kell generálnia.

Gyakran feltett kérdések

Mi az a szállítási értesítés (ASN)? A szállítási értesítés (ASN, Advance Shipping Notice) egy elektronikus üzenet, amelyet a szállító küld el, mielőtt az áru megérkezne a címzetthez, és amely pontosan leírja a szállítmány tartalmát és csomagolását.

Mi az a DESADV? A DESADV (Despatch Advice) az EDIFACT szabvány szerinti szállítási értesítés neve.

Mi a különbség az EDIFACT és a VDA között? Az EDIFACT egy nemzetközi elektronikus kommunikációs szabványcsalád. A VDA az autóiparban használt, önálló szabvány, amely fix szélességű formátumon alapul, ahol az adatmezők közötti szóközök pontos száma számít.

A KSeF előírja-e a szállítási értesítés elküldését? Nem. A KSeF kizárólag a számlázást támogatja, és nem ellenőrzi a dokumentumok tartalmi elemeit. A szállítási értesítés egy különálló logisztikai üzenet, amely független a számlától.

Mivel foglalkozik az Infinite IT Solutions? Az Infinite IT Solutions a beszállító belső formátumát egy adott logisztikai szolgáltató vagy kereskedelmi hálózat követelményeihez igazítja, így nincs szükség minden új üzleti kapcsolat esetén külön integrációt kiépíteni.