Dropshipping: technické možnosti napojení dodavatele

01Nejdřív rozdělte odpovědnost za celý obchod

Dropshipping propojuje objednávku vašeho zákazníka s expedicí dodavatele. Z technického pohledu jde o několik toků: katalog, dostupnost, ceny, předání objednávky a následné stavy. Každý potřebuje vlastní pravidla. Úspěšný import produktů ještě neznamená, že dodavatel přijme objednávku nebo dokáže potvrdit zásilku.

Před vývojem popište, kdo prodává zákazníkovi, kdo objednávku potvrzuje a kdo řeší problém po nákupu. Pokud vystupujete jako prodávající, proces musí odpovídat vašim povinnostem. Přehled EU pro prodej na dálku zahrnuje informace o obchodníkovi, ceně, dodání, vrácení a řešení stížností. Automatizace je musí podpořit ve skutečném provozu.

Dohodněte s dodavatelem dostupnost podkladů, možnost použít fotografie, změny cen a čas potvrzení. Vyřešte také storno, částečné plnění, vratku a zákaznickou komunikaci. Bez těchto podmínek bude integrace jen přeposílat nejasnost mezi systémy. Technický tým nemůže ze samotného XML souboru odvodit obchodní odpovědnost.

Pro modelový obchod si nakreslete cestu jedné objednávky: přijetí platby, předání dodavateli, potvrzení, odeslání a případná vratka. Jde o návrhový scénář, nikoli o univerzální pořadí. Dobírka a více dodavatelů mohou vyžadovat jiné kroky. K nezvyklým situacím napište rozhodnutí člověka a informaci, kterou potřebuje.

02Feed, API a webhook řeší různé části napojení

Produktový feed bývá soubor určený pro dávkový přenos katalogu. API nabízí konkrétní operace mezi systémy. Webhook oznamuje událost, například změnu objednávky. Tyto cesty lze kombinovat. Název modernější technologie sám neprokazuje aktuálnější sklad ani úplnější obchodní proces.

Shoptet popisuje webhooks jako oznámení událostí s pravidly potvrzení a opakování. Výchozí zpráva může obsahovat jen metadata a identifikátor, takže detail načítáte samostatně. Příjem notifikace a její následné zpracování jsou proto různé kroky. Konkrétní dostupné události ověřte pro zamýšlené napojení.

Před nákupem konektoru nechte dodavatele ukázat své skutečné API nebo ukázku exportu. Zeptejte se na testovací prostředí a způsob oznamování změn. Pokud zatím vybíráte základ obchodu, pomůže s návaznou otázkou naše porovnání e-shopových platforem. Ani vhodná platforma však sama nedoplní chybějící rozhraní partnera.

03Katalog potřebuje stálé identifikátory a pravidla úprav

Každé nabízené variantě přiřaďte jednoznačné mapování na produkt dodavatele. Název není spolehlivým klíčem: může se změnit nebo být stejný pro několik velikostí. Evidujte dodavatele, jeho identifikátor a vlastní identifikátor. Pokud partner kódy recykluje, potřebujete znát i pravidlo, jak poznat skutečně nový produkt.

Rozdělte data, která smí přepsat dodavatel, od vlastní redakční práce. Dodavatel může spravovat nákupní cenu a sklad, zatímco vy vlastníte popis, kategorii a prodejní argumenty. Automatický import nemá při každém běhu mazat ručně opravené informace. U každého pole určete zdroj pravdy a způsob řešení konfliktu.

Zkontrolujte varianty, jednotky, měnu, daňové významy a formát čísel. Prázdný údaj nemusí znamenat nulu ani pokyn k vymazání. Katalogový import připravte tak, aby chybné produkty odložil k řešení a nepřepsal správná data neúplným souborem. Výstup má ukázat, co se změnilo a proč některé položky neprošly.

Řešte životní cyklus produktu. Dočasně vyprodaná varianta je jiný stav než trvale ukončené zboží. Zmizelý řádek ve feedu nemusí bez dalšího znamenat konec nabídky; může jít o chybný export. Dohodněte potvrzení a ochranné podmínky, než systém hromadně skryje velkou část katalogu.

Na reprezentativním vzorku prověřte také obrazové podklady a zákaznické údaje. Nechte obchod zkontrolovat, zda popis odpovídá dodávané variantě. Funkční přenos textu ještě neprokazuje správnost nabídky. Připravené mapování má umožnit opravit jednotlivou položku a dohledat původ informace bez dalšího ručního pátrání.

04Dostupnost a cena mají konkrétní stáří

Zjistěte, co partner slovem skladem skutečně označuje. Může jít o fyzický počet, dostupné množství po rezervacích nebo obecný příznak. Důležitý je okamžik poslední aktualizace a možnost dalšího prodeje jinými odběrateli. Poslední import není rezervací zboží pro vašeho zákazníka.

Domluvte pracovní toleranci stáří dat a reakci při jejím překročení. Podle sortimentu může dávat smysl omezit prodej, změnit dostupnost nebo vyžádat ruční potvrzení. Nepoužívejte jednu univerzální dobu pro všechny dodavatele. Rozhoduje riziko nesplnitelného příslibu a skutečná rychlost dostupného rozhraní.

