Getting started

Invoice, UBL - Integrators Manual

Important notice

mojeRačun has discontinued support for API V1 on January 1st, 2021 This means that we will not update API V1 with new features from that date on. API will continue to work, but we strongly suggest that you migrate to API V2 to enable new features for your customers.

Intellectual property statement

The content of www.moj-eracun.hr and info.moj-eracun.hr web sites, in their entirety and partially, has been protected by copyright and other intellectual property rights. The company Elektronički računi d.o.o. OIB: 42889250808, is the sole holder of all rights to use the content of the websites and the know-how acknowledged and transferred by its content. Without the explicit written approval granted by the right holder, it is not allowed to reproduce, transfer, distribute or amend neither the content of this website, nor the know-how acknowledged and transferred, nor to use it in any other way or by any other mean.

Goals

Your main goals are to enable users to follow operations via your ERP system:

Send documents, properly formatted and wrapped in XML with enabled attachments
Receive documents (importing data from XML document)
Monitor statuses of sent invoices
Enable resend and cancel actions with outgoing and reject action on incoming invoices

Registration

mojeRačun functionalities presume that the user is registered, so if he hasn't passed the registration process, it is necessary for an application to redirect him to our page https://www.moj-eracun.hr/hr/Account/Register where he can go through the process using a web browser and familiarize himself with details and further steps. After he successfully passes the registration process, he should be able to input his credentials into your application. User identity is defined through 4 fields:

Api V1

ID - User credential username
Pass - User credential password
OIB - Sender CompanyID
PJ – Sender Company Business Unit

Api V2

Username - Login number
Password - Login password
CompanyId - Sender Business Number, aka Oib or VatId
CompanyBu – Sender Business Unit

All of these four data are interpreted as textual data. Users may run multiple companies under the same account and vice-versa so a "many-to-many" relationship should be considered. The business unit field should remain empty if a user doesn't require one or he doesn't know what that is. A business unit can be described as a store or dislocated area that one company owns or where it conducts some business activities.

Invoice

Invoice is an XML representation of invoice data.

Invoice xsd schemes and namespaces

Invoice implements UBL-2.1 schemes and namespaces.

DOWNLOAD SCHEMES, NAMESPACES AND EXAMPLE DOCUMENTS

Invoice parsed nodes

Parsed nodes are mandatory nodes, that moj-eracun.hr service will extract from the posted documents and use to properly address document.

Invoice ID: Invoice/ID
Supplier CompanyID (Oib, VatId or similar): Invoice/AccountingSupplierParty/Party/PartyLegalEntity/CompanyID
Supplier Company BusinessUnit: Invoice/AccountingSupplierParty/Party/PartyIdentification/ID
Customer CompanyID (Oib, VatId or similar): Invoice/AccountingCustomerParty/Party/PartyLegalEntity/CompanyID
Customer Company BusinessUnit: Invoice/AccountingCustomerParty/Party/PartyIdentification/ID
Customer Business Contact Email: Invoice/AccountingCustomerParty/AccountingContact/ElectronicMail
Attached document: AttachedDocument/Attachment/EmbeddedDocumentBinaryObject

Invoice parsed nodes example

<cbc:companyid>69715301002</cbc:companyid>
</cac:partylegalentity>

<cac:partyidentification>
<cbc:id>Business unit 1</cbc:id>
</cac:partyidentification>
</cac:party>
</cac:accountingsupplierparty>
<cac:accountingcustomerparty>
<cac:party>
<cac:partylegalentity>

<cbc:companyid>01234554321</cbc:companyid>
</cac:partylegalentity>

<cac:partyidentification>
<cbc:id>podružnica Ilok</cbc:id>
</cac:partyidentification>
</cac:party>
<cac:accountingcontact>

<cbc:electronicmail>test@gmail.com;test2@gmail.com;test3@gmail.com</cbc:electronicmail>
</cac:accountingcontact>
</cac:accountingcustomerparty>
</invoice>
</invoiceenvelope>
<attacheddocumentenvelope>
<attacheddocument>
<cbc:parentdocumentid>15-01-91</cbc:parentdocumentid>
<cac:attachment>

<cbc:embeddeddocumentbinaryobject mimecode="application/pdf" filename="Invoice-15-01-91.pdf">
JVBER...==
</cbc:embeddeddocumentbinaryobject>
</cac:attachment>
</attacheddocument>
</attacheddocumentenvelope>

</outgoinginvoice>

</outgoinginvoicesdata>

Guidelines for implementation

These guidelines contain some of the most common questions which could appear during the integration process.

DOWNLOAD PDF DOCUMENT WITH FULL GUIDELINES (CROATIAN)

Make sure to fill as much data as possible in the XML document
Make sure that you validate your XML document before testing
Make sure that you enable sending eDocuments to multiple e-mail addresses (see XML node structure lower)
Make sure that you enable sending multiple attachments

Multiple e-mails - XML node structure

Multiple e-mail addressess should be put in the customers Accounting Contact data:

<cac:AccountingContact>

<cbc:Name>Accounting Contact Name</cbc:Name>
<cbc:ElectronicMail>mail1@mail.com;mail2@mail.com</cbc:ElectronicMail>

</cac:AccountingContact>

European Norm (EN) compliance

In March 2017, CEN issued the EU norm for electronic invoices which are exchanged with public entities. This norm implemented some differences in comparison to the current data model used by Moj-eRačun and other service providers in Croatia.
Therefore we have begun to implement these changes to our system to enable our users to exchange eInvoices with public entities. Our service will be fully compliant with the EU norm, and the Croatian legislation in time.
To implement these differences, we had to do some modifications to our system. These modifications are described in the following guidelines:

DOWNLOAD GUIDELINES (ENGLISH)

These Guidelines contain XSD schemes for EN compliant eInovices, an XML example and a PDF file with textual guidelines. In order to ensure that all of our partners will be able to exchange EN compliant eInvoices, we have decided to develop a converter that will convert the current standard which our users use to the EN compliant format. Therefore, the process of exchange of eInvoices will look like this:

We hope that this picture, together with the Guidelines will give you all the necessary information on the implementation of EN compliant eInvoices. If you have any questions, feel free to contact us.

EN Extensions

This document defines the mojeRačun extension of EU norm HRN EN 16931-1:2017 and its UBL 2.1 mapping EN 16931-3.2:2017. The goal of defining an extension of EN 16931-1:2017 is to define additional business terms required to adequately support electronic invoicing legal requirements in Croatia (from other laws besides VAT), further automate electronic invoice processing and payment and better integration with other business documents exchanged in the supply and financial value chains. The document contains the definition of business terms that consist the extensions, extensions of business terms and required controlled vocabularies (code lists) The definition of business terms follows the structure defined by the semantic model of EN 16931-1:2017 in which every business term is described by an ID, term name, description, content model and cardinality.

UBL Validation

You can validate Your XML document on this link

Demo environment

mojeRačun service provides a demo environment to its partners for testing purposes. The demo environment can be accessed via this link

If a partner wants to use our demo environment, he should be registered so make sure you have your username and password before you begin testing.

Contact us

If you have any questions, feel free to contact us:

Technical Support - Croatia
Technical Support - Serbia