Ordre- og handelssystemer
Et ordresystem kan sende afsluttede ordrelinjer til en fakturakladde. Partner-API'et understøtter denne afgrænsning med invoices:write. Ordren skal have en stabil ekstern identitet, så genforsøg ikke skaber flere kladder for samme tilsigtede operation.
Lagerstatus, leveringsstatus, betaling og kreditnotaer er andre processer. De må ikke fremstå synkroniserede, bare fordi fakturakladden blev oprettet. Partner-API'et har ikke en komplet handelsconnector med alle disse tilstande.
Servicevirksomheder og tidsbaseret fakturering
Et servicesystem kan levere en fakturalinje med antal timer, enhed og pris. Mængde og enhedspris skal mappes hver for sig; en mængde på 1,5 timer er ikke et beløb på 1,5 øre. Fakturalinjer accepterer op til tre decimaler i mængde, mens prisen er hele øre.
Timegrundlagets faglige godkendelse ligger ikke automatisk i invoices:write. Et senere tids-API skal have sine egne medarbejder- og godkendelsesregler. Undlad personfølsomme oplysninger i fritekstfelter, hvis opgaven kun kræver en samlet ydelseslinje.
Regnskabsintegrationer
En bogføringsintegration kan forberede og eventuelt bogføre balancerede posteringer med kundens valgte kontireferencer. Det er et snævert mandat til den pågældende organisation, ikke læseadgang til hele hovedbogen.
Behov for fuld regnskabssynkronisering, åbningsbalancer, historiske bilag eller korrektioner kræver flere konkrete kontrakter end den første gatewayprofil leverer. Beskriv dem særskilt i stedet for at antage, at alle interne regnskabsruter er offentlige.
Kæder og franchises
En kædeapp kan genbruge den samme apprevision hos flere kunder, men hver juridisk enhed har sin egen grant. Kontireferencer og tokens skal holdes adskilt. En fejl i routing mellem to butikker er en datagrænsefejl, ikke blot en forkert filterindstilling.
Start med test af mindst to enheder, før du kalder integrationen flerorganisationsklar. Se kæder for mapping og rollegrænser.
Leverandør- og kontraktprodukter
Et produkt kan have behov for aftaleoversigt, udløbsdatoer eller forhandlingsflow. Hours har relevante interne modeller, men partner-API'et udstiller ikke et generelt kontrakt-API. Behovet skal beskrives med nødvendige felter og handlinger, så en senere kontrakt kan afgrænses.
En opsigelse, en e-mail eller en underskrift er en reel ekstern handling. Den skal ikke ligge som en overraskelse i et generisk "synkroniser leverandør"-kald.
En konkret integrationsbeskrivelse
En god appbeskrivelse angiver kildesystem, udløsende hændelse, input, handling i Hours og det resultat, brugeren ser. Angiv også, hvilke undtagelser der kræver menneskelig behandling. Det gør review og kundeautorisation mere præcist end et branchestempel.
Bankdata og betalingsinitiering er udelukket i alle disse mønstre. Branche eller virksomhedsstørrelse ændrer ikke partner-API'ets dataafgrænsning.