different Invoice types with same Invoice ID range -> Chilean case

[Gabriel Oberreuter]

Hi all,

I have the following requirement and if any of you guys can help me think about this I would really appreciate it.

In Chile we have different kinds of Invoices, as expected. Now Chile is migrating to a electronic system, were all documents must be generated in XML form, signed with a ssl certificate and sent to the tax authority after the issue of those documents. The transition to this electronic system nation-wide has been kind of smooth, with its problems but I think it is a great thing.

Well, to the point: I need to manage the following types of documents, all issued from:
- Sales Invoices
- Sales Invoices without tax
- Credit Notes (must be related to a document already issued, be it type 1, 2 or 4)
- Debit Notes (must be related to a document already issued, be it type 1, 2 or 3)

The thing here is that all types of invoices have different id ranges for the tax authority: we can have a Credit Note with ID=1 and a Sales Invoices with ID=1, for example.

In Ofbiz we have:
- SALES_INVOICE, which maps perfectly to type 1 Chilean way
- CUST_RTN_INVOICE, which could be used for Credit Notes Chilean way

I can think of writing new types, something like SALES_INVOICE_NO_TAX and DEBIT_NOTE or similar. But I need to define a way to handle the IDs issue. I really want to use the ids of the entities, and not implement a new custom_type or a new code to each document.

So, my questions:
1) How would you do it? I am thinking of adding the INVOICE_TYPE to the Invoice Entity key, so now the id of Invoice is composed of (id,type) instead of only being (id). This would allow to have different ID ranges for different types of invoices, but I would have to check and probably change lots of ofbiz code to make it work this way.
2) how are usually Debit Notes handled in Ofbiz?

Any suggestion or idea is welcome,
Gabriel

[taher]

Hi Gabriel,

I'm trying to help out with your question and a few inquiries come to mind:


    * What are the types 1, 2, 3 and 4? what do they mean?
    * Who decides what the sequence of invoices is and how is it generated? under which examples would you have identical credit and debit IDs?
    * Why do you want the sequence to be in the ID and not in any other placeholder? For example, why not just another field to add to the invoice entity, or add it as an invoice attribute?
    * Why do you need to distinguish between an invoice without tax and a regular invoice? Why not just create a report for invoices that have a tax invoice item versus those that do not?
    * What is the difference between an invoice and debit/credit notes?

Taher Alkhateeb

----- Original Message -----

From: "Gabriel Oberreuter" <[hidden email]>
To: [hidden email]
Sent: Monday, 28 September, 2015 2:33:46 AM
Subject: different Invoice types with same Invoice ID range -> Chilean case

Hi all,

I have the following requirement and if any of you guys can help me think
about this I would really appreciate it.

In Chile we have different kinds of Invoices, as expected. Now Chile is
migrating to a electronic system, were all documents must be generated in
XML form, signed with a ssl certificate and sent to the tax authority after
the issue of those documents. The transition to this electronic system
nation-wide has been kind of smooth, with its problems but I think it is a
great thing.

Well, to the point: I need to manage the following types of documents, all
issued from:
- Sales Invoices
- Sales Invoices without tax
- Credit Notes (must be related to a document already issued, be it type 1,
2 or 4)
- Debit Notes (must be related to a document already issued, be it type 1, 2
or 3)

The thing here is that all types of invoices have different id ranges for
the tax authority: we can have a Credit Note with ID=1 and a Sales Invoices
with ID=1, for example.

In Ofbiz we have:
- SALES_INVOICE, which maps perfectly to type 1 Chilean way
- CUST_RTN_INVOICE, which could be used for Credit Notes Chilean way

I can think of writing new types, something like SALES_INVOICE_NO_TAX and
DEBIT_NOTE or similar. But I need to define a way to handle the IDs issue. I
really want to use the ids of the entities, and not implement a new
custom_type or a new code to each document.

