A Appendix

The following section list the information required to generate a receipt, digital certificate, E-Journal and X and Y Report for submission to the Norwegian Tax Authority.

Receipt Layout Modification

The Norwegian Tax Authority requires that the receipts contains the following information.

Sales Receipt Requirements

The table below describes the requirement for the Sales Receipts.

Table A-1 Sales Receipt Requirements

Mandatory Element on Sales Receipt Comments

Document Number and Date

Consecutive number of document (Sales Receipt) and date of the document.

Parties involved

Information about document (Sales Receipt) Issuer and Receiver.

Issuer data must contain the name, address, and organization number (from The Brønnøysund Register Centre (Brønnøysundregistrene) of the enterprise.

If the issuer is registered with the VAT Register, the organization name shall follow the following convention: the letters “MVA”+registration number.

Receiver data must contain identification data.

Date and place of delivery

When and where services were delivered.

Sale nature and scope

Services that have been delivered.

Specification of taxable and tax-free sales

Taxable and tax-free sales and the sales exempted from VAT shall be listed and added separately. The same applies if taxable turnover tax is calculated at different rates.

Identification of Cash Register

The ID number of the Cash Register System (UWID). It must be a unique identifier that represents the PC Workstation that prints the receipt, it must not be changeable and preferably a combination of letters and numbers. It must be unique to each business location (ship) and within the company's organization (fleet). It must also be unique in the case of Workstation replacement.

(suggestion UWID -> XCET_FC_ID + WORKSTATION ID)

Indication that document is a Sales receipt (Salskvittering)

The word 'Salskvittering' must appear at the top of the receipt and are twice as big as the “change due” entry on the receipt.

It is not permitted to replace the upper case letters with a lower case.

The font of the text must be at least 50% larger than the text of the amount shown.

Indication that Sales receipt is in electronic form (Elektronisk Salskvittering)

If the sales receipt is produced in electronic form, the words "Elektronisk salskvittering" (Electronic sales receipt) must be displayed.

Digital Signature

Each receipt must be electronically signed. The signature shall sign specific data from each receipt and recorded in the Electronic Journal upon finalization of each transaction. Electronic signature of the Sales Receipt must not be printed but it must be stored in the Electronic Journal.

Return Receipt Requirements

The layout of Return Receipt is similar to Sales Receipt except the following:

Table A-2 Return Receipts Requirement

Mandatory Element on Return Receipt Comments

Indication that document is a Return Sales receipt (Returkvittering)

The word 'Returkvittering' must appear at the top of the receipt in letters as big as the “change due” entry on the receipt.

It is not permitted to replace the upper case letters with a lower case.

The font of the text must be at least 50% larger than the text that of the amounts shown.

Proforma Receipt Requirements

The layout of the Pro-Forma Receipt is similar to Sales Receipt except for the following:

Table A-3 Proforma Receipt Requirement

Mandatory Element on Proforma Receipts Comments
Indication that document is a Pro forma receipt (Foreløpig kvittering)

Phrase 'Foreløpig kvittering – IKKE KVITTERING FOR KJØP' must appear at the top of the receipt in letters twice as big as the “change due” entry on the receipt.

It is not permitted to replace the upper case letters with a lower case.

The font of the text must be at least 50% larger than the text of the amount shown.

Delivery Receipt Requirements

The layout of the Delivery Receipts is similar to Sales Receipt, except for the following

Table A-4 Delivery Receipt Requirement

Mandatory Element on Delivery Receipts Comments
Indication that document is a Delivery receipt (Utleveringskvittering)

Phrase 'Utleveringskvittering – IKKJE KVITTERING FOR KJØP' must appear at the top of the receipt and in letters twice as big as the “change due” entry on the receipt.

It is not permitted to replace the upper case letters with a lower case.

The font of the text must be at least 50% larger than the text that shows the amounts.

Digital Certificate Requirement

To implement digital signature cryptographic functions, a key pair of a private key and a public key is required. The key pair is stored in a digital certificate form. The Norwegian Tax Authority requires that the digital certificate format to be as shown below.

  • Format: x.509

  • Charset: UTF-8

  • Encoding: Base-64

  • Endianness: Little Endian

  • OAEP Padding: PKCS1 v1.5 padding

  • Private key size: 1024 bits

  • Hash Message Format: SHA-1

Digital Signature

Digital signature in our context here is the asymmetrically encrypted hash of the Transaction Data. Briefly, the digital signature is defined as:

<Transactiondatahash> = Sha-1(<Transactiondata>)
<Digitalsignature> = Rsa-1024(<Transactiondatahash >) Using The Private Key

Signing and Verification Process

Figure A-1 Signing and Verification Process


This figure shows the signing and verification process of digital certificate.

Figure A-2 Sample Signed and Verified Certificate


This figure shows the sample signed and verified certificate.

Digital Signature Trail

To preserve the integrity of transactions, the Norwegian Tax Authority mandates that the digital signing process should be chained, as shown below where the signature trail that SPMS would apply appears for its digital signing function.

  • Cruise Line Company A

    • Ship AA

      • TransactionAA1

        • SignatureAA1

      • TransactionAA2

        • SignatureAA2 (from SignatureAA1)

      • TransactionAA3

        • SignatureAA3 (from SignatureAA2)

    • Ship AB

      • TransactionAB1

        • SignatureAB1

      • TransactionAB2

        • SignatureAB2 (from SignatureAB1)

      • TransactionAB3

        • SignatureAB3 (from SignatureAB2)

  • Cruise Line Company B

    • Ship BA

      • TransactionBA1

        • SignatureBA1

      • TransactionBA2

        • SignatureBA2 (from SignatureBA1)

      • TransactionBA3

        • SignatureBA3 (from SignatureBA2)

    • Ship BB

      • TransactionBB1

        • SignatureBB1

      • TransactionBB2

        • SignatureBB2 (from SignatureBB1)

      • TransactionBB3

        • SignatureBB3 (from SignatureBB2)

Verifying Digital Signature

Table A-5 Digital Certificate Elements and Descriptions

Element in SAF-T Cash Register Description Format and requirements Examples

signature (previous)

Signature from previous receipt

Base-64 If no previous receipt the signature value must be set to “0” – number zero

signature_from_previous_receipt

transDate

Date at which the transaction was performed.

YYYY-MM-DD Do NOT use time zone or combined date and time format.

2014-01-24 2015-10-29

transTime

Time at which the transaction was performed.

hh:mm:ss Use ss=00 as default value if no information of seconds are available. Same as within the SAF-T export. Do NOT use time zone or combined date and time format.

23:59:59

nr

Transaction number.

This must be a unique, sequential number within a journal.

This will be the same as the number stated on the issued receipt

No leading or ending spaces.

123456789

transAmntIn

The amount involved in the transaction, including VAT.

Decimal Data Type: Numerical field with two decimals. Decimal separator “.” (dot). No thousand separators. No leading or ending spaces.

1250.00 -1250.00 0.00

transAmntEx

The amount involved in the transaction, excluding VAT.

Decimal Data Type:

1000.00 -1000.00

signature (current)

Signature of current receipt

Base-64
If no previous receipt the signature value must be set to “0” – number zero

  
Below are the steps to verify the digital signature.

  1. Get Transaction Data from e-journal xml file.

  2. Ensure that you have the public key in PEM format. You need this to verify the signature.

  3. Save the transaction data in message.txt file.

  4. Save the signature in signature.txt file.

  5. Go to Windows search and type “git bash” to start the command line tool.

  6. Extract the public key from the certificate.

    $ openssl x509 -pubkey -noout -in <certificate_name> > pubkey.pem

  7. Now, decode the base64 encoded signature and store it in “<signature_name>.txt” file.

    $ cat signature.txt| base64 -d > <signature_name>.txt

  8. Finally, verify the signature.

    $ openssl dgst -<name> -verify pubkey.pem -signature <signature_name>.txt message.txt

E-Journal Report Structure

This following tables list the report header for standard report, company report and company by location and cashier register.

Report <header> Structure

Table A-6 Report Header Structure

Element Descriptions

<fiscalYear>

Current year of From Date.

<startDate>

First day in current year of From Date.

<endDate>

Last day in current year of To Date.

<curCode>

Current currency code setup in SPMS.

<dateCreated>

Current database date.

<timeCreated>

Current database time.

<softwareDesc>

Current software to generate E-Journal report.

<softwareVersion>

Current software version.

<softwareCompanyName>

Current company setup in SPMS

<auditfileVersion>

The XML version number to be displayed in E-Journal Report.

<userID>

Login user who generates E-Journal Report.

Report<company>Structure

Table A-7 Company Report Header Structure

Element Descriptions

<companyName>

Get from Name under Company Entities Setup in OHC Administration.

<taxRegIdent>

Get from VAT registration number under Company Entities Setup in OHC Administration.

<customersSuppliers>

Customer details. Only customer who exists in the receipt period being selected from user interface.

<vatCodeDetails>

<standardVatCode>

All VAT configuration details are using in SPMS.

Standard VAT Code stated in norwegian-saf-t-standard-vat-codes.pdf. More details in section Standard Predefined Code 99 – Standard VAT Codes.

<periods>

<periodNumber>

Period number of the defined period. Period number is generated by sequence CNT_EJOURNAL_RUNNO from database.

<employees>

Employee who generate the receipt and trigger the event (refer to <event> node). Only employee who exists in the receipts period is selectable from user interface.

<articles>

Department and main department details. Only department and main department that exist in the receipts period is selectable from user interface.

<basics>

Main department ID for credit and debit department, and transaction code. With the mapping standard predefined code. See section Standard Predefined Code 04 — Article Group/Department Codesfor more information.

Report <company><location><cashregister> Structure

<registerID>

Company ID in Company Entities Setup in OHC Administration, combine with my computer name.

<regDesc>

Name in Company Entities Setup in OHC Administration.

<event>

Log record from LOG table. Only records that exist in the date period being selected from user interface.

<cashtransaction>

One <cashtransaction> per one receipt. Only receipts that exist in the receipts period being selected from user interface.

<nr>

Receipt number.

<transID>

Receipt number.

<transType>

Receipt type:

  • SALES

  • RETURN

  • PROFORMA

  • DELIVERY

Refers to section Standard Predefined Code 11 – Transaction Codes

<transAmntIn>

Total receipt amount including VAT tax.

<TransAmntEx>

Total receipt amount excluding VAT tax.

<amntTp>

An increase in revenue (such as sales) is to be marked as C.

While a decrease in revenue (such as returns) is to be marked as D.

<empID>

User who generates receipt.

<custSupID>

Customer account number.

<periodNumber>

Refer to <periods> in above table.

<transDate>

Receipt creation date.

<transTime>

Receipt creation time.

<invoiceID>

Delivery receipt number.

<rounding>

Rounding to 2 decimal places.

<signature>

Digital signature of receipt.

<keyVersion>

The version of the private/secret key.

<voidTransaction>

True = Void transaction

False = No

<vat>

VAT details of all transactions within each receipt.

<payment>

Payment details of receipt.

<ctLine>

All transactions of the receipt. Record is retrieved from POS table.

<nr>

Receipt number. Link to root <nr>.

<lineID>

POS_ID of the POS record.

<lineType>

Transaction type of the POS record.

  • POST

  • SALES

  • REFUND

  • DIS

  • VOID

Refers to section 2.4 Standard Predefined Code 11 – Transaction Codes.

<artGroupID>

Main department ID of the POS record.

<artID>

Department ID of the POS record.

<qnt>

Quantity of the POS record.

<lineAmntIn>

Amount of the POS record including VAT tax.

<lineAmntEx>

Amount of the POS record excluding VAT tax.

<amntTp>

An increase in revenue (such as sales) is to be marked as C.

While a decrease in revenue (such as returns) is to be marked as D.

<empID>

User who process this record.

<lineDate>

POS record creation date.

<lineTime>

POS record creation time.

<vat>

VAT details of the POS record.

<discount>

Discount details of the POS record

X and Z Report Structure

X Report

An X Report must contain the following information at the very least:

  • An inscription that the report is an X report.

  • The name and organization number of the enterprise.

  • The date and time.

  • The ID number of the Cash Register System (UWID). It must be a unique identifier that represents the PC Workstation that prints the report, it must not be changeable and preferably a combination of letters and numbers. It must be unique on each business location (ship) and within the company's organization (fleet). It must also be unique in case of Workstation replacement.

  • Total cash sales

  • The number of cash sales and amounts broken down by different means of payment

  • The number of cash sales and amounts broken down by different means of payment for each individual operator (user)

  • The number of tips and amount

  • Sales subject to value added tax and sales free from value added tax, as well as value added tax subdivided into different value added tax rates

  • Opening change float

  • The number of Sales receipts

  • The number of Copy receipts and amount (currently not applicable for OHC SPMS)

  • The number of Pro forma receipts and amount

  • The number of returns and amount

  • The number of discounts and amount

  • Number of Delivery receipts and amount

  • Grand total sales

  • Grand total returns (voids)

  • Grand total net

Z Report

A Z Report must contain at least the same amount of information as X Report except of the following:

  • An inscription that the report is a Z report.

  • A Z Report number that represents a unique counter that is increased every time it is run. This means that a Z Report must not have the same number as an earlier Z Report.

  • A Z Report must not contain transactions that have been included in an earlier Z Report.