Översikt
När en synkroniseringsuppgift misslyckas loggar Junipeer ett fel med en specifik felkod och meddelande. Den här guiden listar alla kända felkoder, förklarar vad som orsakar dem och ger lösningssteg.
Du kan också slå upp fel direkt i den nya kunskapsdatabasen påjunipeer-kb.vercel.app/errors, som stöder sökning efter felmeddelande och filtrering efter allvarlighetsgrad.
För att hitta fel för en specifik integration, använd sidanLoggari Junipeer-appen och filtrera efter status "error".
Fortnox Felkoder
COMMON_FORTNOX_ERRORS_EXPLAINED
Allvarlighetsgrad: Fel
Detta är en grupperad referens som täcker två av de vanligaste svenska Fortnox-felen:
"Kunde inte hämta/hitta moms"(Kunde inte hämta/hitta moms)
Orsak: Momssatser är inte konfigurerade i Fortnox.
Lösning: I Fortnox, gå till Inställningar → Bokföring → Moms och skapa den saknade momssatsen. Svenska standardvärden är 25%, 12% och 6% — om dina beställningar inkluderar andra satser (t.ex. från EU-gränsöverskridande försäljning), måste dessa läggas till manuellt.
"Kunde inte hämta/hitta valuta"(Kunde inte hämta/hitta valuta)
Orsak: Beställningens valuta är inte aktiverad i Fortnox.
Lösning: I Fortnox, gå till Inställningar → Leverantörsfakturor → Valuta. Välj den saknade valutakoden och spara. Valutanamnet läggs till automatiskt.
FORTNOX_ACCOUNT_INACTIVE
Allvarlighetsgrad: FelMeddelande: "The account is not active"
Orsak: En produkt i Fortnox är länkad till ett bokföringskonto som har inaktiverats. Kontot måste vara aktivt för att Fortnox ska kunna skapa fakturor.
Lösning: I Fortnox, gå till Inställningar → Bokföring → Kontoplan. Hitta kontot som refereras i felet och återaktivera det. Alternativt kan du uppdatera produkten i Fortnox för att använda ett annat, aktivt konto.
FORTNOX_COST_CENTER_AUTH
Allvarlighetsgrad: FelMeddelande: "Saknar behörighet för kostnadsställen"
Orsak: Fortnox-användaren som är ansluten till Junipeer har inte den licens eller de behörigheter som krävs för kostnadsställen. Kostnadsställen är en av de första sakerna Fortnox kontrollerar vid anslutning, så detta fel kan visas även om du inte aktivt använder kostnadsställen.
Lösning: I Fortnox, gå till Inställningar → Hantera användare. Kontrollera att integrationsanvändaren har rätt licenstyp som inkluderar åtkomst till kostnadsställen. Detta kan kräva uppgradering av användarens Fortnox-licens. SeFortnox Setup-guiden för den fullständiga listan över nödvändiga behörigheter.
FORTNOX_CURRENCY_MISMATCH
Allvarlighetsgrad: FelMeddelande: "Valuta X och Valuta X matchar inte"
Orsak: Under betalningsavstämning är betalningsvalutan och fakturavalutan olika. Fortnox kräver att betalningen och fakturan använder samma valuta.
Lösning: Detta händer vanligtvis när en utbetalning avräknas i en annan valuta än den ursprungliga beställningen. Kontrollera fakturan i Fortnox för att verifiera dess valuta, och kontrollera att betalningsleverantörens utbetalningsrapport använder samma valuta. Om valutorna legitimt skiljer sig åt kan du behöva hantera avstämningen manuellt för dessa transaktioner.
FORTNOX_CURRENCY_NOT_FOUND
Allvarlighetsgrad: FelMeddelande: "Kunde inte hämta/hitta valuta"
Orsak: Beställningen använder en valuta som inte är konfigurerad i Fortnox.
Lösning: I Fortnox, gå till Inställningar → Leverantörsfakturor → Valuta och aktivera den saknade valutan. Försök sedan igen med den misslyckade uppgiften i Junipeer frånTasks-sidan. För att förhindra detta i framtiden, aktivera alla valutor som din e-handelsplattform stöder innan du går live.
FORTNOX_CUSTOMER_NAME_EMPTY
Allvarlighetsgrad: FelMeddelande: "Kundnamn kan inte vara tomt (2000637)"
Orsak: Beställningen i e-handelsplattformen har ingen faktureringsadress eller kundnamn. Fortnox kräver ett kundnamn på alla beställningar och fakturor.
Lösning: Konfigurera ett standardkundnamn i Junipeer under Konfigurera > Inställningar > Kundinställningar. Detta reservvärde kommer att användas när en beställning anländer utan kundnamn (vanligt vid gästutcheckning eller marknadsplatsbeställningar). Du kan också uppdatera beställningen i e-handelsplattformen för att lägga till ett kundnamn och försöka synkronisera igen.
FORTNOX_FISCAL_YEAR
Allvarlighetsgrad: FelMeddelande: "Räkenskapsår inte tillgängligt"
Orsak: Beställningsdatumet faller inom ett räkenskapsår som inte har skapats i Fortnox. Fortnox kräver ett aktivt räkenskapsår för vilket datum som helst då transaktioner bokförs.
Lösning: I Fortnox, gå till Inställningar → Bokföring → Räkenskapsår och skapa det saknade räkenskapsåret. Detta inträffar vanligtvis i början av ett nytt kalenderår om nästa års räkenskapsperiod inte har ställts in ännu. Efter att ha skapat räkenskapsåret, försök igen med de misslyckade uppgifterna.
FORTNOX_PAYMENT_DATE
Allvarlighetsgrad: FelMeddelande: "Betalningsdatumet kan inte föregå fakturadatumet"
Orsak: Under betalningsavstämning är betalningsdatumet som registrerats av betalningsleverantören tidigare än fakturadatumet i Fortnox. Fortnox tillåter inte att en betalning registreras innan fakturan existerar.
Lösning: Detta händer vanligtvis när det finns en tidslucka — kunden betalar omedelbart, men fakturan skapas i Fortnox senare (t.ex. på grund av en synkroniseringsfördröjning eller batchbearbetning). Junipeer använder följande datumprioriteringsordning när betalningsdatum bestäms:
Betalningsleverantörens datum (högsta prioritet)
Beställningsdatum
Synkroniseringsdatum (lägsta prioritet)
Om detta fel uppstår ofta, kontrollera om din schemaläggning körs tillräckligt ofta för att hålla fakturagenereringen nära orderplaceringen. Du kan också behöva justera logiken för betalningsdatum i samråd med Junipeer support.
FORTNOX_SHIPPING_NOT_FOUND
Allvarlighetsgrad: FelMeddelande: "Kunde inte hämta/hitta leveranssätt" (Could not retrieve/find shipping method)
Orsak: En leveransmetod som tidigare var konfigurerad i Fortnox har tagits bort eller inaktiverats, men refereras fortfarande på en kundpost. Detta är ett känt Fortnox-beteende — att ta bort en leveransmetod rensar inte upp befintliga referenser till den.
Lösning: I Fortnox, hitta den berörda kundposten och uppdatera eller ta bort leveransmetodreferensen. Alternativt kan du återskapa den borttagna leveransmetoden i Fortnox. Verifiera även dina leveransmetodmappningar i Junipeer under Configure > Settings > Shipping Methods för att säkerställa att alla aktiva e-handelsfrakt-metoder är mappade.
FORTNOX_VAT_NOT_FOUND
Allvarlighetsgrad: FelMeddelande: "Kunde inte hämta/hitta moms" (Could not retrieve/find VAT)
Orsak: Momssatsen på den inkommande ordern är inte konfigurerad i Fortnox. Som standard har Fortnox endast 25%, 12% och 6% (svenska standardsatser).
Lösning: I Fortnox, gå till Inställningar → Bokföring → Moms (VAT) och skapa den saknade momssatsen. Om du säljer över gränser inom EU kan du behöva lägga till momssatser för varje destinationsland (t.ex. 21% för Nederländerna, 19% för Tyskland). SeFortnox Setupguiden för detaljer om OSS försäljningskontouppställning.
Allmänna Felkoder
ERROR_MESSAGE
Allvarlighetsgrad: FelMeddelande: "Error message:" (följt av detaljer)
Orsak: Ett produktnummer, orderfält eller annat datavärde innehåller alltför lång eller felaktigt formaterad text. Detta är ett allmänt datavalideringsfel som uppstår när ett fält överskrider den maximala längd som tillåts av målsystemet.
Lösning: Kontrollera entiteten som refereras i felet (synlig iLoggar). Leta efter ovanligt långa produktnamn, SKU-nummer eller anpassade fältvärden som kan överskrida målsystemets fältlängdsgränser. Förkorta värdet i källplattformen och försök synka igen.
Ytterligare Felmönster
Följande fel är inte listade som formella felkoder i kunskapsdatabasen men förekommer ofta i verkliga supportärenden.
"Invalid grant"
System: Fortnox, Visma.net (OAuth-baserade kopplingar)Allvarlighetsgrad: Kritiskt
Orsak: OAuth-token för en koppling har gått ut eller återkallats. Alla synkroniseringar stannar tills anslutningen återupprättas.
Lösning: Gå tillConnectors, koppla från den berörda kopplingen och återanslut genom att auktorisera på nytt via OAuth-flödet. Om problemet återkommer ofta, kontrollera om policyn för tokenupplöpning har ändrats på plattformssidan.
"Customer ID not found"
System: Fortnox, Business Central, Visma.net (alla ERP-destinationer)Allvarlighetsgrad: Fel
Orsak: En order refererar till en kund som inte finns i mål-ERP:et. Detta kan hända när kundsynkronisering inte är aktiverat eller när en kund skapades i e-handelsplattformen efter att den senaste kundsynkroniseringen kördes.
Lösning: Säkerställ att kundsynkroniseringsflödet är aktiverat och har körts nyligen. Du kan också manuellt utlösa en Export One för den saknade kunden och sedan försöka ordersynkroniseringen igen. Om kunden redan finns i ERP:et under ett annat ID, kontrolleraReferensersidan.
"Cash account not found"
System: Fortnox, Visma.net (ERP-destination)Allvarlighetsgrad: Fel
Orsak: En betalningsmetod är kopplad till ett kassakonto i ERP:et som Junipeer inte kan lösa, även om det visas i kontolistan. Detta kan inträffa när ERP:ets API returnerar konton som inte är fullt aktiverade eller konfigurerade.
Lösning: Försök att koppla till ett annat kassakonto för att bekräfta att synkroniseringen fungerar, undersök sedan det ursprungliga kontot i ERP:et. Kontot kan behöva aktiveras helt eller dess API-synlighetsinställningar kan behöva justeras. Kontakta Junipeer support om problemet kvarstår.
"Could not json-decode visma error response"
System: Visma.net (ERP)Allvarlighetsgrad: Fel
Orsak: Visma.net returnerade ett felsvar som Junipeer inte kunde tolka. Detta indikerar vanligtvis en oväntad API-ändring eller ett problem på serversidan hos Visma.net.
Lösning: Försök synkronisera igen. Om felet kvarstår, kontrollera om Visma.net upplever avbrott eller har släppt en API-uppdatering. Kontakta Junipeer support med uppgifts-ID:t för undersökning.
"Order with ID X not found"
System: Shopify, Centra, Magento, Norce (e-handelsplattformar som källa)Allvarlighetsgrad: Fel
Orsak: Junipeer försöker läsa in en order från e-handelsplattformen, men ordern finns inte eller är inte tillgänglig. Detta kan hända om en order raderades, arkiverades, eller om API-uppgifterna saknar åtkomst till den specifika orderomfattningen.
Lösning: Verifiera att ordern finns i källplattformen och är tillgänglig via API:et. Om ordern raderades kan den inte synkroniseras. Om den finns men Junipeer inte kan hitta den, kontrollera API-behörigheter och omfattning.
"Could not identify the size in the product attributes"
System: Business Central / Trimit (ERP) → Centra (e-handel)Allvarlighetsgrad: Fel
Orsak: Vid synkronisering av produkter kan Junipeer inte matcha en produkts storleksattribut med den konfigurerade storlekstabellen. Storleksvärdet i källsystemet motsvarar inte någon post i den mappade storlekstabellen.
Lösning: Kontrollera produktens storleksattribut i källsystemet och verifiera att det matchar storlekstabellmappningen i Junipers artikelinställningar. Om en ny storlekstabell skapades kan den behöva läggas till i mappningskonfigurationen.
Cachad data förhindrar återsynkronisering
System: Alla plattformar (Junipeer internt)Allvarlighetsgrad: Info
Orsak: En post korrigerades i källplattformen (t.ex. ett felaktigt postnummer fixades), men Junipeer har fortfarande den gamla, cachade versionen och fortsätter att misslyckas.
Lösning: Använd knappenClear Cachepå sidanConfigure > Settingsför att tvinga Junipeer att hämta färsk data från källplattformen. Försök sedan med den misslyckade uppgiften igen.
Ordrar saknas från synkronisering utan fel
System: Alla e-handelsplattformar (källa)Allvarlighetsgrad: Varning
Orsak: Vissa beställningar kanske inte visas alls i Junipeer — ingen uppgift, ingen loggpost, inget fel. Det här kan hända när beställningen faller utanför: Tidshistorik: -fönstret eller beställningens exkluderingsdatum, eller om det var ett kort anslutningsavbrott under en schemalagd synk.
Lösning: Kontrollera sidan Tidshistorik för att bekräfta att "senast laddad"-datumet täcker den saknade beställningens skapandedatum. Om datumintervallet ser korrekt ut, utlös manuellt en Export One för den specifika beställningen från sidan: Flows: . Om beställningen fortfarande inte visas, kontakta Junipeer support med beställnings-ID:t.
: Token upphör att gälla
System: Alla OAuth-baserade kopplingar (Fortnox, Visma.net, Shopify, Business Central)Allvarlighetsgrad: Kritiskt
Orsak: API-tokens eller OAuth-anslutningar kan upphöra över tid. När detta händer misslyckas alla synkroniseringar för den kopplingen samtidigt.
Lösning: Återanslut den berörda kopplingen på sidanConnectors: . För att förhindra oväntade avbrott, övervaka plötsliga toppar i stoppade uppgifter på: Dashboard: — ett hopp från nära noll till alla-misslyckas är en stark indikator på en utgången token.
: Dubbletter av SKU:er orsakar felaktig lagersynkronisering
System: Centra (källa), valfri ERP (destination)Allvarlighetsgrad: Fel
Orsak: I Centra kan en enskild SKU associeras med flera produkter — till exempel om produkter dupliceras över säsonger eller kollektioner. När Junipeer frågar efter lager per SKU och får flera resultat, kan det synkronisera lager från fel produkt (inaktiv eller annullerad) istället för den aktiva.
Lösning: Se till att varje SKU är unik för en enskild aktiv produkt i Centra. Om dubbletter av SKU:er finns på grund av säsongskollektioner, inaktivera eller annullera de gamla produktposterna i Centra. Junipeer prioriterar aktiva produkter när de finns tillgängliga, men tvetydiga SKU-mappningar kan fortfarande orsaka problem. Kontakta Junipeer support om du behöver anpassad SKU-upplösningslogik.
: "Loaded 0 Articles" — produkten hittades inte i ERP
System: Business Central, Visma.net (käll-ERP → e-handelsdestination)Allvarlighetsgrad: Fel
Orsak: När man försöker synkronisera en produkt laddar Junipeer noll artiklar från ERP:en. Produkten kanske inte finns, kan vara opublicerad, eller kan sakna obligatoriska fält som förhindrar att den returneras av API:et.
Lösning: Verifiera att produkten finns i ERP:en och har alla obligatoriska fält ifyllda. I Visma.net, kontrollera att artikeln har ett namn — felet "The Product Name attribute value is empty" indikerar ett saknat namnfält. I Business Central, verifiera att produkten är publicerad och tillgänglig via integrations-API-slutpunkten.
: "Too many requests" — hastighetsbegränsning vid stora synkroniseringar
System: Centra, Brightpearl, och andra plattformar med strikta API-hastighetsgränserAllvarlighetsgrad: Fel
Orsak: Synkroniseringar med stora volymer (t.ex. en fullständig lagersynk med tusentals SKU:er) överskrider målplattformens API-hastighetsgränser. Uppgiften slutförs delvis och misslyckas sedan med hastighetsbegränsningsfel.
Lösning: Minska synkroniseringsfrekvensen i: Scheduling: — till exempel, ändra från varje minut till var femte minut. För initiala dataladdningar, synkronisera i mindre satser med datumintervall. Om felet kvarstår, kontakta Junipeer support för att justera API-throttling-inställningar.
: Problem med lagersynkronisering för flera lager
System: Business Central / Trimit (ERP) → Centra (e-handel)Allvarlighetsgrad: Fel
Orsak: När flera lager är konfigurerade kan lagersynkronisering rapportera "inga ändringar" även när lagernivåer skiljer sig mellan ERP:en och e-handelsplattformen. Detta inträffar vanligtvis när lagerlokationskoder i Business Central inte är korrekt mappade, eller när standardlagerkonfigurationen inte matchar ERP:ens lagerstruktur.
Lösning: I Junipeer, gå till Configure > Settings och verifiera dina lagermappningar. Se till att varje lager-ID i Business Central är korrekt mappat till motsvarande lager i Centra. Efter att ha justerat mappningar, användClear Cachepå flödesinställningssidan och försök synkronisera lagret igen.
"Kunde inte skapa referens"
System: Junipeer (References-sidan), alla anslutningsparAllvarlighetsgrad: Fel
Orsak: När entitetsreferenser (mappningar av ID mellan system) skapas manuellt på References-sidan misslyckas operationen. Detta kan inträffa om entitets-ID:n inte existerar i ett eller båda anslutna system, eller om det finns en datatypmatchning mellan käll- och mål-ID-formaten.
Lösning: Verifiera att både käll- och mål-ID:n existerar i sina respektive system. Kontrollera att ID:n är i rätt format (vissa system använder numeriska ID:n, andra använder alfanumeriska). Om felet kvarstår, kontakta Junipeer support med de specifika referens-ID:n du försöker skapa.
SAP Business One — problem med orderstatus-identifiering
System: SAP Business One (ERP)Allvarlighetsgrad: Varning
Orsak: SAP Business One:s Service Layer API kan inte alltid tydligt skilja mellan annullerade, stängda och fullföljda ordrar.DocumentStatus: bost_Close-flaggan kan gälla både slutförda och annullerade ordrar, ochCancelled-flaggan kanske inte är satt även när en order annullerades i SAP GUI. Detta kan få Junipeer att misstolka orderstatusar.
Lösning: Kontakta Junipeer support för att verifiera orderstatus-mappningen för din SAP Business One-konfiguration. Teamet kan behöva justera mappningslogiken baserat på din specifika SAP-konfiguration och arbetsflöden.
SAP Business One — lagertidsstämpel uppdateras inte
System: SAP Business One (ERP)Allvarlighetsgrad: Varning
Orsak: ArtikelnsUpdateDate/UpdateTime-fält i SAP Business One uppdateras inte alltid när lagerförändringar sker genom transaktioner som varuinleveranser eller leveranser. Detta gör att Junipers datumbaserade lagersynkronisering missar förändringar.
Lösning: Junipeer har implementerat alternativ lagerförändringsdetektion för SAP Business One som inte förlitar sig på artikeltidsstämplar. Om du upplever missade lageruppdateringar, kontakta support för att säkerställa att du använder den senaste anslutningsversionen med förbättrad lagerspårning.
"Ignorerar order — ingen referens hittad"
System: Business Central / Trimit (ERP) → Centra (e-handel)Allvarlighetsgrad: Fel
Orsak: När Junipeer försöker uppdatera en orders status (t.ex. markera den som skickad), kan den inte hitta den matchande referensen i sin mappningstabell. Detta händer vanligtvis i Business Central by Trimit-integrationer där säljdokument konverteras till säljordrar och sedan bokförs, vilket ändrar deras dokument-ID:n genom processen.
Lösning: KontrolleraReferenser-sidan för att verifiera att ordermappningen existerar. Om referensen saknas kan den behöva skapas manuellt. I komplexa ERP-arbetsflöden där dokument ändrar ID:n genom bearbetningssteg, kontakta Junipeer support för att verifiera referensspårningslogiken.
"Kan inte uppdatera kund i Visma"-fel
System: Visma.net (ERP)Allvarlighetsgrad: Fel
Orsak: När kunddata synkroniseras till Visma.net misslyckas uppdateringen på grund av fältvalideringsfel eller behörighetsbegränsningar i Visma.net API:et.
Lösning: Kontrollera det specifika felmeddelandet iLoggarför detaljer på fältnivå. Vanliga orsaker inkluderar ogiltiga landskoder, saknade obligatoriska fält, eller att kundposten är låst för redigering i Visma.net. Verifiera kunddata i källsystemet och försök igen.
Visma Business — felaktig måttenhet synkroniserad
System: Visma Business (ERP) → e-handelsplattformarAllvarlighetsgrad: Fel
Orsak: Integrationen synkroniserar fel måttenhet från Visma Business — till exempel hämtar "förpackningar" istället för "nystan" för garnprodukter. Detta kan hända när produktens primära måttenhetsområde i Visma Business är konfigurerat annorlunda än förväntat, eller när integrationen läser ett sekundärt måttenhetsområde.
Lösning: Kontrollera produktens måttenhetsrättning i Visma Business. Säkerställ att det primära måttenhetsområdet matchar vad som ska synkroniseras till e-handelsplattformen. Kontakta Junipeer support om integrationen läser fel måttenhetsområde.
Hanteringsmissförhållande för kreditnotas moms
System: Business Central (ERP), Centra (e-handel)Allvarlighetsgrad: Varning
Orsak: Kreditnota-/återbetalningsflödet kanske inte respekterar samma inställning "Moms inkluderad i orderrader" som orderflödet använder. Om order är konfigurerade med momsinkluderande prissättning men kreditnotor inte är det, kan återbetalningsbeloppen vara felaktiga.
Lösning: Kontrollera att kreditnotaflödets inställningar matchar orderflödets inställningar för momshantering. Kontrollera Configure > Settings för kreditnotaflödet och säkerställ att momsinställningarna är konsekventa. Kontakta Junipeer support om inställningen inte är tillgänglig i kreditnotaflödet.
Webhook-signal inte mottagen — manuell utlösarknapp misslyckas
System: Visma.net → nShift (via Junipeer), alla webhook-utlösta flödenAllvarlighetsgrad: Varning
Orsak: Käll-ERP:n har en knapp eller åtgärd (t.ex. "Skicka till nShift" i Visma.net) som utlöser en webhook till Junipeer. Om webhook-signalen inte anländer synkroniseras inte försändelsen. Detta kan hända på grund av tillfälliga Visma.net API-problem, webhook-leveransfel eller att knappen inte är korrekt konfigurerad i ERP:n.
Lösning: Kontrollera förstTaskssidan för att se om en uppgift skapades — om inte, nådde signalen aldrig Junipeer. Som en lösning, användExport Onepå sidan: Flowssidan för att manuellt synkronisera försändelsen. Om webhook-knappen regelbundet misslyckas, kontakta Junipeer support för att undersöka att lägga till webhooks programmatiskt eller växla till ett polling-baserat schema.
Överförsäljning under högvolymförsäljning — eftersläpning i lagersynkronisering
System: Visma.net (lagerstamdata) → Centra (e-handel), alla ERP → e-handel lagersynkAllvarlighetsgrad: Varning
Orsak: Under blixtrean eller händelser med hög trafik (t.ex. 15 order per minut) är standardintervallet på 5 minuter för lagersynkronisering för långsamt. ERP:n har korrekt lager, men när Junipeer synkroniserar det till e-handelsplattformen har redan flera order lagts för artiklar som är slut i lager.
Lösning: Minska tillfälligt synkroniseringsintervallet i: Scheduling— t.ex. från 5 minuter till 1 minut under topperioder. För en mer permanent lösning ger aktivering av webhooks på både ERP- och e-handelssidan lageruppdateringar nästan i realtid. Kontakta Junipeer support för att diskutera webhook-baserad lagersynkronisering om överförsäljning är ett återkommande problem.
OSS momsmappningsbegäran för land — taxZone och taxCategory
System: Centra → Visma.net (ERP), alla OSS-aktiverade flödenAllvarlighetsgrad: Info
Orsak: När handlare börjar rapportera OSS (One Stop Shop) moms behöver de landsspecifika skattezons- och skattekategorimappningar. Till exempel ska en fransk order mappas tilltaxZoneId: FRochtaxCategory: FRi Visma.net. Detta kräver anpassad mappningskonfiguration som kanske inte är tillgänglig i standardinställningarnas användargränssnitt.
Lösning: OSS land-till-skatt-mappning kräver anpassad konfiguration. Kontakta Junipeer support med dina krav. Om möjligt, begär att ändringar distribueras till en QA/testmiljö först innan de går live för att undvika redovisningsstörningar. För Fortnox-integrationer hanteras OSS genom funktionen för försäljningskontosmappning i plattformens användargränssnitt.
Shopify manuella/utkast-order exporteras som betalda istället för obetalda
System: Shopify → FortnoxAllvarlighetsgrad: Fel
Orsak: När handlare skapar manuella eller utkast-order i Shopify för B2B-fakturering kan ordern felaktigt markeras som betalda i Fortnox. Detta händer eftersom standardflödet behandlar alla order som betalda, vilket är korrekt för B2C men fel för manuella order avsedda för fakturabaserade betalningsvillkor (t.ex. 14 eller 30 dagar).
Lösning: Använd Shopify ordertaggar (t.ex.FN14,FN30) för att ange betalningsvillkor, och konfigurera Junipeers regelbyggare för att upptäcka dessa taggar och ställa in lämpliga betalningsvillkor i Fortnox samtidigt som fakturan hålls obetald. Kontakta Junipeer support för hjälp med att konfigurera detta flöde, eftersom det kräver mappningsjusteringar i Transform Fortnox Orders to Invoices endpoint.
Felaktiga utbetalningsreferenser efter aktivering av ny betalningsleverantör
System: Shopify → Fortnox (med Mollie, Qliro eller andra PSP:er)Allvarlighetsgrad: Fel
Orsak: När en ny betalningsleverantör (t.ex. Mollie) aktiveras i Shopify utan att först konfigureras i Junipeer, får historiska utbetalningar felaktiga referenser i Fortnox. Nya beställningar fungerar bra, men utbetalningar som skapades innan konfigurationen lades till innehåller fel referensdata.
Lösning: Konfigurera alltid nya betalningsleverantörer i Junipeerinnandu aktiverar dem i Shopify. Om de redan är aktiverade, kontakta Junipeer support för att korrigera de historiska utbetalningsreferenserna. Framöver kommer Junipeer att mappa den nya leverantören korrekt för alla nya beställningar.
Qliro-utbetalningar synkroniserar inte med Fortnox-fakturor
System: Shopify → Fortnox (Qliro betalningsleverantör)Allvarlighetsgrad: Kritiskt
Orsak: Qliro-betalda fakturor visas som obetalda i Fortnox trots att betalningar samlades in. Utbetalningsavstämningsflödet misslyckas med att matcha Qliro-utbetalningar till motsvarande Fortnox-fakturor, vilket resulterar i hundratals fakturor som verkar vara utestående.
Lösning: Kontrollera Export Payouts to Fortnox-flödet i: Flowsoch verifiera att Qliro-utbetalningskartan är korrekt konfigurerad. Om problemet påverkar ett stort antal fakturor, kontakta Junipeer support — batchkorrigering kan behövas för att avstämma historiska utbetalningar.
Återbetalning saknar rabattrad på kreditfaktura
System: Centra → Fortnox (återbetalnings-/kreditflöde)Allvarlighetsgrad: Fel
Orsak: Vid återbetalning av en beställning som hade en rabatt tillämpad, inkluderar kreditfakturan i Fortnox endast produktraden men inte rabattraden. Detta gör att kreditfakturabeloppet blir högre än det faktiska återbetalningsbeloppet (t.ex. produkt var 2660 SEK minus 880 SEK rabatt = 1730 SEK återbetalning, men kreditfakturan visar 2660 SEK).
Lösning: Kontakta Junipeer support. Återbetalningskartan behöver uppdateras för att inkludera rabatt-/kreditrader tillsammans med produktrader vid generering av kreditfakturor.
Återbetalning skapad som faktura istället för kreditfaktura
System: Svea → Fortnox, alla återbetalningsflödenAllvarlighetsgrad: Kritiskt
Orsak: Återbetalningar från betalningsleverantören skapas som standardfakturor i Fortnox snarare än kreditfakturor, vilket orsakar felaktiga redovisningsposter och momsavvikelser.
Lösning: Kontakta Junipeer support omedelbart. Återbetalnings-till-faktura-kartan måste korrigeras för att använda kreditfaktura-dokumenttypen i Fortnox.
Returavgift behandlad som frakt på kreditfaktura
System: Centra → FortnoxAllvarlighetsgrad: Fel
Orsak: I kreditfakturan kategoriseras en returavgift (t.ex. 39 SEK) felaktigt som "Frakt" istället för "Avgift", vilket gör att den bokförs på fraktkontot (t.ex. 3520) istället för avgiftskontot (t.ex. 3002).
Lösning: Verifiera dina avgiftskonto- och fraktkontokartor i Configure > Settings för återbetalningsflödet. Returavgiftskartan kan behöva justeras — kontakta Junipeer support om avgiften inte mappas till rätt kontokategori.
Återbetalningsutbetalningsbelopp dubblerat (negativt saldo)
System: WooCommerce → Fortnox (Walley betalningsleverantör)Allvarlighetsgrad: Fel
Orsak: Under utbetalningsavstämning tillämpas återbetalningsbeloppet två gånger — en gång som negativ utbetalning och en gång som återbetalningsavdrag — vilket resulterar i ett dubbelt negativt saldo på fakturan i Fortnox.
Lösning: Kontakta Junipeer support med specifika order- och utbetalnings-ID:n. Detta är vanligtvis ett mappningsproblem med hur återbetalningsutbetalningar hanteras för den specifika betalningsleverantören.
"Could not map payout transaction" — flemarknadsvalutamismatch
System: Shopify → Fortnox (flemarknadsbutiker)Allvarlighetsgrad: FelMeddelande: "Could not map payout transaction: Invoice X, Unsupported currency combination"
Orsak: I Shopify-butiker med flera marknader (t.ex. inhemsk SEK + internationell EUR) kan utbetalningar från en marknad innehålla transaktioner i en valuta som inte matchar fakturavalutan i Fortnox. Utbetalningsavstämningen misslyckas eftersom den inte kan matcha transaktioner mellan valutor.
Lösning: Kontakta Junipeer support. Flemarknadsutbetalningsavstämning kräver särskild konfiguration för att hantera valutakonverteringar mellan utbetalningsvaluta och fakturavaluta.
EU omvänd skattskyldighet tillämpas inte — WooCommerce VAT-nummer i metafält
System: WooCommerce → FortnoxAllvarlighetsgrad: Fel
Orsak: B2B-beställningar från EU-kunder debiteras moms istället för att hanteras som omvänd skattskyldighet. Detta händer eftersom WooCommerce inte har ett standardfält för VAT-nummer — numret lagras i ett anpassat metafält via ett plugin, och Junipeer kan inte upptäcka det utan anpassad mappning.
Lösning: Kontakta Junipeer support för att konfigurera anpassad VAT-nummermappning från WooCommerce-metafältet. När det är konfigurerat kommer beställningar med giltigt EU VAT-nummer att klassificeras korrekt som omvänd skattskyldighet i Fortnox.
OSS försäljningskontomappning tillämpas inte på kreditnotor
System: Centra/Shopify → Fortnox (OSS-aktiverad)Allvarlighetsgrad: Fel
Orsak: OSS försäljningskontomappningen fungerar korrekt för fakturor men tillämpas inte på kreditnotor med nya orderrader. Detta innebär att återbetalningar för internationella beställningar kan bokföras på fel försäljningskonto, vilket bryter lands-specifik momsrapportering.
Lösning: Kontakta Junipeer support. Kreditnotaflödet behöver uppdateras för att ärva samma OSS försäljningskontomappningslogik som fakturaflödet. Detta är vanligtvis ett problem med att VATCode eller Project-fälten inte överförs till kreditfakturaraderna.
Schemalagd synkronisering rapporterar framgång men överför 0 poster
System: Magento → Fortnox, vilket schemalagt flöde som helstAllvarlighetsgrad: Varning
Orsak: Den schemalagda synkroniseringen körs och rapporterar status "Completed" med 0 bearbetade poster. Uppgiften lyckas tekniskt (inga fel), men ingen data överförs faktiskt. Detta kan hända när tidsfönsterkursorn fastnar, käll-API:et tyst returnerar tomma resultat, eller en filterkonfiguration utesluter alla poster.
Lösning: Kontrollera: Tidshistoriksidan för att verifiera att synkroniseringsfönstret inte har hoppat förbi tillgänglig data. Kontrollera även flödesfilter för att säkerställa att de inte är för restriktiva. Prova att köra Export Many med ett specifikt datumintervall för att bekräfta att data är tillgänglig. Om problemet kvarstår, kontakta Junipeer support — synkroniseringskursorn kan behöva återställas.
Orderstatusfilter fungerar inte
System: Shopify → Fortnox, vilket flöde som helst med statusfilterAllvarlighetsgrad: Fel
Orsak: Ett flöde konfigurerat för att synkronisera beställningar med specifika statusar (t.ex. FULFILLED) bearbetar inte matchande beställningar. Filtret verkar korrekt konfigurerat i gränssnittet men beställningar hoppas över.
Lösning: Kontrollera filterkonfigurationen på flödesinställningssidan (kugghjulsikon → Source → Filters). Verifiera att statusvärdena matchar exakt (skiftlägeskänsligt). Om filtret ser korrekt ut men beställningar fortfarande hoppas över, använd Export One för att manuellt synkronisera en specifik beställning för att bekräfta problemet. Kontakta Junipeer support om filtret verkar fungera fel.
Visma Business — kundnummertilldelningsfel
System: Centra → Visma Business (ERP)Allvarlighetsgrad: FelMeddelande: "Det var inte mulig å allokere nummer fra den angitte nummerserie" (Kunde inte tilldela nummer från den angivna nummerserien)
Orsak: När en ny kund skapas i Visma Business för en inkommande beställning har nummerserien för kund-ID:n uttömts eller är felkonfigurerad. Visma Business kan inte tilldela ett nytt kundnummer.
Lösning: I Visma Business, kontrollera nummerserieskonfigurationen för kunder. Serien kan behöva utökas eller en ny serie skapas. Detta är ett konfigurationsproblem på ERP-sidan — kontakta din Visma Business-administratör.
Synkronisering stannar efter bearbetning av 700–900 poster
System: WooCommerce → Fortnox, vilket högvolymflöde som helstAllvarlighetsgrad: Fel
Orsak: Under stora batchsynkroniseringar stannar processen efter att ha bearbetat ungefär 700–900 poster utan ett tydligt fel. Detta kan orsakas av minnesbegränsningar, API-pagineringsproblem eller att timeoutgränser nås.
Lösning: Dela upp stora synkroniseringar i mindre batchar med datumintervall via Export Many. Om problemet kvarstår, kontakta Junipeer support för att undersöka potentiella paginations- eller minnesproblem med kopplingen.
NoWaste → Norce leveranssynkronisering JSON-tolkningsfel
System: NoWaste → NorceAllvarlighetsgrad: FelMeddelande: "json: cannot unmarshal number 1.0 into Go struct field PickReportEventBody.body.event_data.NumberOfPallets of type int"
Orsak: NoWaste webhook skickar ett decimaltal (1.0) för fältet NumberOfPallets, men integrationen förväntar sig ett heltal. Denna typmismatch orsakar att JSON-tolkningen misslyckas.
Lösning: Kontakta Junipeer support. Detta är en fix på kopplingsnivå som kräver uppdatering av datatyphanteringen för NoWaste webhook payload.
Dubbletter av fakturor för samma beställning
System: Shopify → Fortnox, alla beställning-till-faktura-flödenAllvarlighetsgrad: Fel
Orsak: Samma beställning faktureras två gånger i Fortnox. Detta kan hända när en webhook utlöses flera gånger för samma händelse, eller när en manuell Export One utlöses för en beställning som redan bearbetats av en schemalagd synkronisering.
Lösning: KontrolleraReferensersidan för att se om dubblettreferenser finns för beställningen. Junipeer förhindrar normalt dubblettbearbetning genom att kontrollera referenser, men undantagsfall (t.ex. timing mellan webhook och schema) kan orsaka dubbletter. Ta bort dubblettfakturan i Fortnox och kontakta Junipeer support om det upprepas.
Avrundnings-/valutaskillnader som lämnar små obetalda belopp
System: Shopify/Centra → Fortnox, alla fakturaflödenAllvarlighetsgrad: Varning
Orsak: På grund av avrundningsskillnader vid valutakonvertering mellan e-handelsplattformen och Fortnox kan fakturor ha små obetalda belopp (t.ex. 0,01 SEK) efter betalningsavstämning. Med tiden ackumuleras dessa till många fakturor som verkar "obetalda" trots att de är fullt insamlade.
Lösning: Junipeer har implementerat avrundningskorrigeringslogik för nya fakturor. För befintliga fakturor med små skillnader, kontakta Junipeer support — batchkorrigering kan vara tillgänglig. I Fortnox kan du också använda "avskrivnings"-funktionen för att rensa små återstående belopp på enskilda fakturor.
Utbetalningsavgift och avskrivningshantering
System: Shopify/Centra → Visma.net (utbetalningsavstämning)Allvarlighetsgrad: Info
Orsak: Vid bearbetning av utbetalningar från betalningsleverantörer (Shopify, Adyen, Mollie, etc.) inkluderar utbetalningsbeloppet transaktionsavgifter som dras av av PSP:n. Dessa avgifter behöver registreras som avskrivningar i ERP:n för att balansera böckerna.
Lösning: Junipeer hanterar utbetalningsavgifter automatiskt genom att registrera nettoutbetalningsbeloppet och avgiften som en balansavskrivning med en konfigurerad avskrivningsorsakkod. Se till attFeeWriteOffReasonCodeinställningen är konfigurerad i din integration. Obs: Adyen tillhandahåller för närvarande inte ett komplett utbetalnings-API, så Adyen utbetalningsavstämning kanske inte är tillgänglig för alla handlare.
Allmän felsökning
Anslutningsproblem
Om uppgifter misslyckas med anslutnings- eller timeout-fel:
KontrolleraConnectorssidan — visar båda kopplingarna "Connected" (grön)?
Om en koppling visar frånkopplad kan API-referenserna ha gått ut eller återkallats. Återanslut med nya referenser.
Tillfälliga nätverksproblem mellan Junipeer och målplattformen kan orsaka isolerade fel. Dessa löser sig vanligtvis vid nästa schemalagda synkronisering — kontrollera om uppgiften lyckas vid nytt försök.
Hastighetsbegränsning
Synkroniseringar med hög volym (t.ex. genom att använda Export Many med tusentals poster) kan utlösa hastighetsgränser på målplattformens API. Symptom inkluderar timeout-fel eller ofullständig synkronisering.
Lösning: Fördela stora synkroniseringar genom att justeraschemaläggningsintervall. För initiala historiska dataladdningar, överväg att synkronisera i mindre datumintervall med hjälp av: Tidshistorik.
Datavalideringsfel
När en order eller produkt misslyckas med validering i målsystemet, indikerar felmeddelandet vanligtvis vilket fält som är problemet. Vanliga orsaker:
Saknat obligatoriskt fält (kundnamn, artikelnummer, valuta)
Fältvärdet överskrider maximal längd
Enum-värde inte igenkänt (t.ex. omappad frakt- eller betalningsmetod)
Datum i ogiltigt intervall (räkenskapsår inte konfigurerat, betalningsdatum före fakturadatum)
För alla valideringsfel är mönstret detsamma: identifiera det problematiska fältet från felmeddelandet, åtgärda det i källsystemet eller konfigurera rätt mappning i JunipeersInställningar, och försök igen med uppgiften.
Tips
När du undersöker ett fel, börja medLoggar-sidan och filtrera efter referensnumret för den misslyckade posten. Detta visar hela felkedjan för den specifika entiteten.
De flesta fel kan lösas genom att åtgärda konfigurationen och försöka igen med uppgiften — du behöver sällan utlösa hela synkroniseringen igen.
Om samma felkod visas på många uppgifter samtidigt, indikerar det vanligtvis ett konfigurationsproblem (saknad valuta, saknad momssats) snarare än ett problem med enskilda poster. Åtgärda konfigurationen en gång och försök igen med alla misslyckade uppgifter.
Fel på svenska (t.ex. "Kunde inte hämta/hitta...") kommer från Fortnox API och vidarebefordras av Junipeer. Felkodsreferensen påErrors-sidaninnehåller översättningar och lösningar för dessa.