So, my questions:
1) How would you do it? I am thinking of adding the INVOICE_TYPE to the
Invoice Entity key, so now the id of Invoice is composed of (id,type)
instead of only being (id). This would allow to have different ID ranges for
different types of invoices, but I would have to check and probably change
lots of ofbiz code to make it work this way.
2) how are usually Debit Notes handled in Ofbiz?

Any suggestion or idea is welcome,
Gabriel



--
View this message in context: http://ofbiz.135035.n4.nabble.com/different-Invoice-types-with-same-Invoice-ID-range-Chilean-case-tp4672808.html 
Sent from the OFBiz - User mailing list archive at Nabble.com.

[Gabriel Oberreuter]

Hi Taher,

* What are the types 1, 2, 3 and 4? what do they mean?
In fact, the types are as follows:
33) Electronic Sales Invoice
34) Electronic Sales Invoice without tax
56) Electronic Debit Note
61) Electronic Credit Note

These types were defined by Chilean Tax Authority, Servicios de Impuestos Internos (SII). This means that when submitting the documents to SII we have to use those types.

Who decides what the sequence of invoices is and how is it generated? under which examples would you have identical credit and debit IDs?
SII decided that each type of document has its own sequence of IDs. When a company wants to issue any of these documents, first a request for IDs must be made to SII. SII then generated the IDs you can use. For example, a company just starting business can ask SII for the following ranges:
type 33, range 1-1000
type 34, range 1-1000
type 56, range 1-1000
type 61, range 1-1000

That means that the issued documents must use those IDs, and only those. And of course each ID for each type can be used only once. When submitting the documents to SII they validate this. Each issued document can be validated at SII webpage: the issuer or its client or any other person on hold of that document can enter its values at SII webpage and the SII informs if it is a valid document, that the issuer company sent to them. If you run out of IDs, new requests must be generated.
There is no relation between the IDs beforehand: I can have an Invoice with ID=1 issued to Client 1, then Invoice ID=2 to Client2, and then issue a Debit/Credit Note ID=1 to the Client 1 referencing Invoice ID=1.

Why do you want the sequence to be in the ID and not in any other placeholder? For example, why not just another field to add to the invoice entity, or add it as an invoice attribute?
I don't want to use a new field in Invoice entity, for the simple purpose that in Chile the invoice number is really important. So all the lookups, the references (Debit/Credit notes MUST reference a previously issued document) and the reporting must be based on these IDs. If we implement a new field for this purporse, we will have the extra work of modifying and implementing everything in accounting aroung this new field. I strongly believe that this is a solution, but not the easiest one. That's why I want to use the inherent ID of the Invoice entity. But it is still not decided, that's why I am asking here for feedback ;)

Why do you need to distinguish between an invoice without tax and a regular invoice? Why not just create a report for invoices that have a tax invoice item versus those that do not?
SII decided to implement it this way: all Chilean companies works like this. If an Invoice is issued, and the Invoice has items which do not pay taxes, it must be of type 34 (Electronic Invoice with no taxes...). Put it simple, its the law.

What is the difference between an invoice and debit/credit notes?
Credit Note is a document were you reference an Invoice and issue a credit to the same client. For example, for an item that was never shipped, or a service that did not conclude well and the client ask for a discount, or just an error in the Invoice. As the Invoice are electronic and synchronized with SII, it can not be just modified: it must be modified through a Credit Note, or a Debit Note (in case instead of a discount, more charges apply).

As you can see, all this is regulated by SII. And sadly for us, it is not in the way Ofbiz was coded, or as in other countries these documents are regulated. In the other hand, everything is well documented, and I really like that now all is electronic and synchronized with SII. Other latinamerican countries are following our example. Hope to have cleared your questions!

[taher]

Hi Gabriel,

Thank you for your explanation below. I think there is definitely a need for some customization to reach your goal. With that being said, I list below some of my thoughts on the subject:

