Integracje

Zwykle decyduje bank. Host-to-host SFTP to najszerzej oferowany kanał dla korporacyjnych plików płatności. EBICS jest częsty w bankach w Niemczech, Francji i krajach sąsiednich. API banków pasują do sald w czasie rzeczywistym i płatności natychmiastowych, gdy bank je oferuje. Wiele firm używa więcej niż jednego, a warstwa integracji ukrywa różnicę przed ERP.

Więcej: Pliki płatności i uzgadnianie między ERP a bankiemOdnośnik do tego pytania

Gdy bank oferuje oba, camt.053 niesie bogatsze, ustrukturyzowane dane tytułu płatności, co czyni automatyczne dopasowanie niezawodniejszym. MT940 jest nadal szeroko używany i dobrze działa w wielu przypadkach. Obsługujemy oba, konwertujemy je na ten sam model wewnętrzny i przenosimy każdy bank z MT940 na camt.053, gdy to Państwu i bankowi pasuje.

Więcej: Pliki płatności i uzgadnianie między ERP a bankiemOdnośnik do tego pytania

Zwykle jako zdarzenia blisko czasu rzeczywistego, bo stany i sprzedaż są wtedy aktualne w ciągu dnia. Niektóre ERP lub licencje czynią częste księgowania kosztownymi, więc warstwa może też grupować zdarzenia w podsumowania per sklep i okres. Wybieramy z Państwem na podstawie tego, które decyzje wymagają aktualnych danych i co ERP obsługuje dobrze.

Więcej: Synchronizacja sprzedaży, stanów i cen POS–ERPOdnośnik do tego pytania

Projekt działa z każdym POS, który eksportuje transakcje przez API, zdarzenia lub pliki, oraz z ERP takimi jak SAP S/4HANA, Oracle NetSuite, Microsoft Dynamics 365 Business Central i Odoo. Na starcie potwierdzamy interfejsy Państwa konkretnego POS i ERP. Wymienienie produktu nie oznacza partnerstwa z jego dostawcą.

Więcej: Synchronizacja sprzedaży, stanów i cen POS–ERPOdnośnik do tego pytania

Agent rozliczeniowy to bank lub licencjonowana instytucja, która przetwarza dla Państwa płatności kartą i wypłaca pieniądze. Bramka to usługa techniczna przed nim, przyjmująca żądania z terminali i kas, tokenizująca karty i kierująca je dalej. Niektórzy dostawcy są jednym i drugim. Projekt działa w obu przypadkach i utrzymuje role rozdzielone.

Więcej: Płatności kartąOdnośnik do tego pytania

Nie. ISO 8583 definiuje strukturę, a każdy agent rozliczeniowy lub sieć publikuje własną specyfikację pól, typów komunikatów i kodów. Dlatego budujemy na podstawie specyfikacji agenta rozliczeniowego i uruchamiamy jego testy certyfikacyjne. API bramki przed agentem rozliczeniowym ukrywa te różnice, co dla detalistów jest często prostsze.

Więcej: Płatności kartąOdnośnik do tego pytania

Agregator daje wiele banków przez jedno API i obsługuje różnice między nimi, przy koszcie za wywołanie lub połączenie. Połączenia bezpośrednie dają większą kontrolę i mogą pasować do niewielkiej liczby ważnych banków. Wiele produktów zaczyna od agregatora i później dodaje połączenia bezpośrednie. Porównujemy opcje względem banków i krajów, których Państwo potrzebują.

Więcej: API bankowości otwartejOdnośnik do tego pytania

Zasięg zależy od przepisów regionu i API banków. Unia Europejska i Zjednoczone Królestwo mają szeroki zasięg w ramach PSD2 i UK Open Banking Standard. W innych miejscach zasięg jest różny, a agregatorzy wypełniają część luk. Sprawdzamy zasięg dla banków używanych przez Państwa klientów, zanim zdecydują się Państwo na projekt.

Więcej: API bankowości otwartejOdnośnik do tego pytania

Nie w większości pracy skarbu korporacyjnego. Kanały host-to-host obsługują wsadowe pliki płatności i pełne wyciągi dla Państwa rachunków. Bankowość otwarta pasuje do produktów dla klientów, sald w czasie rzeczywistym i pojedynczych płatności. Wiele firm używa obu: host-to-host do własnych serii płatności, a bankowości otwartej dla swoich klientów.

Więcej: API bankowości otwartejOdnośnik do tego pytania

Każdą usługę z udokumentowanym API lub interfejsem plikowym. Typowe przykłady to platformy CRM, przewoźnicy i dostawcy logistyczni, marketplace’y, platformy e-fakturowania i podatkowe, kadry i płace, dostawcy KYC i tożsamości oraz partnerzy handlowi wymieniający dokumenty EDI przez AS2. Przed zobowiązaniem się do planu sprawdzamy API, limity i środowisko testowe każdego partnera.

Więcej: Połączenia ERP z zewnętrznymi APIOdnośnik do tego pytania

