LagDinBridgeLagDinBridge

WooCommerce → PowerOffice Go

Teknisk integrasjonsbeskrivelse for API-gjennomgang

Oversikt

LagDinBridge automatiserer dataflyt mellom WooCommerce-nettbutikker og PowerOffice Go. Ordrer, kunder, produkter og betalinger synkroniseres automatisk, slik at du slipper manuell dobbeltregistrering og reduserer feil.

Hva synkroniseres

Kunder

Opprettes og oppdateres automatisk i PowerOffice Go basert på nettbutikkordrer

Produkter

Varenavn, SKU, pris og momskode synkroniseres mellom systemene

Salgsordrer

Ordrelinjer med mengde, enhetspris, rabatt og moms overføres automatisk

Fakturering

Utgående faktura opprettes og sendes automatisk ved fullførte ordrer

Innbetalinger

Betalinger bokføres som bankbilag når betaling er bekreftet

Krediteringer

Kreditnota via OutgoingCreditNoteJournals for både full og delvis refusjon

Autentisering (OAuth2)

PowerOffice Go bruker OAuth2 Client Credentials Grant med tre nøkler:

Application Key

Identifiserer LagDinBridge-utvidelsen. Fast per miljø (demo/prod).

Client Key

Unik per Go-klient. Genereres i PowerOffice Go → Utvidelser.

Subscription Key

Fra PowerOffice Developer Portal. Sendes som header.

MetodeEndepunktFormål
POST/OAuth/TokenHent OAuth2 access token (Client Credentials Grant)
Token-forespørsel
POST /OAuth/Token
Content-Type: application/x-www-form-urlencoded
Authorization: Basic base64(ApplicationKey:ClientKey)
Ocp-Apim-Subscription-Key: {subscription_key}

grant_type=client_credentials
Token-levetid: 20 minutter. LagDinBridge fornyer tokenet automatisk 60 sekunder før utløp. Alle credentials lagres kryptert med Fernet (AES-128-CBC + HMAC-SHA256).

PowerOffice Go API-endepunkter

Kundebehandling

MetodeEndepunktFormål
GET/Customers?emailAddresses={email}Finn kunde på e-postadresse
GET/Customers?organizationNumbers={orgNr}Finn kunde på organisasjonsnummer (B2B)
POST/CustomersOpprett ny kunde
PATCH/Customers/{id}Oppdater eksisterende kunde (JSON Patch)
GET/Customers/{id}Hent kundedetaljer + SubledgerAccountId

Fakturering

MetodeEndepunktFormål
POST/Vouchers/OutgoingInvoiceJournalsBokfør faktura direkte til hovedbok (betalt)
POST/SalesOrders/CompleteOpprett salgsordre-utkast (B2B/faktura)
POST/SalesOrders/{id}/CreateAndSendInvoiceKonverter utkast → faktura (asynkron)
GET/SalesOrders/SentState?salesOrderIds={id}Poll status etter sending
OutgoingInvoiceJournals — Request-eksempel
{
  "InvoiceNo": 170,
  "VoucherDate": "2026-02-09",
  "DueDate": "2026-02-09",
  "CurrencyCode": "NOK",
  "CurrencyAmount": 125.00,
  "CustomerAccountId": 42361164,
  "ExternalImportReference": "wc-170",
  "Description": "Ordre #170",
  "CustomMatchingReference": "170",
  "VoucherLines": [
    {
      "AccountId": 42357907,
      "VatId": 101,
      "CurrencyAmount": -125.00,
      "Description": "Produktnavn",
      "Quantity": 1.0
    }
  ]
}
Balanseregel: CurrencyAmount + SUM(VoucherLines.CurrencyAmount) = 0. Faktura-beløp (AR debet) er positivt, ordrelinjer (kredit) er negative.

Kreditnotaer (refusjoner)

MetodeEndepunktFormål
POST/Vouchers/OutgoingCreditNoteJournalsKreditnota direkte til hovedbok (full og delvis refusjon)
OutgoingCreditNoteJournals — Request-eksempel
{
  "InvoiceNo": 9000171,
  "VoucherDate": "2026-02-09",
  "CurrencyCode": "NOK",
  "CurrencyAmount": -25.00,
  "CustomerAccountId": 42361164,
  "ExternalImportReference": "wc-refund-170-171",
  "Description": "Kreditnota til faktura #170",
  "CustomMatchingReference": "170",
  "VoucherLines": [
    {
      "AccountId": 42357907,
      "VatId": 101,
      "CurrencyAmount": 25.00,
      "Description": "Refusjon faktura #170",
      "Quantity": 1.0
    }
  ]
}