First It seems to me that the central entity you need to work with is InvoiceItem not Invoice where you can use the invoiceItemSeqId which OFBiz allows the user to override. This way you can link multiple documents together such as a sales invoice with a debit note for a discount or whatever.

Next regardless of the entity you choose to work with, you are stuck between two issues, either you choose to modify the ID bank sequencing code in some places or you choose to change the search-screens, listing-screens and reports to be based on a custom field that you create which holds the government's sequence number.

I do not think that generating a custom sequence ID would entail "lots of ofbiz code" as you said though. The code you need to worry about is really just the services. So you need an if condition in the service implementation for the createInvoice or createInvoiceItem that changes the sequence number based on the type e.g. InvoiceType or InvoiceItemType.

Also on the other hand, creating a new field would not make it less "important". You can enforce it with id-ne and some other enforcements on the widgets that create an invoice (not too many).

These are my thoughts for now, I hope that helps or someone else with more insight can jump in to this thread.

Regards,

Taher Alkhateeb.

----- Original Message -----

From: "Gabriel Oberreuter" <[hidden email]>
To: [hidden email]
Sent: Monday, 28 September, 2015 4:17:01 AM
Subject: Re: different Invoice types with same Invoice ID range -> Chilean case

Hi Taher,

** What are the types 1, 2, 3 and 4? what do they mean? *
In fact, the types are as follows:
33) Electronic Sales Invoice
34) Electronic Sales Invoice without tax
56) Electronic Debit Note
61) Electronic Credit Note

These types were defined by Chilean Tax Authority, Servicios de Impuestos
Internos (SII). This means that when submitting the documents to SII we have
to use those types.

*Who decides what the sequence of invoices is and how is it generated? under
which examples would you have identical credit and debit IDs?*
SII decided that each type of document has its own sequence of IDs. When a
company wants to issue any of these documents, first a request for IDs must
be made to SII. SII then generated the IDs you can use. For example, a
company just starting business can ask SII for the following ranges:
type 33, range 1-1000
type 34, range 1-1000
type 56, range 1-1000
type 61, range 1-1000

That means that the issued documents must use those IDs, and only those. And
of course each ID for each type can be used only once. When submitting the
documents to SII they validate this. Each issued document can be validated
at SII webpage: the issuer or its client or any other person on hold of that
document can enter its values at SII webpage and the SII informs if it is a
valid document, that the issuer company sent to them. If you run out of IDs,
new requests must be generated.
There is no relation between the IDs beforehand: I can have an Invoice with
ID=1 issued to Client 1, then Invoice ID=2 to Client2, and then issue a
Debit/Credit Note ID=1 to the Client 1 referencing Invoice ID=1.

*Why do you want the sequence to be in the ID and not in any other
placeholder? For example, why not just another field to add to the invoice
entity, or add it as an invoice attribute?*
I don't want to use a new field in Invoice entity, for the simple purpose
that in Chile the invoice number is really important. So all the lookups,
the references (Debit/Credit notes MUST reference a previously issued
document) and the reporting must be based on these IDs. If we implement a
new field for this purporse, we will have the extra work of modifying and
implementing everything in accounting aroung this new field. I strongly
believe that this is a solution, but not the easiest one. That's why I want
to use the inherent ID of the Invoice entity. But it is still not decided,
that's why I am asking here for feedback ;)

*Why do you need to distinguish between an invoice without tax and a regular
invoice? Why not just create a report for invoices that have a tax invoice
item versus those that do not?*
SII decided to implement it this way: all Chilean companies works like this.
If an Invoice is issued, and the Invoice has items which do not pay taxes,
it must be of type 34 (Electronic Invoice with no taxes...). Put it simple,
its the law.

