Different language versions of invoicing documents - differents series & document stacks?

[f109...@trbvm.com]

Hi everyone,

I am currently on the search for an ERP that suits the needs of our company and have a question about tryton concerning invoicing documents.

Background Information:

1. Our company wants to be able to issue invoicing documents (and all documents belonging to this, e.g. offers, delivery slip, invoice, credit memo) in DIFFERENT LANGUAGES, in dependency of the language/ country of the recipient of the invoices.
2. Our local laws demand that all invoicing documents are in the local language and they can contain all information ADDITIONALLY in a foreign language
   
3. The local language is non-latin letters, the foreign languages are latin and non-latin
4. The local laws allow to have multiple "series" of invoicing documents, e.g. series A invoices, series B invoices, etc., each having it's own and totally separated numbering and "document stack"
   

What solutions would comply with our local laws:

Our local laws would allow us to do two alternatives:

1. We could have only 1 series and change language from document to document, e.g.:
1. Series A - Invoice No. 0001 = English
   
2. Series A - invoice No. 0002 = English
3. Series A - invoice No. 0003 = Russian
4. Series A - invoice No. 0004 = Chinese
5. Series A - invoice No. 0005 = English
6. etc.
2. We could have different series, with each series being an isolated language stack with it's own numbering, e.g.
1. Series A - Invoice No. 0001 = English
2. Series B - invoice No. 0001 = Russian
3. Series B - invoice No. 0002 = Russian
4. Series C - invoice No. 0001 = Chinese
5. Series B - invoice No. 0003 = Russian
6. Series A - invoice No. 0002 = English

Questions:

1. Would both alternatives be supported by Tryton?
2. If both alternatives would be possible:
1. Which would be the preferred solution considering:
1. complexity of the configuration
2. flexibility
3. usability
4. manageability
   
5. extendability?
2. In the case of solution 2 (different series): Would each series have it's complete own stack of documents (offer, delivery slip, invoice, credit memo)?

Thank you very much for any feedback, help, hint!!

Best regards

Anton

[Carlos Antonio Ruiz Gomez]

Hi Anton, maybe you're lost in these forums.

Tryton is a fork of odoo (formerly openerp formerly tinyerp)

iDempiere is from a different family (adempiere / compiere / openbravo / openxpertya / libertya)

Regards,

Carlos Ruiz



El 15/03/15 a las 19:17, f109...@trbvm.com escribió:

[f109...@trbvm.com]

Hi Carlos,

sorry, I meant of course iDempiere, not Tryton. I had initially posted my question at the Tryton forum and forgot to exchange the name for this forum, but the questions are the same for iDempiere.
So please when reading my posting, everywhere where you read Tryton, please read iDempiere instead :-)

Thank you
Anton

[redhuan d. oon]

OK answers to Tritonpiere in between: :)

On Monday, 16 March 2015 07:17:17 UTC+7, f109...@trbvm.com wrote:

Hi everyone,

I am currently on the search for an ERP that suits the needs of our company and have a question about tryton concerning invoicing documents.

Background Information:

1. Our company wants to be able to issue invoicing documents (and all documents belonging to this, e.g. offers, delivery slip, invoice, credit memo) in DIFFERENT LANGUAGES, in dependency of the language/ country of the recipient of the invoices.
2. Our local laws demand that all invoicing documents are in the local language and they can contain all information ADDITIONALLY in a foreign language
   
3. The local language is non-latin letters, the foreign languages are latin and non-latin
4. The local laws allow to have multiple "series" of invoicing documents, e.g. series A invoices, series B invoices, etc., each having it's own and totally separated numbering and "document stack"
   

In our family of *Piere projects we refer to documents as DocTypes, i.e. Orders, Invoices, Payments..

What solutions would comply with our local laws:

Our local laws would allow us to do two alternatives:

1. We could have only 1 series and change language from document to document, e.g.:
1. Series A - Invoice No. 0001 = English
   
2. Series A - invoice No. 0002 = English
3. Series A - invoice No. 0003 = Russian
4. Series A - invoice No. 0004 = Chinese
5. Series A - invoice No. 0005 = English
6. etc.
2. We could have different series, with each series being an isolated language stack with it's own numbering, e.g.
1. Series A - Invoice No. 0001 = English
2. Series B - invoice No. 0001 = Russian
3. Series B - invoice No. 0002 = Russian
4. Series C - invoice No. 0001 = Chinese
5. Series B - invoice No. 0003 = Russian
6. Series A - invoice No. 0002 = English

Questions:

1. Would both alternatives be supported by Tryton?

Been Open Source, it is open to setting, code Callouts, configuring, etc. You have to specifically describe a sample case in full flow before one can give an approximate suggested solution or options. Others who can understand or have similar cases as above can answer better as i have never encountered such a case before.

1. If both alternatives would be possible:

I can only answer in general until a specific case is asked in detail.

1. Which would be the preferred solution considering:
1. complexity of the configuration
2. flexibility
3. usability
4. manageability
   
5. extendability? 
   

Since you are considering Odoo's too, a general guideline is this:
1. IDempiere use Java and thus allow for more complex and IBM-centric financial systems (meaning heavy very complex use)
Thus Odoo type using Python are for more simpler cases
2. iDempiere has many features that maybe unwanted and it is a challenge to understand first before deciding not to use it or reuse/map it to a more suitable user requirement case.
Thus the learning curve is more steeper with iDempiere what more the plugin framework before actually using it meaningfully. If Odoo type is suitable then iDempiere is overkill.

1. In the case of solution 2 (different series): Would each series have it's complete own stack of documents (offer, delivery slip, invoice, credit memo)?

The DocTypes are already standard and cover the docs you mentioned here. They have associated Doc Sequence numbering schemes. You can extend with more DocTypes based on the same original DocBaseTypes but with more different sequencing schemas.
Howver much DocType handling is hardcoded in Model java classes and this is my worry that a lot of research is needed when a particular feature becomes a bug in your specific business requirement. Then a good expert developer is needed to make a workaround or overloading of the class via a plugin.