Betalingsregistrering

MetodeEndepunktFormål
POST/Vouchers/BankJournalsRegistrer innbetaling eller refusjonsbetaling

Produkter

MetodeEndepunktFormål
GET/ProductsHent alle produkter
POST/ProductsOpprett nytt produkt
PATCH/Products/{id}Oppdater produkt (JSON Patch)

Oppslag og hjelpeendepunkter

MetodeEndepunktFormål
GET/VatCodesMVA-koder (SAF-T → VatId mapping)
GET/GeneralLedgerAccounts?accountNos={nr}Kontonummer → intern ID
GET/ClientAdmin/ClientsTilkoblingstest + firmanavn

WooCommerce API-endepunkter

MetodeEndepunktFormål
GET/wp-json/wc/v3/orders?status=completed&per_page=100Hent ordrer (paginert)
GET/wp-json/wc/v3/orders/{id}Enkeltordre med detaljer
GET/wp-json/wc/v3/orders/{id}/refundsRefusjoner for en ordre
GET/wp-json/wc/v3/products?per_page=100Hent produkter (paginert)
POST/wp-json/wc/v3/webhooksOpprett webhook-abonnement
Autentisering: Basic Auth med Consumer Key + Consumer Secret. Webhook-signaturer verifiseres med HMAC-SHA256 (X-WC-Webhook-Signature).

Dataflyt — Ordresynkronisering

1

Hent ordrer fra WooCommerce

REST API v3 med paginering. Kun ordrer med status 'completed' eller 'processing' (betalt).

2

Sjekk idempotens

wc_poweroffice_mappings sikrer at ingen ordre behandles to ganger. Sjekk på wc_order_id + integration_id.

3

Finn, oppdater eller opprett kunde

Søk på org.nr (B2B) eller e-post. Oppdater eksisterende kunde hvis navn, adresse eller telefon har endret seg (JSON Patch). Opprett ny kunde hvis ikke funnet.

4

Bestem MVA-kode

Basert på kundens land: norsk (3/31/33), EU B2B (5), utenfor EU (52), fritatt (6).

5

Bygg fakturalinjer

Ordrelinjer med produktnavn, antall, enhetspris (brutto inkl. MVA), rabatt og frakt.

6

Bestem overføringsmodus

Fakturabetaling (bacs/invoice) → DRAFT eller UNPAID. Online-betaling (Stripe/Vipps) → PAID.

7

Opprett faktura/ordre

PAID: OutgoingInvoiceJournals + BankJournals. DRAFT: SalesOrders/Complete. UNPAID: OutgoingInvoiceJournals uten betaling.

8

Lagre mapping

PowerOffice faktura-ID og status lagres i wc_poweroffice_mappings for sporing og refusjoner.

Synkroniseringsfrekvens

Standard

Nattlig batch-synkronisering

Alle nye og endrede ordrer synkroniseres automatisk kl. 02:00 hver natt.

Valgfritt

Sanntid via webhook

Ordrer og produkter overføres i sanntid ved endringer i WooCommerce.

Ved behov

Manuell synkronisering

Brukeren kan trigge synkronisering av enkeltordrer eller batch fra dashbordet.

Kl. 04:00

Automatisk feilhåndtering

Feilede synkroniseringer forsøkes automatisk på nytt med exponential backoff.

MVA-håndtering (SAF-T)

SAF-T kodeSatsBeskrivelse
325%Standard norsk MVA (de fleste varer og tjenester)
3115%Næringsmidler (mat og drikke)
3312%Transport, overnatting, kino
50%EU B2B med gyldig org.nr. (omvendt avgiftsplikt)
60%Utenfor MVA-området
520%Eksport (utførsel)

Bestemmelseslogikk

MVA-kode basert på kundens land
Hvis land = NO:
    Mat/drikke      → 15% (SAF-T kode 31)
    Transport/hotell → 12% (SAF-T kode 33)
    Standard        → 25% (SAF-T kode 3)

Hvis land i EU + B2B + gyldig org.nr:
    → 0% omvendt avgiftsplikt (kode 5)

