Následující text popisuje možnosti datového propojení Alzy s autorizovanými servisy.

Datové propojení je realizováno pomocí veřejně přístupného REST API, které poskytuje metody pro zobrazení a práci s daty servisu. Jako formát výměny dat byl zvolen standardní fromát JSON. Servis dostane k dispozici autorizační token, pomocí kterého může API bezpečně dotazovat. Mezi daty služby a daty v produkčním systému Alzy dochází k přísně kontrolované výměně validních stavů. Proto po importu dat do interního systému nemusí vždy dojít k synchronizaci s informačním systémem (v případě vložení porušených nebo nesmyslných kombinací dat). Všechny anomálie na vstupu a při zpracování dat logujeme a spolupracujeme se servisy, aby výměna probíhala bez problémů.

• Je vyžadován důvěryhodný HTTPS ověřovací certifikát.

• Je vyžadován TLS protokol verze 1.2 nebo vyšší.

• Všechny žádosti-requesty musí používat Content-Type: application/json hlavičku spolu s UTF-8 znakovou sadou (RFC 7231, section 3.1.1.5: Content-Type)

• Všechny žádosti-requesty musí mít vyplněnou hlavičku User-Agent (RFC 7231, section 5.5.3: User-Agent)

Tst prostředí

• Veřejná adresa služby (REST API): https://service-center-connector-test.alza.cz/
• Swagger dokumentace: https://service-center-connector-test.alza.cz/swagger

Prd prostředí

• Veřejná adresa služby (REST API): https://service-center-connector.alza.cz/

Na produkčním prostředí není Swagger dokumentace dostupná. Popisy request/response polí a datových struktur jsou k dispozici pouze na tst prostředí (viz výše).

Základní entitou, nad kterou probíhá komunikace, je servisní požadavek, v dokumentaci service task. Servisní požadavek je určen v systémech Alzy jednoznačným identifikátorem ve formátu SETxyz, kde xyz je celé číslo a slouží ke zpracování servisního případu ve směru Alza ↔ autorizovaný servis. Na druhou stranu záznam reklamace slouží pouze ke komunikaci se zákazníkem a reflektuje zákonnou povinnost. Servisní požadavek je také obvykle obsahem zásilky, kterou se dostává zboží z poboček do reklamační centrály nebo do servisu. V záznamu evidujeme množství údajů, část z nich je společná a datově shodná s údaji v autorizovaných servisních centrech. Pro pohodlný přístup k záznamu lze servisní požadavek dotazovat pomocí externího identifikátoru externalServiceTaskKey, který je možné k záznamu uložit.

Servisní soupiska, v dokumentaci vendor sheet, slouží k seskupení servisních požadavků do jedné zásilky a odeslání do servisu. V cílovém servisu obvykle slouží ke kontrole obsahu zásilky.

Řešení servisního požadavku OPRAVOU

1. Vznik servisního požadavku na pobočce a odeslání do reklamační centrály Alzy
2. Určení autorizovaného servisu dle typu zboží a odeslání do servisu současně se servisní soupiskou
3. Servis v případě dokončení servisního případu provolá metodu pro úprava dat konkrétního servisního případu a vyplní identifikátor servisního případu + způsob vyřízení solution.REPAIRED a servisní report serviceReport.
4. Ve chvíli odeslání servis provolá stejnou metodu a uvede hodnotu pro číslo zásilky returnPackageNumber, pod kterou k nám servisní požadavek dorazí.
5. Po doručení zásilky do Alzy přijímací technik fyzicky kontroluje zboží
6. V systému se mu automaticky dotahují data předaná pomocí API rozhraní
7. Dotažená data technik pouze zkontroluje a na jejich základě vyřizuje reklamaci
8. Tímto je servisní případ ukončen
   • Pokud dojde ke změně SN/IMEI zapíše do atributu replacedSerialNumber

Řešení servisního požadavku VÝMĚNOU

• Postup je podobný řešení opravou.

• Rozdíl je ve způsobu vyřízení solution.REPLACEMENT a odeslaném novém SN nebo IMEI v atributu replacedSerialNumber

• Pokud dojde k výměně za odlišný produkt (novější verzi, podobné zařízení ve stejné nebo vyšší cenové kategorii) je potřeba navíc vyplnit strukturu replacedProduct. Povinná pole pak jsou supplierCode, EAN, Name.

Řešení servisního požadavku ZAMÍTNUTÍM

• Postup je podobný řešení opravou

• Autorizovaný servis posílá způsob vyřízení jako solution.REJECTED a navíc detailní důvod zamítnutí rejectedDetail

Řešení servisního požadavku PROTOKOLEM O NEOPRAVITELNOSTI

• Autorizovaný servis posílá způsob vyřízení jako solution.UNRECOVERABLE_PROTOCOL

• Pokud servis není zároveň dodavatelem odesílá flag protokol neopravitelnosti unrecoverableProtocolDetail, kterým říká, zda-li odesílá včetně protokolu i zboží. Pokud ano, je potřeba při expedici zároveň vypnit returnPackageNumber jako při řešení opravou.

Řešení servisního požadavku DOBROPISEM

• Autorizovaný servis posílá způsob vyřízení jako solution.CREDIT_NOTE

• Dokladová výměna dobropisů proběhne v EDI → dobropis od dodavatele Reklamace

Odeslání cenového návrhu

Je obvyklé posílat CN automaticky při vyřízení zamítnutím

• Pro odeslání CN se používá sekce priceProposal

• V případě CN čeká servis dohodnutou dobu než zboží odesílá zpátky na vyjádření reklamační centrály

  • V budoucnu bude automatizováno a součástí rozhraní

• Synchronizace objednávky CN proběhne v EDI → objednávka na Servisní opravy

• Synchronizace daňových dokladů proběhne v EDI → přijatá faktura od dodavatele na Servisní opravy