Under konteringsregler sätter man upp ett regelverk som definierar hur olika transaktioner skall konteras. Kontering i Extend Commerce Backend urskiljer sig från andra bokföringssystem i att man inte sätter bokföringsregler på själva produkten om huruvida den skall bokföras utan man skapar ett regelverk i form av en matris.
På detta sätt kan en produkt konteras mot olika konton beroende på olika typer av händelser.
Det finns en mängd olika händelser som först aktiveras i admingränssnittet och sedan visas upp som ett alternativ under konteringshändelser.
Konteringshändelserna sätts vid uppstart upp av Extend Commerce där vi möjliggör skapandet av konteringsreglerna.
Denna sida är rättighetsstyrd och kräver att du som användare har rollen "Financial manager".
Regelverk & Kontering
För varje vald händelse skapas en matris som utgör vad som kan hända vid en transaktion. Här är prioriteringsordningen extremt viktigt.
Ordningen utgör en stegvis kontroll där systemet testar varje rad enskilt i prioritetsordning tills transaktionens uppgifter överensstämmer med villkoren angivna på en rad. När systemet får en träff på en rad kommer systemet avsluta sin sökning och kontera till de konton som är uppsatta på den raden som systemet får träff på. Systemet kommer ej söka på samtliga rader, utan enbart tills systemet får träff. Prioritetsordningen för raderna är därför essentiell för att regelverket skall fungera korrekt.
Exempel
Generas exempelvis en faktura så heter händelsen 'CustomerInvoice'. Systemet kommer då kolla första raden i prioritetsordningen och se om transaktionen matchar de villkor som är definierade på raden. I detta exempel så kommer systemet först kolla om fakturan har generats för en försäljning i Sverige, om detta stämmer kommer systemet få träff på raden och kontera mot de konton som är uppsatta på raden. Är det inte försäljning i Sverige kommer systemet gå vidare till nästa rad tills den får träff och kommer kontera mot de konton angivna för den raden.
Raden för land skall anges i format enligt ISO 3166 Alpha-2, (2 bokstäver för varje land). Dessa finnes här: https://sv.wikipedia.org/wiki/ISO_3166#ISO_3166-1-koder
Sammanfattning
- Transaktionens innehåll matchas mot villkoren för varje enskild rad i prioritetsordning.
- Varje enskilt villkor på en rad måste exakt stämma överens med transaktionens innehåll för att systemet skall ge träff för den raden. Samtliga angivna villkor för raden måste alltså matcha för att transaktionen skall konteras enligt raden.
- Systemet kommer enbart söka träff på angivna villkorsfält. Lämnas ett villkorsfält blankt så komme systemet inte söka träff för det villkoret utan automatiskt godkänna alla värden gällande det villkoret.
Konton & Konteringsutfall
Systemet konterar samtliga transaktioner. Detta betyder att för varje transaktion skrivs det ner flera olika kontonummer som är angivna på den rad systemet får träff på. Dessa konton används i samband med att det skapas konteringsutfall. Varje transaktion i systemet stämplas med flera kontonummer: debit, kredit, moms, punktskatt.
Grundprincipen för konteringsreglerna beskrivas nedan.
Exempel: Försäljning har skett mot en Norsk kund och vi vill nu bokföra frakten till Norge på ett annan konto.
Konteringsevent,
Följande bokförings / konterings event finns i Extend Commerce Backend.
De olika eventen behöver aktiveras för att synas. Detta görs normalt sett vid grunduppsättning av er installation. Saknar ni något event så kontakta supporten för hjälp
| Event / händelse | Beskrivning | Typ/exempel på konto Debet | Typ/exempel på konto Kredit |
|---|---|---|---|
| Kundfaktura | Bokföring av utställda (skickade) fakturor. Här finns det flera olika typer av fakturor, som oftast har lite olika konteringsregler. Det kan handla om Fritextfakturor (utan att några varor plockats) Kreditfakturor Vanliga kundfakturor OBS Det är inte ovanligt att Extend Commerce backend skickar över fakturor till ett redovisningssystem, och att konteringsregler för kundfakturor sker i det systemet. I sådana fall aktiveras inte detta event i Extend Commerce | Kundfodran | Försäljning |
| Intag | Värdet av mottagna varor på lager, som sker kopplat till en inköpsorder. | Lager | Förväntad leverantörsskuld |
| Korrigering intag | En rättning av ett intag, detta event bör sättas upp på samma sätt som intagseventet. | Lager | Förväntad leverantörsskuld |
| Automatic product cost change | Ett event som bokför skillnaden mellan befintligt lagervärde och det nya omräknade vid intag på lager från ett inköp. skillnaden i lagervärde kan beror på ändrade inköpspriser, valutakurser etc. Detta event skall i normalfallet sättas upp identiskt med eventet intag. | Lager | Förväntad leverantörsskuld |
| Manuellt intag | Ett intag av produkter på lager som sker utan att det är gjort någon inköpsorder. | Lager | Utredningskonto? eller förväntad leverantörsskuld |
| Uttag | Uttag bokför värdet av produkterna vid ett uttag från lager via en av följande transaktioner
Konteringsreglerna sätts normalt sett upp olika beroende på vilken transaktionstyp det är. Äger man lagret som man flyttar produkterna till ? osv. det finns många olika variabler som påverkar hur detta skall konteras. | Kostnad sålda varor | Lager |
| Retur | Retur eventet bokför värdet av produkterna som kommer tillbaks till lager via en returtransaktion. bokföringen av ev. kredit till kund pga av retur sker genom kundfaktura eventet. | Lager | Kostnad sålda varor |
| Inköp | Värdet av inköp för direktleverans, vid tidpunkt för skapandet av inköpet. | Kostnad sålda varor | Förväntad leverantörsskuld |
| Orderleverans av inköp | Värdet av inköp vid direktleverans, vid tidpunkten när inköpet markeras såsom levererat. Om detta event skall användas eller om man använder det som heter inköp (ovan), eller om man skall använda bägge beror helt på vilken bokföring och process man vill uppnå. Hur reglerna skall / kan sättas upp beror mycket på vilken process man skall ha. | Kostnad sålda varor | Förväntad leverantörsskuld |
| Manual product cost change | En manuell justering av lagervärdet på en enskild artikel. Detta event innehåller det totala förändrade lagervärdet för produkten. Exempel: Produkt A saldo 100 st lagervärde per st = 5 kr totalt lagervärde = 500 Justering görs så att produktens värde blir 4 kr /st totala lagervärdet beräknas då till 400 kr. Detta event kommer då att bokföra 100 kr i manual product cost change. | kostnad sålda varor | Lagerkonto (vid sänkning av lagervärdet, annars tvärt om) |
| Olika typningar av saldojusteringar från lagret | Exempel på debet / kredit för dessa justeringar som kommer nedan är exempel då lagervärdet sänks pga av eventet. Om lagervärdet istället höjs, så kommer Extend Commerce s regelverk att hantera det automatiskt och kontera tvärt emot som om det sänks. | ||
| Inventering | Konterar förändringen av lagervärdet som görs pga av en formell inventering | Lagerjustering (kostnad sålda varor) | Lagerkonto |
| Saldojustering | Konterar förändringen av lagervärdet som görs genom att lagret har rapporterat ett nytt saldo på en vara, orsak okänd, det har bara justerats. Skillnaden mellan detta event och Inventering är hur detta har initierats på lagret. | Lagerjustering (kostnad sålda varor) | Lagerkonto |
Skrotning | En saldojustering som typats av lagret såsom en skrotning | Lagerjustering (kostnad sålda varor) | Lagerkonto |
| Intern Skada | En saldojustering som typats av lagret såsom en internt skadad vara | Lagerjustering (kostnad sålda varor) | Lagerkonto |
| Blockering | På lagret kan man blockera produkter, detta event möjliggör att i bokföringen hantera värdet av blockerade produkter på separata konton. Detta event hanterar både blockering och avblockering | Lagerkonto, blockerade varor | Lagerkonto |
| På denna sida: |
|---|
| Instruktioner & Handledning: |
| Relaterade uppslag: |