Hvis utenfor EU:
    → 0% eksport (kode 52)

Betalingskonto-mapping

BetalingsmetodeKontoBeskrivelse
Bankoverføring (bacs)1920Bankinnskudd
Kontant (cod)1900Kontanter
Stripe1910Andre innbetalinger
PayPal1910Andre innbetalinger
Klarna1910Andre innbetalinger
Vipps1910Andre innbetalinger
Standard (ukjent)1920Bankinnskudd (fallback)

Prioritet: Bruker-konfigurert per-metode → bruker-global → innebygd mapping → 1920 (fallback)

Fremmedvaluta-støtte

LagDinBridge sender ordrevalutaen direkte til PowerOffice Go. For ordrer i EUR, USD, GBP eller andre valutaer opprettes fakturaen i originalvalutaen. PowerOffice Go håndterer valutakurs og agio/disagio automatisk når AutoAdjustCurrencyExchangeDifference er satt til true.

Eksempel: EUR-faktura i PowerOffice Go
Faktura #10010 — Valuta: EUR
Beløp:    49,00 EUR (hvorav MVA 9,80 EUR)

BankJournals (betaling):
  CurrencyCode: "EUR"
  AutoAdjustCurrencyExchangeDifference: true
  VoucherLines:
    Debet  1920 Bank         49,00 EUR
    Kredit 1500 Kundefordring 49,00 EUR

→ PowerOffice Go henter valutakurs fra Norges Bank
→ Beløpet bokføres i NOK automatisk
→ Agio/disagio (kursdifferanse) føres automatisk
Refusjon i fremmedvaluta
Kreditnota og refusjonsbetaling bruker samme valuta
som originalordren (lagret i mapping-tabellen).

  CurrencyCode: "EUR"  (fra original.currency)
  AutoAdjustCurrencyExchangeDifference: true

→ Kursdifferanse mellom faktura- og
  refusjonstidspunkt håndteres automatisk
Regnskapsmessig korrekt: Bokføringsloven tillater utstedelse av salgsdokumenter i fremmedvaluta, men krever at regnskapet føres i NOK. PowerOffice Go håndterer dette automatisk ved å sette AutoAdjustCurrencyExchangeDifference: true på betalingsbilag (BankJournals). Kursdifferanser (agio/disagio) føres automatisk til konto 8060/8160.

Automatisk kundeoppdatering

Når en ordre synkroniseres, sjekker LagDinBridge om kundens data har endret seg siden forrige gang. Hvis navn, adresse, postnummer, by, telefon eller organisasjonsnummer er endret, oppdateres kunden automatisk i PowerOffice Go via JSON Patch før fakturaen opprettes.

FeltSjekkesOppdateres
Navn (Name)JaJa
Fornavn (FirstName)JaJa
Etternavn (LastName)JaJa
AdresseJaJa (MailAddress/AddressLine1)
PostnummerJaJa (MailAddress/ZipCode)
ByJaJa (MailAddress/City)
LandJaJa (MailAddress/CountryCode)
TelefonJaJa (PhoneNumber)
OrganisasjonsnummerJaJa (OrganizationNumber)
E-postBrukes som oppslagsnøkkelJa (EmailAddress + InvoiceEmailAddress)

B2B-kundeoppslag

For bedriftskunder (B2B) prioriteres oppslag på organisasjonsnummer fremfor e-post. Dette sikrer at samme bedrift alltid kobles til riktig kunde i PowerOffice Go, selv om kontaktpersonen endrer e-postadresse.

Oppslagsprioritet
1. Organisasjonsnummer (B2B):
   GET /Customers?organizationNumbers={orgNr}
   → Samme firma, uansett kontaktperson

2. E-post (fallback):
   GET /Customers?emailAddresses={email}
   → Privatpersoner og B2C-kunder

3. Opprett ny (hvis ingen treff):
   POST /Customers med currency_code fra ordren
Bokføringsloven §5-1-1: Salgsdokumentasjon skal inneholde korrekt kundeadresse. Automatisk oppdatering sikrer at fakturaer alltid har riktig adresse, også når kunden har flyttet eller endret navn. Oppdatering gjøres via JSON Patch (PATCH /Customers/{id}) som kun endrer de feltene som faktisk er ulike.

Overføringsmoduser

Betalt (paid)