Gdy do jednego ERP podłączonych jest kilku partnerów, platforma taka jak MuleSoft, Boomi lub Azure Logic Apps albo zestaw usług własnych na kolejce komunikatów utrzymuje mapowanie, ponowienia i monitoring w jednym miejscu. Przy jednym lub dwóch partnerach mogą wystarczyć połączenia bezpośrednie. Przedstawiamy kompromisy, w tym koszty licencji, dla Państwa przypadku.

Więcej: Połączenia ERP z zewnętrznymi APIOdnośnik do tego pytania

Po stronie ERP: SAP ECC, S/4HANA i BTP, Oracle Fusion Cloud ERP i NetSuite, Microsoft Dynamics 365, Odoo i Sage. Po stronie workflow i CRM: ServiceNow, Salesforce i Microsoft Power Platform. Pracujemy też z systemami niestandardowymi i starszymi. Wymienienie produktu nie oznacza partnerstwa z jego dostawcą.

Więcej: Wdrożenie i synchronizacja ERP oraz CRMOdnośnik do tego pytania

Tak. Inwentaryzujemy każdy interfejs w ECC, decydujemy, które zachować, przebudować lub wycofać, i przenosimy każdy do S/4HANA lub BTP wraz z testami. Przepływy przełączamy pojedynczo, aby firma nie zależała od jednego weekendu przełączenia.

Więcej: Wdrożenie i synchronizacja ERP oraz CRMOdnośnik do tego pytania

Nie zawsze. Kilka stabilnych przepływów między dwoma systemami może działać na bezpośrednich wywołaniach API. Gdy kilka systemów wymienia dane albo potrzebne jest mapowanie, kolejki i monitorowanie w jednym miejscu, middleware zwykle się zwraca. Jeśli już Państwo je mają, budujemy na nim.

Więcej: Wdrożenie i synchronizacja ERP oraz CRMOdnośnik do tego pytania

Prosimy wybrać ten, który pasuje do procesów, integracji i użytkowników. Porównujemy opcje z Państwa wymaganiami, istniejącymi licencjami i systemami, z którymi CRM musi się łączyć, i przedstawiamy kompromisy na piśmie. Jeśli mają już Państwo CRM, najpierw przeglądamy jego konfigurację, dane i integracje, bo problemy tam są częstsze niż ograniczenia produktu.

Więcej: Wdrożenie i synchronizacja ERP oraz CRMOdnośnik do tego pytania

Za dużo to wtedy, gdy aktualizacje stają się ryzykowne, a każda zmiana wymaga programisty. Najpierw konfigurujemy to, co oferuje platforma, a kod niestandardowy budujemy tylko tam, gdzie proces tego wymaga i warto go utrzymywać. Każda funkcja niestandardowa jest udokumentowana i przetestowana, aby aktualizacje pozostały zarządzalne.

Więcej: Wdrożenie i synchronizacja ERP oraz CRMOdnośnik do tego pytania

Faza 2, integracyjna, wymaga połączenia systemów podatników z platformą FATOORA. Standardowe faktury podatkowe są odprawiane przez ZATCA, zanim dotrą do nabywcy, a faktury uproszczone raportowane wkrótce potem. Każda faktura niesie pieczęć kryptograficzną i kod QR, więc ERP lub POS musi je tworzyć w wymaganym formacie.

Więcej: E-fakturowanie, podatki i cyfrowe paszporty produktówOdnośnik do tego pytania

PINT-AE to specyfikacja ZEA formatu faktury PEPPOL International, używana w programie e-fakturowania ZEA. Faktury są wymieniane w tym formacie strukturalnym przez akredytowanych usługodawców i raportowane do Federalnej Administracji Podatkowej, której platforma EmaraTax obsługuje podatki w ZEA.

Więcej: E-fakturowanie, podatki i cyfrowe paszporty produktówOdnośnik do tego pytania

VAT w erze cyfrowej (ViDA) to unijny pakiet przenoszący transgraniczne fakturowanie biznesowe na strukturalne e-faktury i raportowanie cyfrowe. Dotyczy każdej firmy, która fakturuje klientów w UE lub prowadzi unijne podmioty, niezależnie od siedziby.

Więcej: E-fakturowanie, podatki i cyfrowe paszporty produktówOdnośnik do tego pytania

Cyfrowy paszport produktu (DPP) to unijny zapis materiałów, pochodzenia, naprawialności i recyklingu produktu, udostępniany przez nośnik danych, taki jak kod QR. Wprowadzany jest etapami według grup produktów. Zależy od danych łańcucha dostaw, które zwykle znajdują się w ERP i systemach produkcyjnych.

Więcej: E-fakturowanie, podatki i cyfrowe paszporty produktówOdnośnik do tego pytania

Często dodatek jest właściwym punktem wyjścia, a my go konfigurujemy i rozszerzamy, zamiast budować obok. Zwykle zostaje praca nad danymi: typy faktur, kody podatkowe, dane podstawowe i wyjątki, których dodatek nie obejmuje. POS i inne systemy wystawiające faktury też wymagają połączenia.

Więcej: E-fakturowanie, podatki i cyfrowe paszporty produktówOdnośnik do tego pytania

