Vzpomínám si, jak všichni podnikatelé začínali pracovat s Whitelistem. A jak už to tak bývá, ze začátku vše probíhalo ve velkém chaosu. Někdy si říkám, jestli je vůbec nutné, aby každá změna musela takto začínat. A přitom, ve skutečnosti změny jsou dobré. Alespoň já mám rád, když se stále něco děje. Vraťme se ale zpátky k Whitelistu. Všichni byli nervózní a měli obavy, jak bude fungovat. Nakonec se ale ukázalo, že nic není tak horké, jak se uvaří. Po pravdě, Bond tuto frázi nikdy nevyslovil, ale jsem si jistý, že jí někde hluboko v sobě měl. Když jsem se potkal s Przemkem na kávě, pověděl mi trochu více o Whitelistu:
Jak to vidí expert:
Od roku 2019 je v Polsku povinnost ověřovat obchodní partnery takzvaným Whitelistem. Jedná se o vládní seznam (vyhledávač) všech společností, který udává jejich status plátce DPH.
Na trhu jsou řešení, která umožňují hromadné dotazování databáze Whitelist pomocí API, ovšem jedná se o konkrétní řešení „šitá na míru“ danému zákazníkovi a systému ERP. Tato řešení také mají určitá omezení vyplývající přímo z ustanovení zákona, která se týkají maximálního počtu denních dotazů, které lze provádět, a také maximálního množství zpracovávaných dat (maximálně 300 záznamů).
V XELTO DIGITAL jsme vyvinuli vlastní způsob ověřování Whitelistu na základě automatizace vyhledávání na webu bez použití API.
Uživatel poskytne seznam daňových identifikačních čísel a/nebo čísel bankovních účtů obchodních partnerů. Poté robot každé číslo na stránce vyhledávače plátců DPH jedno po druhém zkontroluje a shromáždí potřebné informace, jako například: stav poplatníka, ověření, zda je číslo (čísla) účtu v seznamu ověřených účtů, datum vyhledávání a jedinečné ID. Dále pak robot tato data uloží do výsledného souboru, který lze kamkoliv uložit, anebo zákazníkovi zaslat e -mailem.
Na rozdíl od ostatních, již existujících řešení, je výhodou našeho řešení pro zákazníka jeho značná volnost v možnostech nastavení, která mu umožňuje přizpůsobit jej svým konkrétním potřebám.
Další velkou výhodou je obcházení limitů pro dotazy API, protože v našem řešení simulujeme přímo lidskou činnost, tedy otevírání webu a vyhledávání plátců „ručně“.
Pokud je proces automatizován pomocí uživatelského rozhraní, je pomalejší než odesílání dotazů prostřednictvím rozhraní API. I přesto je ale stále mnohokrát rychlejší, než by to udělal člověk, díky čemuž se můžete vyhnout limitu v počtu vyhledávání.
Technicky vzato, vývoj procesu vyžaduje, aby byla věnována pozornost volbám nastavení vyhledávacích tlačítek – po prvním hledání se tlačítko přesune na jiné místo na obrazovce, a přestože vypadá úplně stejně, jeho volba nastavení se v dalších dotazech liší. Pokud vstupní soubor obsahuje čísla DIČ i čísla bankovních účtů, v kódu robota by měl být seznam oddělen.
Robot nejprve zkontroluje bankovní účty, a teprve poté až čísla DIČ, čímž se vyhne zbytečnému přepínání mezi obrazovkami pro vyhledávání.
Autor: Przemysław Wal – RPA Developer