Brukes for online-betalinger (Stripe, PayPal, Vipps, Klarna). Faktura bokføres direkte via OutgoingInvoiceJournals, deretter registreres betaling via BankJournals.

Ubetalt (unpaid)

Brukes for fakturabetalinger (B2B). Faktura bokføres via OutgoingInvoiceJournals uten betalingsregistrering. Vises som utestående kundefordring.

Utkast (draft)

Salgsordre opprettes via SalesOrders/Complete. Konverteres manuelt til faktura i PowerOffice Go.

Refusjonshåndtering

Alle refusjoner (full og delvis) oppretter en formell kreditnota via OutgoingCreditNoteJournals. Dette er i henhold til Bokføringsforskriften § 5-2-1 som krever kreditnota som salgsdokumentasjon ved kreditering.

Full refusjon (≥99% av beløpet)

Kreditnota opprettes via OutgoingCreditNoteJournals med alle originalfakturaens linjer reversert. InvoiceNo = 9.000.000 + wc_order_id. For online-betalinger registreres refusjons­betaling via BankJournals (kredit bank, debet kunde-reskontro). For fakturabetalinger reverseres kun kundefordringen uten betalingsbilag.

Delvis refusjon (<99%)

Kreditnota opprettes via OutgoingCreditNoteJournals med proporsjonell MVA-fordeling etter Bokføringsforskriften § 5-1-1. InvoiceNo = 9.000.000 + wc_refund_id. CustomMatchingReference kobler kreditnotaen til originalfakturaen. Refusjonsbetaling registreres som kredit på bankkonto og debet på kunde-reskontro.

Verifiseringsmodus (staging)

Når verifiseringsmodus er aktivert, legges ordrer og refusjoner i en staging-kø for manuell godkjenning. Brukeren ser ordredetaljer, kundeinfo, fakturalinjer og betalingsmetode før overføring til PowerOffice Go. Refusjoner på staging-ordrer kobles automatisk til den opprinnelige staging-oppføringen.

Staging-flyt
1. Ordre mottas fra WooCommerce
2. Kunde opprettes/oppdateres i PowerOffice Go
3. Fakturalinjer og betalingsinfo beregnes
4. Alt lagres som staged_data i databasen (status='staging')
5. Bruker godkjenner i dashbordet
6. Faktura/betaling opprettes i PowerOffice Go
7. Status endres til 'synced'

Refusjoner på staging-ordrer:
→ Lenkes til original staging-oppføring
→ Begge må godkjennes i rekkefølge
Nummerering: Kreditnotaer bruker InvoiceNo = 9.000.000 + wc_refund_id (delrefusjon) eller 9.000.000 + wc_order_id (full refusjon) for å unngå kollisjon med fakturanumre.

Regnskapsmessig føring

Alle bilagsføringer følger norsk regnskapslovgivning: Bokføringsloven § 7 (bilagskrav), Bokføringsforskriften § 5-1-1 (salgsdokumentasjon) og § 5-2-1 (kreditnota ved kreditering). Nedenfor vises konkrete konteringer for hver overføringsmodus og tilhørende refusjonshåndtering.

1. Betalt modus — Online-betaling (Stripe, Vipps, Klarna o.l.)

Kunden har allerede betalt i nettbutikken. Fakturaen bokføres som betalt med én gang.

Ordreoverføring — 2 bilag
Bilag 1: Faktura (OutgoingInvoiceJournals)
┌──────────────────────────────────────────────────────┐
│ Debet  1500 Kundefordring          kr 125,00         │
│ Kredit 3000 Salgsinntekt           kr  100,00        │
│ Kredit 2700 Utgående MVA           kr   25,00        │
└──────────────────────────────────────────────────────┘

Bilag 2: Betaling (BankJournals)
┌──────────────────────────────────────────────────────┐
│ Debet  1920 Bank                   kr 125,00         │
│ Kredit 1500 Kundefordring          kr 125,00         │
└──────────────────────────────────────────────────────┘
→ Resultat: Kundefordring = 0. Faktura er betalt.
Full refusjon — 2 bilag
Bilag 1: Kreditnota (OutgoingCreditNoteJournals)
┌──────────────────────────────────────────────────────┐
│ Kredit 1500 Kundefordring          kr -125,00        │
│ Debet  3000 Salgsinntekt           kr  100,00        │
│ Debet  2700 Utgående MVA           kr   25,00        │
└──────────────────────────────────────────────────────┘