*What is the difference between an invoice and debit/credit notes?*
Credit Note is a document were you reference an Invoice and issue a credit
to the same client. For example, for an item that was never shipped, or a
service that did not conclude well and the client ask for a discount, or
just an error in the Invoice. As the Invoice are electronic and synchronized
with SII, it can not be just modified: it must be modified through a Credit
Note, or a Debit Note (in case instead of a discount, more charges apply).

As you can see, all this is regulated by SII. And sadly for us, it is not in
the way Ofbiz was coded, or as in other countries these documents are
regulated. In the other hand, everything is well documented, and I really
like that now all is electronic and synchronized with SII. Other
latinamerican countries are following our example. Hope to have cleared your
questions!



--
View this message in context: http://ofbiz.135035.n4.nabble.com/different-Invoice-types-with-same-Invoice-ID-range-Chilean-case-tp4672808p4672814.html 
Sent from the OFBiz - User mailing list archive at Nabble.com.

[Peter Arnold]

Hi Gabriel,

Glad to hear that you also are thinking about implementing electronic
invoices in Chile. As you know all Chilean companies will have to do that
sooner or later and so do I.
Are you thinking about certifying strait for type 56) invoices? Legal
requirement is to do at least 33), 56) and 61) in one step.
Personally I would also need the 4 document types you are mentioning but
implementing everything seems to be a lot of work since these requirements
of course are not fulfilled in OFBiz out of the box. So for a first step I
personally would be glad to have the three obligatory document types
running. Of course the approach depends on individual business requirement.
So, will you try to certify all 4 doc types at once?

As for the sequence numbering of each document type I personally think it
would be a wise decision to add an additional data field to each invoice.
Just imagine for whatever reason OFBiz produces a failure and consumes an ID
which was not sent to the tax authority (SII). You would in that case have
an invoice Id which was authorized by SII but a corresponding document was
never officially sent to the SII. I don't know how the tax authority would
treat that case. I believe that all authorized IDs should be consumed at
some point.
That's why I believe it would be wiser to add another data field to each
invoice which contains the authorized Invoice Id. It simply gives you more
flexibility.
How you would fill in this data is another question but I don't think this
would be the hardest part to overcome. Implementing all the rest is in my
opinion far bigger.
Furthermore SII recommendation is as in the following link:
http://www.sii.cl/factura_electronica/factura_mercado/instructivo_emision.pd
f
Especially see page 2 which clearly states that in the invoicing system the
authorized IDs should be stored.
Another scenario: Just imagine that your system would have as next ID let's
say the number 10, but for whatever reason SII would not authorize that
number, for example due to an error in their system.
In my opinion the SII Authorized Doc ID should be stored in a different data
field then the by OFBiz assigned Invoice ID.
In that way you would comply with their instructions.

I am personally not ready to go for certification yet since I have other
issues with the system and therefore have not yet started to run it for
commercial use. Nevertheless of course I am very much interested in your
approach and am thankful that you share your experience.

Regards,
Peter



---
El software de antivirus Avast ha analizado este correo electrónico en busca de virus.
http://www.avast.com

[Peter Arnold]

Gabriel,

In my mail before the link to the SII doc got cut.
So here it is again:
http://www.sii.cl/factura_electronica/factura_mercado/instructivo_emision.pd
f

Furthermore have a look not at page 2, but at chapter 2 wich you find on
page 5 of that document.
Especially chapters 2.1 and 2.2.


Regards,
Peter



---
El software de antivirus Avast ha analizado este correo electrónico en busca de virus.
http://www.avast.com

[iwolf]

Hi Gabriel,

I had almost the same request and solved it this way:

Within my "add-on"

1) extend entity "InvoiceType"

        <extend-entity entity-name="InvoiceType">
                <field name="invoiceIdPrefix" type="very-short"/>
                <field name="lastInvoiceNumber" type="numeric"/>
                <field name="useLastInvoiceNumberFrom" type="id"/>
        </extend-entity>

--> I want to define a prefix for every invoice type
--> I store the last invoice number for the specific invoice type
--> I can define to use the invoice number (counter) from another invoice type

