Gå til innhold

Integration API — fagområder og dataeffekter

API-et har parallelle controllere for v1 og v2. De bruker i hovedsak de samme fagtjenestene og databasetabellene.

flowchart TD
  api["Integration API"] --> master["Masterdata"]
  api --> operations["Operative data"]
  api --> finance["Økonomi"]
  master --> actor["Actor"]
  master --> product["Product"]
  master --> config["Configuration"]
  operations --> time["Time"]
  operations --> work["WorkOrder"]
  operations --> project["ProjectTask"]
  operations --> asset["NisAssets"]
  finance --> accounting["Accounting"]
  finance --> deal["Deal / CRM"]

Controlleroversikt

Controller v1/v2 Hoveddata Viktige skriveeffekter
Accounting 21 / 22 Ansvarsenheter, konto, lager, leverandør, bilag Cache-/grunndata, produkter og bilag; flere ruter er kun stubber
Actor 13 / 12 Kunde, leverandør, ansatt og adresser Upsert, adresseerstatning og soft delete i wv_Actor
Configuration 5 / 5 Setup mode og API-konfigurasjon wv_ws_config_update
Deal 8 / 8 CRM-pipeline, stages og salgsmuligheter Deal, stage-overgang, historikk og sletting
NisAssets 3 / 3 Anleggsmidler wv_NisAssets_save
Product 5 / 5 Produkt/artikkel og lagerfilter Create, update og delete via produkt-SP-er
ProjectTask 7 / 7 Prosjekter, buckets og oppgaver Opprett, oppdater og soft delete av oppgave
Time 14 / 15 Lønnsarter, timer, timebank og eksport Timelinjer, ekstern ID, sletting og kvittering
WorkOrder 7 / 7 Ordrehode, linjer og ERP-kostnader Ordre/linjer, lagertransaksjon og kostnadskvittering

Faktisk persistens

flowchart LR
  endpoint["POST/PUT/DELETE"] --> model{"Input gyldig?"}
  model -- "Nei" --> bad["400"]
  model -- "Ja" --> implementation{"Persistens koblet?"}
  implementation -- "Ja" --> db["Skriv til database"]
  db --> result["Returner lagringsresultat"]
  implementation -- "Nei" --> accepted["Returner Accepted-melding<br/>uten databaseendring"]

Følgende v2 Accounting-ruter har ikke koblet persistens i dagens kildekode:

Ressurs Rute/handling
Responsible units PUT responsible-units/{no}
Voucher types POST voucher-types, PUT voucher-types/{no}
Stocks POST stocks, PUT stocks/{stockNo}
Accounts PUT accounts/{accountNo}
Business units POST business-units, PUT business-units/{no}
Suppliers PUT suppliers/{supplierNo}
Voucher series POST voucher-series, PUT voucher-series/{seriesId}

Disse rutene returnerer en melding med teksten «persistence not wired yet». Integrasjoner må behandle det som ikke lagret, selv om HTTP-status er 200.

v2-ruter med bekreftet Accounting-persistens inkluderer:

  • POST responsible-units
  • POST products
  • POST accounts
  • POST suppliers
  • POST vouchers

v1 har flere Accounting-stubber enn v2. Bruk Swagger og denne siden sammen, og verifiser lagring i sandkasse før produksjonsoppsett.

Viktige dataeffekter

Time

  • Leser og skriver wv_Time_WageReg gjennom etablerte SP-er.
  • Kan opprette eller oppdatere flere dager ved RepeatDays.
  • Kan automatisk overføre en lagret timelinje til arbeidsordre når kundens arbeidsordreinnstilling tillater det.
  • Eksportkvittering lagrer ekstern ID.
  • Slettede registreringer har egen les/kvitteringsflyt.

WorkOrder

  • Ordrehode lagres via wv_WorkOrder_ins.
  • Linjer lagres via wv_WorkOrderLine_ins.
  • Linjer kan synkroniseres til wv_Stock_Transaction og oppdatere wv_Stock_Balance.
  • ERP-kostnader kan markeres som hentet og senere bekreftes i ERP-tabellen AcTr.
  • Remote Visma Business-oppsett støtter ikke alle kostnadsfunksjoner.

Actor og CRM

  • Actor upsert finner eksisterende rad på ID eller eksterne nummer.
  • Adresser erstattes ved lagring.
  • Actor delete er soft delete.
  • Deal lagrer stage-endringer i wv_CRM_DealHistory.
  • ProjectTask delete er soft delete, mens Deal delete også fjerner historikk før deal-raden slettes.

Accounting og produkt

  • Ansvarsenheter med type 1–3 går via R-dimensjons-SP-er.
  • Type 4–10 går via wv_Time_RespUnit_ins.
  • Kontoer og leverandører oppdaterer eksterne cachetabeller.
  • Bilag bygges med header og linjer i wv_ExtCache_Vo_*.
  • Product-controlleren bruker egne create/update/delete-SP-er.

Før en integrasjon aktiveres

  1. Finn konkret endepunkt i Swagger.
  2. Kontroller om handlingen er lesing, faktisk persistens eller stub.
  3. Dokumenter nøkkelen som gjør operasjonen idempotent.
  4. Test samme payload to ganger i sandkasse.
  5. Kontroller databaseeffekt og eventuelle lager-/ERP-sideeffekter.
  6. Implementer kvittering og retry per element.

Kildepunkter

  • ePortalIntegrationApi/Controllers/
  • ePortalIntegrationApi/Controllers/V2/
  • ePortalIntegrationApi/Services/AccountingService.cs
  • ePortalIntegrationApi/Services/ActorService.cs
  • ePortalIntegrationApi/Services/TimeService.cs
  • ePortalIntegrationApi/Services/WorkOrderService.cs
  • ePortalIntegrationApi/Services/ProjectTaskService.cs
  • ePortalIntegrationApi/Services/DealService.cs

Relaterte sider