Bilag 2: Refusjonsbetaling (BankJournals)
┌──────────────────────────────────────────────────────┐
│ Kredit 1920 Bank                   kr -125,00        │
│ Debet  1500 Kundefordring          kr  125,00        │
└──────────────────────────────────────────────────────┘
→ Resultat: Inntekt reversert, penger tilbakebetalt. Alle kontoer = 0.
Delvis refusjon (f.eks. kr 49 av 98) — 2 bilag
Bilag 1: Kreditnota (OutgoingCreditNoteJournals)
┌──────────────────────────────────────────────────────┐
│ Kredit 1500 Kundefordring          kr -49,00         │
│ Debet  3000 Salgsinntekt           kr  39,20         │
│ Debet  2700 Utgående MVA           kr   9,80         │
└──────────────────────────────────────────────────────┘

Bilag 2: Refusjonsbetaling (BankJournals)
┌──────────────────────────────────────────────────────┐
│ Kredit 1920 Bank                   kr -49,00         │
│ Debet  1500 Kundefordring          kr  49,00         │
└──────────────────────────────────────────────────────┘
→ Resultat: Delvis inntekt reversert. Forfalt beløp = 0 (betaling utligner kreditnota).
Hvorfor korrekt: Kreditnota opprettes som formelt salgsdokument (§ 5-2-1) med referanse til originalfaktura via CustomerReference og CustomMatchingReference. BankJournals registrerer den faktiske pengestrømmen tilbake til kunden. MVA reverseres proporsjonelt (§ 5-1-1).

2. Ubetalt modus — Fakturabetaling (B2B)

Kunden betaler på faktura. Fakturaen bokføres som utestående kundefordring — ingen betalingsbilag.

Ordreoverføring — 1 bilag
Bilag 1: Faktura (OutgoingInvoiceJournals)
┌──────────────────────────────────────────────────────┐
│ Debet  1500 Kundefordring          kr 98,00          │
│ Kredit 3000 Salgsinntekt           kr 78,40          │
│ Kredit 2700 Utgående MVA           kr 19,60          │
└──────────────────────────────────────────────────────┘
→ Resultat: Faktura vises som UBETALT. Forfalt beløp = 98,00.
  Betaling registreres manuelt i PO når kunden betaler.
Full refusjon — 1 bilag (ingen bankbilag)
Bilag 1: Kreditnota (OutgoingCreditNoteJournals)
┌──────────────────────────────────────────────────────┐
│ Kredit 1500 Kundefordring          kr -98,00         │
│ Debet  3000 Salgsinntekt           kr  78,40         │
│ Debet  2700 Utgående MVA           kr  19,60         │
└──────────────────────────────────────────────────────┘
→ Resultat: Kundefordring = 0. Ingen penger å tilbakebetale
  fordi kunden aldri betalte. Kreditnota utligner fakturaen direkte.
Delvis refusjon (f.eks. kr 49 av 98) — 1 bilag (ingen bankbilag)
Bilag 1: Kreditnota (OutgoingCreditNoteJournals)
┌──────────────────────────────────────────────────────┐
│ Kredit 1500 Kundefordring          kr -49,00         │
│ Debet  3000 Salgsinntekt           kr  39,20         │
│ Debet  2700 Utgående MVA           kr   9,80         │
└──────────────────────────────────────────────────────┘
→ Resultat: Kundefordring redusert fra 98,00 til 49,00.
  Kunden skylder nå kun det gjenværende beløpet.
Hvorfor ingen bankbilag: Kunden har ikke betalt, så det finnes ingen penger å tilbakebetale. Kreditnotaen reduserer kundefordringen direkte i reskontro. CustomMatchingReference kobler kreditnotaen til originalfakturaen slik at PO automatisk motregner beløpene.

3. Utkast modus — Salgsordre

Ordren opprettes som et utkast i PowerOffice Go. Ingen bokføring skjer automatisk.

Ordreoverføring — ingen bilag
SalesOrders/Complete oppretter en salgsordre i PowerOffice Go.
┌──────────────────────────────────────────────────────┐
│ Ingen kontering — dette er kun et utkast.            │
│ Salgsordren må konverteres til faktura manuelt       │
│ i PowerOffice Go av regnskapsfører.                  │
└──────────────────────────────────────────────────────┘
→ Resultat: Ordren ligger som utkast. Ingen påvirkning på regnskap.
Refusjon ved utkast: Hvis det finnes en refusjon på en ordre som ble overført som utkast, slettes salgsordren automatisk fra PowerOffice Go (hvis mulig). Siden utkastet aldri ble bokført, trengs ingen kreditnota.