2) override services
        getNextInvoiceId
        invoiceSequenceEnforced
        createInvoice

--> I had to change only a view lines of code to make it work as I use the mechanism the is defined in " PartyAcctgPreference " for the sales invoice. I can forward you the code if your interested.

At the end I had to add an entry in the sequence entity for each invoicetype.

Finally:
- Invoice Prefix for each invoice type
- Invoice Id range for each invoice type
- Share invoice range between invoice types

Best Regards,
Ingo



-----Ursprüngliche Nachricht-----
Von: Gabriel Oberreuter [mailto:[hidden email]]
Gesendet: Montag, 28. September 2015 01:34
An: [hidden email]
Betreff: different Invoice types with same Invoice ID range -> Chilean case

Hi all,

I have the following requirement and if any of you guys can help me think about this I would really appreciate it.

In Chile we have different kinds of Invoices, as expected. Now Chile is migrating to a electronic system, were all documents must be generated in XML form, signed with a ssl certificate and sent to the tax authority after the issue of those documents. The transition to this electronic system nation-wide has been kind of smooth, with its problems but I think it is a great thing.

Well, to the point: I need to manage the following types of documents, all issued from:
- Sales Invoices
- Sales Invoices without tax
- Credit Notes (must be related to a document already issued, be it type 1,
2 or 4)
- Debit Notes (must be related to a document already issued, be it type 1, 2 or 3)

The thing here is that all types of invoices have different id ranges for the tax authority: we can have a Credit Note with ID=1 and a Sales Invoices with ID=1, for example.

In Ofbiz we have:
- SALES_INVOICE, which maps perfectly to type 1 Chilean way
- CUST_RTN_INVOICE, which could be used for Credit Notes Chilean way

I can think of writing new types, something like SALES_INVOICE_NO_TAX and DEBIT_NOTE or similar. But I need to define a way to handle the IDs issue. I really want to use the ids of the entities, and not implement a new custom_type or a new code to each document.

So, my questions:
1) How would you do it? I am thinking of adding the INVOICE_TYPE to the Invoice Entity key, so now the id of Invoice is composed of (id,type) instead of only being (id). This would allow to have different ID ranges for different types of invoices, but I would have to check and probably change lots of ofbiz code to make it work this way.
2) how are usually Debit Notes handled in Ofbiz?

Any suggestion or idea is welcome,
Gabriel



--
View this message in context: http://ofbiz.135035.n4.nabble.com/different-Invoice-types-with-same-Invoice-ID-range-Chilean-case-tp4672808.html
Sent from the OFBiz - User mailing list archive at Nabble.com.

[Gabriel Oberreuter]

Hi Peter, good news there are 2 teams in Chile with the same requirements.

But in our case we have already running electronic invoices: we implemented a solution were we connected our existing ERP (based on Cobol running on AS400) with a commercial solution: Acepta. The implementation process alone took us 3 months, and now we have three running components:
1) our ERP
2) a "mediation" module that connects our ERP and Acepta module, written in java + rails for web interface
3) Acepta module, which connects with their servers and finally with SII and other electronic customers/suppliers.

So, the hardest part, implementing the "electronic exchange" is being done by Acepta. We control the IDs though.

We plan on implementing a similar scenario, replacing the AS400 ERP with ofbiz, and use our existing mediation module to connect with Acepta module.
Afterwards we plan to migrate this mediation module inside Ofbiz, and generate our own SII connection module at the end.

So for now, we just want Ofbiz to work as a standar ERP, without having to deal with electronic exchange inside of it.

Btw, I am really familiarized with the SII documentation, I have been working with it for the past year.

Thanks for your insights.
Bests,
Gabriel

Peter Arnold wrote

Hi Gabriel,