U cen stanovte způsob výpočtu, měnu, zaokrouhlení a ochranu před neobvyklou změnou. Nákupní cena není hotová prodejní cena. Započtení dalších nákladů řešte s obchodem podle reálného modelu. Pokud import pošle výrazně jinou částku, systém by měl postupovat podle předem dohodnuté kontroly, nikoli automaticky zahájit akci.

Při současném nákupu posledního kusu připravte scénář odmítnutí partnerem. Uživatelský text musí odpovídat tomu, co je skutečně potvrzeno. Provozní tým potřebuje rychlé upozornění a postup komunikace. Integrace má problém odhalit včas; žádná periodická synchronizace sama nevyloučí všechny souběžné změny.

05Objednávku předávejte bezpečně i při opakování

Objednávce přidělte vlastní stabilní identifikátor a evidujte identifikátor partnera. Rozlišujte připravenou, odesílanou, potvrzenou a odmítnutou operaci. Timeout může znamenat, že odpověď nedorazila, přestože dodavatel objednávku vytvořil. Slepé nové odeslání pak může vést ke druhé expedici.

Navrhněte ochranu před duplicitou a postup zjištění nejasného výsledku. Opakování stejné operace má zachovat stejný účel a identifikaci. Shopify vysvětluje idempotentní požadavky, jejich podpora však závisí na konkrétním API a operaci. Nelze předpokládat, že libovolný dodavatel rozpozná vlastní klíč bez dohody.

Pokud jednoho zákazníka obslouží více partnerů, rozložte objednávku do dílčích plnění. Uchovejte vztah mezi položkou, dodavatelem a zásilkou. Změna jednoho balíku nemá automaticky označit celý obchod za dokončený. Zákazník i podpora potřebují srozumitelnou informaci o tom, co již odešlo a co ještě čeká.

Ruční zásah musí používat stejná pravidla jako automat. Tlačítko znovu odeslat má ukázat předchozí výsledek a případné riziko. Evidujte, kdo rozhodl a proč. Jinak může dobře míněná pomoc podpory obejít deduplikaci a vytvořit problém, který se v samotném technickém logu obtížně vysvětluje.

06Výpadky, storna a vratky patří do běžného provozu

Počítejte s opožděnými a opakovanými událostmi. Shopify v dokumentaci webhooků popisuje opakované doručení při chybě, možné zpoždění i obnovu chybějících dat po výpadku. Pravidla se mezi platformami liší. Na straně integrace potřebujete vlastní evidenci zpracovaných operací a kontrolu rozdílů.

Oznámení ověřte podle podporovaného mechanismu původu a uložte k následnému zpracování. Potvrzení příjmu dávejte až ve stavu, kdy jej lze bezpečně dál zpracovat. Samotný úspěšný HTTP kód neříká, že objednávka prošla celým obchodním tokem. Oddělte proto přijatou zprávu, provedenou práci a její obchodní výsledek.

Storno může dorazit před předáním, po potvrzení i po expedici. Připravte pravidla pro každý relevantní stav. Podobně řešte vrácení části objednávky, změnu zásilky a zamítnutí dodavatelem. Ne každý problém je vhodný k nekonečnému automatickému opakování; chybné mapování produktu potřebuje opravu.

Osobní údaje zákazníka předávejte v potřebném rozsahu a dohodnutou cestou. Proveďte kontrolu oprávnění, ukládání přístupových tajemství a provozních logů. Do běžného upozornění stačí identifikátor a popis problému, ne kompletní adresa zákazníka. S partnerem vyjasněte role a podmínky zpracování podle skutečného vztahu.

07Spusťte omezený pilot s kontrolou rozdílů

Pilot připravte s omezeným katalogem a zvládnutelným provozem. Ověřte kompletní cestu několika druhů objednávek i domluvené výjimky. Zapište očekávané stavy, kontakty a postup obnovy. Počet úspěšných HTTP volání není vhodným kritériem převzetí napojení.

1. Prověřte vzorky dat a domluvte mapování i obchodní pravidla.
2. Ověřte přenos katalogu, cenu, dostupnost a ochranné podmínky.
3. Vyzkoušejte objednávku, opakování, výpadek i následné stavy.
4. Spusťte omezený provoz a porovnávejte e-shop s dodavatelem.

Sledujte stáří skladu, nepotvrzené objednávky, nevyřízené chyby a rozdíly mezi systémy. Ke každému upozornění určete příjemce a akci. Připravte možnost bezpečně zastavit další automatické předání a obnovit tok po opravě. Dokumentaci aktualizujte při změně rozhraní partnera.

Rozšíření na další dodavatele posuzujte podle ověřených provozních nároků. Dva partneři mohou mít jiná pravidla cen, stavů a expedice. Sdílenou technickou vrstvu lze opakovaně využít, obchodní rozdíly ale musí zůstat viditelné. V nabídce požadujte cenu údržby i odpovědnost za změny a dohled.

Převzetí doplňte o kontrolu dokladů a komunikace. Obchod a podpora ověří, že zákazník dostává domluvené informace a že účetní podklady odpovídají skutečnému plnění. Technický test má obsahovat i prázdný export, neznámou variantu a změnu přístupu partnera. U každé situace musí být zřejmé, které údaje systém zachová a koho upozorní.

08Časté otázky k napojení dodavatele