Tak. Budujemy jedną warstwę integracji z konektorem dla każdego obowiązku. ERP tworzy jedną fakturę, a warstwa formatuje, podpisuje i wysyła ją dla każdego kraju. Dodanie kraju staje się konfiguracją, mapowaniem i testami.

Więcej: E-fakturowanie, podatki i cyfrowe paszporty produktówOdnośnik do tego pytania

ISO 20022 to międzynarodowy standard komunikatów finansowych. Jego komunikaty XML niosą ustrukturyzowane dane, takie jak pełne nazwy, adresy i szczegóły tytułu płatności, których starsze formaty SWIFT MT nie przenoszą. Banki i systemy płatności na niego przeszły, więc pliki płatności i wyciągów na nim oparte lepiej się uzgadniają i częściej przechodzą kontrole zgodności.

Więcej: Bankowość, skarb i łączność ISO 20022Odnośnik do tego pytania

Używamy pain.001 do płatności, pain.002 do statusów, camt.052, camt.053 i camt.054 do raportów rachunków oraz komunikatów pacs między bankami. Odczytujemy też wyciągi MT940 i MT942, które wiele banków nadal wysyła. Transport to host-to-host SFTP, EBICS, SWIFT lub API banków. Każdy bank ma własny wariant każdego formatu, więc budujemy na podstawie jego przewodnika wdrożenia.

Więcej: Bankowość, skarb i łączność ISO 20022Odnośnik do tego pytania

SAP S/4HANA, Oracle Fusion Cloud ERP i NetSuite, Microsoft Dynamics 365, Odoo i Sage, a także systemy skarbu i systemy niestandardowe. Gdy ERP ma własny moduł komunikacji bankowej, konfigurujemy go i rozszerzamy, zamiast budować obok.

Więcej: Bankowość, skarb i łączność ISO 20022Odnośnik do tego pytania

Tak, gdy agent rozliczeniowy lub procesor go oferuje. ISO 8583 to raczej szkielet niż jeden format: każdy agent rozliczeniowy publikuje własną specyfikację pól i typów komunikatów. Budujemy na podstawie tej specyfikacji, obsługujemy autoryzacje, odwrócenia i komunikaty doradcze oraz testujemy każdy kod odpowiedzi.

Więcej: Płatności, handel agentowy (AP2) i POSOdnośnik do tego pytania

Agent Payments Protocol (AP2) to otwarty protokół płatności dokonywanych przez agentów AI. Każdy zakup niesie podpisane mandaty pokazujące, co klient autoryzował, więc sprzedawcy, wydawcy i agenci rozliczeniowi mogą mu ufać i go audytować. Jeśli agenci AI prawdopodobnie będą kupować u Państwa, możemy przygotować kasę na AP2 obok obecnych przepływów.

Więcej: Płatności, handel agentowy (AP2) i POSOdnośnik do tego pytania

Tak, dzięki SoftPOS. Karty zbliżeniowe i portfele cyfrowe są przyjmowane na obsługiwanym telefonie lub tablecie przez certyfikowaną aplikację płatniczą od Państwa agenta rozliczeniowego lub dostawcy. Integrujemy tę aplikację z przepływami POS, sprzedaży i rozliczeń jak każdy inny terminal.

Więcej: Płatności, handel agentowy (AP2) i POSOdnośnik do tego pytania

Sklep sprzedaje dalej. Sprzedaż jest zapisywana lokalnie i wysyłana do ERP po powrocie połączenia, każda z unikalnym identyfikatorem, aby nic nie zaksięgowano dwa razy. To, czy płatności kartą mogą trwać offline, zależy od zasad agenta rozliczeniowego i Państwa apetytu na ryzyko; projektujemy to wspólnie.

Więcej: Płatności, handel agentowy (AP2) i POSOdnośnik do tego pytania

To zależy od liczby połączeń i od tego, kto będzie je prowadzić. Platforma integracyjna, taka jak MuleSoft, Boomi lub Azure Logic Apps, daje gotowe konektory, mapowanie i monitoring w jednym miejscu, za opłatą licencyjną. Usługi własne dają pełną kontrolę i brak licencji, ale więcej kodu do utrzymania. Porównujemy oba warianty dla Państwa przypadku.

Więcej: Usługi integracji middleware i APIOdnośnik do tego pytania

Magistrala usług korporacyjnych kieruje i przekształca komunikaty przez centralny węzeł. Szyna zdarzeń rozprowadza zdarzenia przez sieć połączonych brokerów, więc systemy w różnych chmurach i lokalizacjach publikują i subskrybują bezpośrednio. Wiele środowisk używa obu, przechodząc z jednego na drugi.

Więcej: Usługi integracji middleware i APIOdnośnik do tego pytania

Projektujemy wokół opublikowanych limitów każdego partnera. Grupujemy żądania, gdy API na to pozwala, buforujemy dane rzadko się zmieniające, rozkładamy zadania zaplanowane i zwalniamy, gdy limit jest blisko. Monitoring pokazuje, jak blisko limitu działa każdy przepływ.

Więcej: Usługi integracji middleware i APIOdnośnik do tego pytania