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:
- numărul din registrul comerţului" → the number from the commerce register.
- 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.
Regarding accounting: chart of account template:
account.account.template model I use the official Romanian chart of accounts, no problems. Of course, each has a specific usage, which I presume is configured by the account’s type.
However regarding types (account.account.type.template), I have some doubts, namely:
There seems to be no official list of account types in Romania, other than Asset, Liability, Bi-functional (?). This is what my accountant said. But this does not configure things like Stock, Payable, etc.
Any advice about how I should go about figuring out what the types should be?
The account type is used to construct different reporting like the balance sheet, the income statement etc. So they must be based on those reports.
In account documentation the following:
‘and has a set of properties that indicate what any Accounts of this type can be used for.’
This seems to indicate that the account type will also be used to filter the accounts that are possible to select for different operations (ex invoicing, purchasing, receiving money in a bank account, etc).
What I would like to do is to have a starting point, and logically i should create the account types template before creating the accounts template, but maybe the more logical way is to create the accounts template, and then create the proper types template.
Yes, that sounds right, these are the properties like Assets, Receivable, Payable, Expense, etc. And these do influence where these accounts can be used, so for example only accounts that have an account type that is marked as Expense can be set as the Account Expense in a product’s category.
You need to get a balance sheet and income statement from an accountant. The lines on these reports will then become the account types, and how the numbers from the different lines add up will define the structure (parents / children) each account type should have.
Thank you Cedric and Dave. I will post here if I need more help.
1 Like
The Romanian account plan is quite similar to the French one so I will be using it as a reference when I am unsure about what attributes the Romanian corresponding accounts should have, of course together with my accountant.
It is my understand that party_required = True should only be set when it is obligatory for a party to be associated.
Question 1: My accountant tells me that there are two accounts (405 and 413) which can be associated with a party, but it is not obligatory. For these accounts should the party_required attribute be omitted?
These two accounts are the same in the Romanian and French account plans.
Question 2: Can a party be associated even if party_required is omitted?
No, we enforce that a party is set when party is required and we do not allow to set a party when the party_required is not set.
From the french chart I see this accounts are related to “Suppliers” and “Customers”. For me it makes completly sense to set this party as party_required. Normally this accounts are used on invoices, so the invoice module will be responsible of setting the party of this accounts.
If you want to have a move related to an unknow party you can always create an empty party on Tryton (even without name) and use this as party for the customer debts. Having said that I think it’s better to always identify the customer so Tryton will be able to compute the debt of each customer but also the debt of all customers.
Understood, thank you Sergi.