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" <goberreu...@gmail.com> To: user@ofbiz.apache.org 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.
