Tryton in Romania

Hello Everyone,

I intend to begin preparing for implementing tryton for my company in Romania.
I will start with translation.

Perhaps this post can serve to unite tryton users who want to localize tryton for use in Romania.

4 Likes

Hello,

First of all: Welcome to our comunity and thanks for starting a new translations.
We are from on Spain an I know some bussiness that operate in both Spain and Romania. So in a future we may benefit for your effort.

In order to implement Tryton for a company you will probably need a chart of accounts, that sets all the accounting values. You can configure it yourself by creating the proper values or develop a module that set ups the values as templates. A discussion has been started recently to setup the chart of accounts for Italy, so I will recomend you to read it.

1 Like

Hi !I am a rumanian jr developer living in Spain. I have just joined a small team here and i’ll start learning more about Tryton, starting wednesday 14 jul… I would like to help also with translations to rumanian language as much as i can, and also, in further developments with localization for Rumania.

1 Like

Hello Daniel,
welcome to our community and thank you to volunteer for helping with the romanian translation. Best is to talk directly with @dotbit.
Best regards Udo

1 Like

Hello @daniel_dev,

Welcome and good luck.

I run a company for which I would like to incrementally move other systems over to tryton.
What I find is that it is very important to know what your requirements are and that I learn better when trying to connect Tryton to the real world.

Regarding Romanian translations, I think you can create an account on translate.tryton.org and start contributing, I will check.

Regarding other localizations:
I have added the following line between the other Romanian identifiers:
(‘ro_j’, “Romanian J Number”),
The J number is one of the two obligatory company identifiers that have to appear on an invoice for ex. So I added the ro_j code. I do not know how correct this is and I don’t know how these identifiers are validated

Also as a resident but not citizen of Romania I have an unusual ro_cnp code which does not validate if I try to create this identifyer for the party representing me. My cnp looks like this: 786xxxxxxxxxx with x representing numbers.

1 Like

Are you sure it is not the ro_cf? According to this site the VAT number is the only required identifier.

It will be good to report it to python-stdnum.

Understood.

This means that once again it is with python-stdnum that I should submit these changes incl. justifying documentation/laws, and after they are submitted, then party.py should be updated according to the new python-stdnum data. Please do confirm if I am understanding this correctly.

I have been discussing this with my accountant and these are our conclusions:

Are you sure it is not the ro_cf ? According to this site the VAT number is the only required identifier.

It is my understanding that this is true if you are a european company selling to a romanian company. However if a romanian company is selling to another romanian company the following law has a list of things that must appear on the invoice:


(Romanian). Art 74 contains the list.
(1) În orice factură, ofertă, comandă, tarif, prospect şi alte documente întrebuinţate în comerţ, emanând de la o societate, trebuie să se menţioneze denumirea, forma juridică, sediul social, numărul din registrul comerţului şi codul unic de înregistrare. Sunt exceptate bonurile fiscale emise de aparatele de marcat electronice, care vor cuprinde elementele prevăzute de legislaţia din domeniu.

“numărul din registrul comerţului” -> the number from the commerce register.
This code has the format of (J|F)[0-9]{1,2}/[0-9]{1,5}/[0-9]{4}, for ex. J52/750/2012.
Also the EUID unique european identification code is based on this identifier.

Codul unic de inregistrare is ro_cf.

To conclude: For a Romanian company to invoice another romanian company the following identifiers for both company emitting and benecifiary on the invoice:

  1. numărul din registrul comerţului" -> the number from the commerce register.
  2. codul unic de înregistrare (also known as codul fiscal, or cf) -> ro_cf. In case this code has a RO infront of it the company is collecting and paying VAT, if not then not collecting VAT, thus the company also does not have an European VAT number.

Sorry for the long intricate message.
I would be very happy is we manage to make it possible for tryton to be compliant for use in romania in an as general fashion as possible.

PS: As the ‘J’ (Juridical entity) number can also start with an F (physical person) i think a more correct name would be ‘ro_onrc’, but I will check further.

Thanks!

Yes, we delegate on python-stdnum the validation of codes. So you should first add the code there.

Once added you should fill an issue to tryton to include the new code and add it as tax_identifier if really required.

I guess this means that it is similar to Belgium where the commerce number (“numéro d’entreprise”) is indeed the VAT number without the ‘0’ prefix. So displaying always VAT number on the invoice is enough because the later can be deduced.
If it is not enough and it should really be displayed, I guess the best would be to add in python-stdnum a method that returns the commerce number from the CF code. This way it could be used in the template.

Regarding EUID: this is something else, sorry for mixing too many different things in the same message.

My company for example has the following identifiers:
ro_cui (missing from stdnum, proposed code): 16281620
ro_cf (VAT code, in stdnum): RO16281620
ro_onrc (missing from stdnum, proposed code): J52/750/2012

ro_cf: this is the vat code for the company. in case a company has this code, this one should be used, else the ro_cui should be used.
My problem is (rare) what one should do in case a company is registered, but is not registered for VAT and thus does not have a ro_cf. In this case they should be identified by the ro_cui code, on which the ro_cf code is based by adding RO in the beginning.
To be it seems like one bit of entropy needs to be removed. Either you store two codes, or you store a boolean if the company is registered for VAT or not.

@ced, how do you solve this problem in Belgium?
What is Belgian Enterprise Number, which is in the list of stdnum identifiers? It is my understanding that this is the company code, on which the VAT number is based.
In this case do you derive the VAT code from this, or do you use European VAT number for the vat code?
How do you specify which companies collect/pay VAT?

The second identifier (ro_onrc) that must be on an invoice is completely separate, it is not based on ro_cf or ro_cui. I have proposed it be added to stdnum and will get back when it is done.

What is the point of such identification for company not registered for VAT?
For example, the Foundation is a Belgian company not registered for VAT. It has a commerce number (which is like the VAT number but without the BE0) but we never have to give it to any company to get an invoice. This is because it fully pays the VAT so it is like a personal customer.

You store only VAT number because it is the only number that matters for invoice.

What is the point of such identification for company not registered for VAT?

In romania you are only obligated to apply for VAT after you have a turnover > ~61000 EUR. This means that smaller companies can chose to not register for VAT, and it is still obligatory to invoice them with the company code.

There are declarations that have to be made each month that need to contain the company code, that is if you wish to use Tryton as your fiscal accounting system.

I checked this with a friend who works in a corporation, and in SAP they store company code, vat code and onrc code for romanian companies.

I will take care of the ro_onrc code first with stdnum, then I will get back to this issue.

@pokoli, perhaps if you, or someone else knows a romanian company wanting to use or is using tryton perhaps they could help with this issue.