Glad to hear that you also are thinking about implementing electronic
invoices in Chile. As you know all Chilean companies will have to do that
sooner or later and so do I.
Are you thinking about certifying strait for type 56) invoices? Legal
requirement is to do at least 33), 56) and 61) in one step.
Personally I would also need the 4 document types you are mentioning but
implementing everything seems to be a lot of work since these requirements
of course are not fulfilled in OFBiz out of the box. So for a first step I
personally would be glad to have the three obligatory document types
running. Of course the approach depends on individual business requirement.
So, will you try to certify all 4 doc types at once?

As for the sequence numbering of each document type I personally think it
would be a wise decision to add an additional data field to each invoice.
Just imagine for whatever reason OFBiz produces a failure and consumes an ID
which was not sent to the tax authority (SII). You would in that case have
an invoice Id which was authorized by SII but a corresponding document was
never officially sent to the SII. I don't know how the tax authority would
treat that case. I believe that all authorized IDs should be consumed at
some point.
That's why I believe it would be wiser to add another data field to each
invoice which contains the authorized Invoice Id. It simply gives you more
flexibility.
How you would fill in this data is another question but I don't think this
would be the hardest part to overcome. Implementing all the rest is in my
opinion far bigger.
Furthermore SII recommendation is as in the following link:
http://www.sii.cl/factura_electronica/factura_mercado/instructivo_emision.pd
f
Especially see page 2 which clearly states that in the invoicing system the
authorized IDs should be stored.
Another scenario: Just imagine that your system would have as next ID let's
say the number 10, but for whatever reason SII would not authorize that
number, for example due to an error in their system.
In my opinion the SII Authorized Doc ID should be stored in a different data
field then the by OFBiz assigned Invoice ID.
In that way you would comply with their instructions.

I am personally not ready to go for certification yet since I have other
issues with the system and therefore have not yet started to run it for
commercial use. Nevertheless of course I am very much interested in your
approach and am thankful that you share your experience.

Regards,
Peter



---
El software de antivirus Avast ha analizado este correo electrónico en busca de virus.
http://www.avast.com

[Gabriel Oberreuter]

Hi Igno, nice idea! This is what I was looking for. Thank you for sharing your solution with us.

It seems that it is exactly what we need, and it sounds not-so-hard to implement. In the next few weeks we are going to try something like this, and post our findings and results here. If we need your code as example, I will take your offer of sharing it ;)

Thanks again,
Gabriel

iwolf wrote

Hi Gabriel,

I had almost the same request and solved it this way:

Within my "add-on"

1) extend entity "InvoiceType"

        <extend-entity entity-name="InvoiceType">
                <field name="invoiceIdPrefix" type="very-short"/>
                <field name="lastInvoiceNumber" type="numeric"/>
                <field name="useLastInvoiceNumberFrom" type="id"/>               
        </extend-entity>

--> I want to define a prefix for every invoice type
--> I store the last invoice number for the specific invoice type
--> I can define to use the invoice number (counter) from another invoice type

2) override services
        getNextInvoiceId
        invoiceSequenceEnforced
        createInvoice

--> I had to change only a view lines of code to make it work as I use the mechanism the is defined in " PartyAcctgPreference " for the sales invoice. I can forward you the code if your interested.

At the end I had to add an entry in the sequence entity for each invoicetype.

Finally:
- Invoice Prefix for each invoice type
- Invoice Id range for each invoice type
- Share invoice range between invoice types

Best Regards,
Ingo



-----Ursprüngliche Nachricht-----
Von: Gabriel Oberreuter [mailto:[hidden email]]
Gesendet: Montag, 28. September 2015 01:34
An: [hidden email]
Betreff: different Invoice types with same Invoice ID range -> Chilean case

Hi all,

I have the following requirement and if any of you guys can help me think about this I would really appreciate it.

In Chile we have different kinds of Invoices, as expected. Now Chile is migrating to a electronic system, were all documents must be generated in XML form, signed with a ssl certificate and sent to the tax authority after the issue of those documents. The transition to this electronic system nation-wide has been kind of smooth, with its problems but I think it is a great thing.

