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.

Reply via email to