Oppsummering per modus

ModusOrdre-bilagBetalingsbilagKreditnotaRefusjonsbetaling
Betalt (paid)OutgoingInvoiceJournalsBankJournalsOutgoingCreditNoteJournalsBankJournals (refusjon)
Ubetalt (unpaid)OutgoingInvoiceJournalsIngen — uteståendeOutgoingCreditNoteJournalsIngen — motregnes
Utkast (draft)SalesOrders (utkast)IngenSlett utkastIngen
Lovhjemmel: Bokføringsloven § 7 krever at alle transaksjoner dokumenteres med bilag. Bokføringsforskriften § 5-1-1 stiller krav til innholdet i salgsdokumentasjon (faktura), og § 5-2-1 krever at kreditering av salg dokumenteres med kreditnota som refererer til opprinnelig salgsdokument. LagDinBridge oppfyller dette ved å opprette formelle kreditnotaer (ikke tilbakeføringsbilag) med CustomerReference og CustomMatchingReference som kobler kreditnota til originalfaktura.

Idempotens-mekanismer

KontekstMekanismeNøkkel
Ordre → fakturaExternalImportReferencewc-{wc_order_id}
Ordre → betalingExternalImportReferencepay-wc-{wc_order_id}
Full refusjon → kreditnotaExternalImportReferencewc-refund-{order_id}
Full refusjon → betalingExternalImportReferencerefund-pay-{order_id}-full
Delrefusjon → kreditnotaExternalImportReferencewc-refund-{order_id}-{refund_id}
Delrefusjon → betalingExternalImportReferencerefund-pay-{order_id}-{refund_id}
Refusjon → duplikatsjekkprocessed_refund_ids (JSON)[171, 172, ...]
Ordre → duplikatsjekkDatabase mappingwc_poweroffice_mappings.wc_order_id

Slik kobler du til

Du trenger kun to nøkler: Application Key (fra LagDinBridge) og Client Key (genereres i PowerOffice Go).
  1. 1

    Motta Application Key

    Du får Application Key fra LagDinBridge når du oppretter integrasjonen. Denne identifiserer LagDinBridge-utvidelsen.

  2. 2

    Logg inn i PowerOffice Go

    Gå til Innstillinger → Utvidelser i din PowerOffice Go-konto.

  3. 3

    Legg til ny utvidelse

    Klikk «Ny utvidelse» → velg «Egendefinert» → lim inn Application Key → klikk «Legg til».

  4. 4

    Kopier Client Key

    Etter at utvidelsen er lagt til, vises en Client Key. Kopier den med en gang — den vises kun én gang!

  5. 5

    Lim inn i LagDinBridge

    Fyll inn Application Key og Client Key i LagDinBridge-oppsettet og klikk «Koble til».

Viktig: Client Key vises bare én gang i PowerOffice Go! Hvis du mister den, må du fjerne utvidelsen og legge den til på nytt.

Sikkerhet

Kryptert lagring

Alle API-nøkler og tokens krypteres med Fernet (AES-128-CBC + HMAC-SHA256) før lagring

HTTPS-only

All kommunikasjon med eksterne API-er skjer over TLS 1.2+ — ingen ukryptert trafikk

Tenant-isolering

Hver brukers credentials er isolert — ingen deling av nøkler mellom kunder

Feilhåndtering

Circuit breaker, exponential backoff (5 forsøk), og respekt for rate limits

Forutsetninger

  • Aktiv PowerOffice Go-konto med tilgang til Innstillinger → Utvidelser
  • Bruker med rettigheter til å legge til egendefinerte utvidelser
  • Aktiv WooCommerce-nettbutikk med REST API aktivert (Consumer Key + Consumer Secret)
  • LagDinBridge-konto hos Technobridge
  • Konfigurasjon av momskode-mapping mellom WooCommerce og PowerOffice Go (gjøres i LagDinBridge)

Kontaktinformasjon

Utvikler: Technobridge

E-post: post@technobridge.no

LagDinBridge er utviklet av Technobridge

Spørsmål? Kontakt oss på post@technobridge.no