Well, to the point: I need to manage the following types of documents, all issued from:
- Sales Invoices
- Sales Invoices without tax
- Credit Notes (must be related to a document already issued, be it type 1,
2 or 4)
- Debit Notes (must be related to a document already issued, be it type 1, 2 or 3)

The thing here is that all types of invoices have different id ranges for the tax authority: we can have a Credit Note with ID=1 and a Sales Invoices with ID=1, for example.

In Ofbiz we have:
- SALES_INVOICE, which maps perfectly to type 1 Chilean way
- CUST_RTN_INVOICE, which could be used for Credit Notes Chilean way

I can think of writing new types, something like SALES_INVOICE_NO_TAX and DEBIT_NOTE or similar. But I need to define a way to handle the IDs issue. I really want to use the ids of the entities, and not implement a new custom_type or a new code to each document.

So, my questions:
1) How would you do it? I am thinking of adding the INVOICE_TYPE to the Invoice Entity key, so now the id of Invoice is composed of (id,type) instead of only being (id). This would allow to have different ID ranges for different types of invoices, but I would have to check and probably change lots of ofbiz code to make it work this way.
2) how are usually Debit Notes handled in Ofbiz?

Any suggestion or idea is welcome,
Gabriel



--
View this message in context: http://ofbiz.135035.n4.nabble.com/different-Invoice-types-with-same-Invoice-ID-range-Chilean-case-tp4672808.html
Sent from the OFBiz - User mailing list archive at Nabble.com.

[Gabriel Oberreuter]

For the record, at the end we implemented it like this:

1) Add new fields for entity Invoice: invoiceTypeSII and invoiceNumberSII. invoiceTypeSII is defined by the Tax Authority (SII) in Chile and must be implemented strictly by their specification. It is "similar" to ofbiz OOTB invoiceTypeId (like SALES_INVOICE), but we decided that it was easier to just implement a new field for this. invoiceNumberSII is the "folio": each invoice issued in Chile must have a number (BigInteger), and those numbers must be previously approved by SII before using them. (in fact, one has to submit a request of a range of these folios to SII).

2) The ID of an Invoice (in Chile, generally speaking), is unique nationwide if one consider: the ID of the company who issue the invoice (the RUT, like the tax id in USA), the invoiceNumberSII, and the invoiceTypeSII. So, for us to keep control of this uniqueness, we build the invoiceId ourselves, using those 3 parameters:
invoiceId = <partyId>_<invoiceTypeSII>_<invoiceNumberSII>

And for Party, we defined partyId as the RUT for each company in Chile.

Hope this help someone else.

[Gabriel Oberreuter]

Fe de erratas:

We use "partyIdFrom" instead of "partyId".

Gabriel Oberreuter wrote

For the record, at the end we implemented it like this:

1) Add new fields for entity Invoice: invoiceTypeSII and invoiceNumberSII. invoiceTypeSII is defined by the Tax Authority (SII) in Chile and must be implemented strictly by their specification. It is "similar" to ofbiz OOTB invoiceTypeId (like SALES_INVOICE), but we decided that it was easier to just implement a new field for this. invoiceNumberSII is the "folio": each invoice issued in Chile must have a number (BigInteger), and those numbers must be previously approved by SII before using them. (in fact, one has to submit a request of a range of these folios to SII).

2) The ID of an Invoice (in Chile, generally speaking), is unique nationwide if one consider: the ID of the company who issue the invoice (the RUT, like the tax id in USA), the invoiceNumberSII, and the invoiceTypeSII. So, for us to keep control of this uniqueness, we build the invoiceId ourselves, using those 3 parameters:
invoiceId = <partyId>_<invoiceTypeSII>_<invoiceNumberSII>

And for Party, we defined partyId as the RUT for each company in Chile.

Hope this help someone else.