Hur ENIT Flowbuilder förkortade ett fakturaintegrationsprojekt

När en ledande bilåterförsäljare behövde ett nytt system för automatisering av fakturahanteringen kunde deras interna IT-team inte leverera det – inte för att uppgiften var för komplex, utan för att de saknade resurser och rätt verktyg. ENIT klev in och med hjälp av ENIT Flowbuilder i kombination med OpenText gick man från uppdragsbeskrivning till driftsättning på mindre än två månader. Så här såg det ut i praktiken.

Problemet: En klyfta mellan behov och tillgång

Återförsäljaren driver en e-handelsplattform där kunderna kan köpa biltillbehör och extrautrustning dygnet runt. Varje köp genererar en faktura – en faktura som måste utfärdas, undertecknas och rapporteras till den nationella skattemyndigheten, allt på ett sätt som uppfyller gällande regler och kan granskas.

Kunden använde redan OpenText för fakturahantering från SAP och andra äldre system. När ett nytt fakturaflöde behövdes för att hantera fakturor från e-handelsplattformen hamnade projektet hos det centrala IT-teamet. De utvärderade det och kom fram till att de inte kunde ta sig an uppdraget – brist på tillgängliga resurser och erfarenhet av integrationslagret innebar att tidsplanen skulle dra ut långt över vad verksamheten behövde.

ENIT arbetade redan med projektet. Uppdraget presenterades under de inledande diskussionerna och ENIT-teamet meddelade att de kunde genomföra det snabbt. Utveckling, testning och leverans skedde på mindre än två månader.

Hur ENIT Flowbuilder förkortade utvecklingscykeln

Hastigheten berodde på arkitekturen. Istället för att skriva integrationskod från grunden satte teamet ihop flödet visuellt med hjälp av ENIT Flowbuilder – ENIT:s egen low-code-integrationsplattform som är utvecklad just för denna typ av processkoordinering.

Flödet hanterar hela processen från början till slut:

• Hämtar data från återförsäljarens e-handelsplattform via API enligt ett fast schema och bläddrar igenom nya fakturor och kreditnotor
• Hämtar varje dokument som JSON och konverterar det till XML för vidare bearbetning
• Kontrollerar om det finns dubbletter i ett bearbetat arkiv, så att ingen faktura skickas ut två gånger
• Skickar XML-filen till skattemyndigheterna – och returnerar en kryptografisk signatur till fakturauppgifterna
• Infogar en QR-kod på varje faktura som konsumenterna kan skanna för att kontrollera dokumentets giltighet via skattemyndighetens egen portal
• Skickar det undertecknade dokumentet till OpenText , som skapar den slutliga PDF-filen och distribuerar den – främst via e-post

Flödet registrerar dessutom varje transaktion i en databas – hämtar tidsstämplar, fakturor och batch-ID:n – och hanterar fel på ett smidigt sätt: om en SFTP-överföring inte går igenom flyttas filen till en mapp för omförsök och skickas på nytt vid nästa cykel.

Det här är inte någon enkel testintegration. Den hanterar flera dokumenttyper, sidnumrering, felhantering, dubblettkontroll, reglerad signering och revisionsloggning. Att den utvecklades och levererades på sex veckor säger mer om verktygen än om hur enkel uppgiften var.

Varför efterlevnaden av skattereglerna inte bromsade upp utvecklingen

I många integrationsprojekt medför efterlevnadskrav både utökad omfattning och ökad osäkerhet. I det här fallet betraktades signeringssteget – där varje faktura förses med en myndighetsföreskriven kryptografisk signatur innan den kan utfärdas på ett lagligt sätt – som en helt vanlig del i flödet.

Eftersom ENIT Flowbuilder skiljer integrationslogiken från utdataskiktet innebär det inte att man måste bygga om hela pipelinen när man lägger till ett steg för reglerhantering. Data passerar igenom, signeras och skickas vidare till Exstream. Varje steg är synligt, granskningsbart och kan testas separat.

Detta tillvägagångssätt kan direkt tillämpas på andra regelverk: ZUGFeRD i Tyskland, PEPPOL för gränsöverskridande B2B-transaktioner eller Swefaktura för den svenska offentliga sektorn. Den bakomliggande principen är densamma – ett definierat omvandlingssteg, inte ett nytt projekt.

Vad detta innebär för process- och produktägare

Resultatet blev inte bara en snabbare leverans. Det blev en helt ny modell för hur integrationsarbetet genomförs.

Traditionella utvecklingscykler – definiera, upphandla, utveckla, testa, driftsätta – är lämpliga för utveckling av stora plattformar. De är dock oproportionerliga för integrationsarbete, där logiken är välkänd men genomförandet begränsas av tillgängliga resurser och verktygens flexibilitet. ENIT Flowbuilder har utvecklats för att överbrygga denna klyfta: flödena byggs upp visuellt, ändringar kan spåras och affärslogiken finns i själva flödet istället för att vara gömd i applikationskoden.

För en processägare innebär det att du kan se vad systemet gör. För en produktägare innebär det att ändringsförslag inte kräver en utvecklingssprint. För en lösningsarkitekt innebär det att integrationslagret går att underhålla utan att man är beroende av intern kunskap.

Funderar du på ett liknande problem?

Om ni har en fakturahanteringsprocess som är beroende av äldre systemintegrationer, en tidsfrist för regelefterlevnad som IT-avdelningen säger att de inte hinner klara i tid, eller en leveranskö som bara växer – hjälper vi er gärna att se över hur detta skulle kunna se ut i just er verksamhet.

Kontakta ENIT för att komma igång, eller läs mer om ENIT Flowbuilder på enit.se.