Swedish to English: SES001 Interface BasWare v1.1
General field: Tech/Engineering
Detailed field: IT (Information Technology) | |
Source text - Swedish
Kontering av preliminära omkostnadsfakturor
Pseudokontot under motkontering för preliminära dokumenttyper för omkostnadsfakturor tas bort. Detta innebär att ingen kostnadskontering genereras av Enterprise.
Alla preliminära omkostnadsfakturor i IP skapas med konteringar. BasWare kompletterar tabellen för preliminära fakturor med fält för konteringar motsvarande som finns idag för definitiva fakturor.
Följande information läggs till i tabellen för prel
Kontering motsvarande POSTING_DIMENSIONS i tabellen för definitiva fakturor
Belopp i transaktionsvaluta motsvarande POSTING_AMOUNT i tabellen för definitiva fakturor
Belopp i systemvaluta motsvarande POSTING_AMOUNT_SEK i tabellen för definitiva fakturor
Momskontering motsvarande ENTRY_CODE (nytt) i tabellen för definitiva fakuror
Radnr motsvarande POSTING_ROW_NO
För transaktioner med V (momskonteringar) krävs dessutom att nedanstående fält uppdateras. Denna information finns inte i IP utan skapas vid inläsning till Enterprise.
Momshanteringskod: Hämtas från leverantören
Vid inläsning av preliminära fakturor till Enterprise kontrolleras fältet pseudokonto för motkontering på dokumenttypen för preliminär faktura. Är fältet blankt ska konteringar från IP uppdateras till Enterprise. Konteringarna loggas även i Enterprise för att kunna bokas bort vid definitiv kontering.
Vid inläsning av definitiva fakturor skapas konteringar som tidigare i IP. I och med att motkonteringen inte skapas med automatik vid inläsning av preliminära fakturor och att definitiva bokningen innehåller samtliga konteringar måste de konteringar som skapades vid preliminär registrering vändas bort.
Detta görs vid inläsning till Enterprise genom att kontrollera om det finns konteringar för motsvarande faktura i nya loggfilen som uppdateras vid inläsning av preliminära fakturor. Dessa konteringar uppdateras till Enterprise, med vänt tecken.
Kontering av prisdifferens
Det finns två typer av prisdifferenser, accepterad och ej accepterad prisdifferens. Endast den accepterade prisdifferensen ska påverka ACRA. För ej accepterade prisdifferenser förväntas en kreditfaktura från leverantören.
Accepterad prisdifferens
För accepterade prisdifferenser skickas med en acceptera flagga, 1=accepterad, i fältet INVOICE_DIFF_STATUS.
Dessa prisdifferenser ska hanteras som tidigare, med skillnaden att konteringen skapas i Enterprise. Prisdifferenser för returer skapas av BasWare på motsvarande sätt.
Ex) Definitiv kontering från BasWare i nuvarande lösning.
Konto Beskrivning Belopp Prisdifferens
2470 Inleverans 1418,11 0,11
1775 Prisdifferens 0,11
2470 Inleverans -0,11
I nuvarande lösning skapar IP konteringar för differenser. I detta exempel på konto 1775 och 2470.
Skapande av differenskonteringen tas bort från IP i den nya versionen och skapas i stället vid inläsning till Enterprise. Är det en accepterad differens (INVOICE_DIFF_STATUS = 1) och det finns en prisdifferens konteras differensen på 1775 med motkonto samma som konto på raden där prisdifferensen anges. I detta exempel 2470.
I nuvarande lösning innehåller fältet INVOICE_DIFF_STATUS = 1 för konteringar som avser differenser och tas inte med vid uppdatering av matchningsinfo och ACRA. Förändring görs så att transaktioner med INVOICE_DIFF_STATUS = 1, dvs accepterad prisdifferens, hanteras vid uppdatering av matchningsino och ACRA.
Ej accepterad prisdifferens
För ej accepterade prisdifferenser skickas en ej acceptera flagga, 0=ej accepterad, i fältet INVOICE_DIFF_STATUS.
Denna typ av prisdifferens hanteras på ett annat sätt än accepterad prisdifferens. Differenskonteringen skapas i Enterprise genom att flytta in orderbeloppet ORDER_AMOUNT som belopp på konteringen för inleverans. Prisdifferensen läggs som egen kontering mot konto 1684.
Konto Beskrivning Belopp Prisdifferens
2470 Inleverans 1418 (orderbel) 0,11
1684 Fordran hos leverantör 0,11
ACRA ska INTE uppdateras för ej accepterad prisdifferens. För att lösa detta uppdateras arbetsfilen för matchning (Z2OINVMAT) med nya fältet INVOICE_DIFF_STATUS. Uppdatering av ACRA sker endast om INVOICE_DIFF_STATUS = 1, accepterad prisdifferens.
Matchningsfilerna uppdateras som tidigare.
Valutakod i leverantörsregistret
Leverantörsinformationen som skickas till BasWare kompletteras med leverantörens valutakod.
Valutakoden läggs i fältet CURRENCY_CODE.
| Translation - English
Coding of preliminary invoices for expenses
The pseudo account under the title “Counter coding” is removed in the preliminary document types page for invoices for expenses. This means that no expense coding is generated by Enterprise.
All preliminary invoices for expenses in the IP are produced with codes. BasWare supplements the table for preliminary invoices with the code field that corresponds to the existing definitive invoices.
The following information is added to the table for preliminary invoices for expenses
Coding equivalent to POSTING_DIMENSIONS in the table for definitive invoices
Amount in the transaction currency equivalent to POSTING_AMOUNT in the table for definitive invoices
Amount in the system currency equivalent to POSTING_AMOUNT_SEK in the table for definitive invoices
VAT coding equivalent to ENTRY_CODE (new) in the table for definitive invoices
Row number equivalent to POSTING_ROW_NO
In addition, for transactions with ”V” (VAT codes) it is required that the fields below are updated. This information does not exist in the IP but is produced during reading into Enterprise.
VAT management code: Collected from the supplier
During reading of preliminary invoices into Enterprise, the field “Pseudo account” under the section “Counter coding” on the page “Document types” for preliminary invoices is checked. If the field is blank the code from the IP should be updated in Enterprise. The codes are also logged in Enterprise in order for them to be able to be cancelled during definitive coding.
During reading of definitive invoices, codes are produced as previously in the IP. As a result of the fact that the counter coding is not produced automatically during reading of preliminary invoices and also that the final booking contains all the codes, the coding that was produced at the preliminary registration must be rejected.
This is done during reading into Enterprise through checking whether there is coding for the corresponding invoice in the new log file which is updated during reading of preliminary invoices.
Coding of the price differential
There are two different types of price differentials, accepted and unaccepted price differentials. Only the accepted price differential should affect ACRA. A credit invoice is expected from the supplier for the unaccepted price differentials.
Accepted price differentials
The accepted price differentials are sent with an “accepted flag” (1 = accepted) in the field INVOICE_DIFF_STATUS.
These price differentials must be managed as previously with the difference that the coding is created in Enterprise.
Example) The definitive coding from BasWare in the present solution.
Account Description Amount Price differential
2470 Delivery 1418.11 0.11
1775 Price differential 0.11
2470 Delivery -0.11
In the present solution the IP creates codes for the differentials; in the above example on account 1775 and 2470. Production of differential coding is removed from the IP in the new version and occurs instead during reading into Enterprise. If it is an accepted differential (INVOICE_DIFF_STATUS = 1) and there is a price differential, the differential is coded on account 1775 with a contra account similar to the account where the price differential is specified; in the above example 2470.
In the present solution the field contains INVOICE_DIFF_STATUS = 1 for codes that are meant for differentials and is not included during updated of matching information and ACRA. A change is made so that transactions with INVOICE_DIFF_STATUS = 1, that is accepted price differentials are managed during updating of matching information and ACRA.
Unaccepted price differentials
The unaccepted price differentials are sent with an “unaccepted flag” (1 = unaccepted) in the field INVOICE_DIFF_STATUS.
This type of price differential is managed in a different way to the accepted price differential. The differential coding is created in Enterprise by transferring in the order amount ORDER_AMOUNT as an amount for the coding.
Account Description Amount Price differential
2470 Delivery 1418 (order amount) 0.11
1684 Demand at the supplier 0.11
ACRA should NOT be updated for unaccepted price differentials. To solve this, the active file for the matching (Z2OINVMAT) is updated with the new field INVOICE_DIFF_STATUS. Updating of ACRA only occurs if INVOICE_DIFF_STATUS = 1 (accepted price differential).
The matching files are updated as previously.
Currency code in the supplier register
The supplier information sent to BasWare is supplemented with the supplier’s currency code. The currency code is added to the field CURRENCY_CODE.
|
Portfolio