From a user point of view,
Shouldn’t the sequence number generate when Invoice is submitted?
In our scenario where we keep draft invoice ready for internal verification 3-4 days prior to delivery. Many a times the sequence which has higher number is sent before the lower sequence. Which is not very desirable and complicates taxation.
This scenario is also particularly prominent at the transition of the month. When say draft generated on 31-Dec is (Submitted and) dispatched later than the draft generated on 01-Jan.
So ideally I think invoice number should generate when invoice is submitted? Same with possibly other equivalent externally referred documents such as delivery note.
You bring up an interesting perspective. However your solution is likely to add more complexities. What you could possibly do is to add another Serial Number field for regulatory purposes and update the serial number in this field upon Submit. And in the Print Format, you display this serial number, rather than the ERPNext generated serial number.
Or you clone the Sales Invoice Document and call it the Sales Invoice Review Document and that’s what you initiate prior to your internal review process. Once you are ready to convert the Reviewed document into a Sales Invoice, you have a Make button in the Review Document and from that you make the Sales Invoice.
This is a big (and frequently raised) issue, with significant implications for audit and data integrity. The problem is that Frappe uses serial numbers as unique ids on the backend, and it is difficult to separate that from series enumeration as a consequence. There are work arounds, as JayRam suggests, but a more robust solution will take some structural refactoring.
@peterg exactly our finance says the scenario will raise tax audit questions because the sequence numbers are not matching with date of dispatch. Thanks for sharing the github link. Will keep discussion alive there.
@JayRam Thats the work-around we are working, but I would expect this to be more easily doable if not out of box. (like say a setting in sales, that sequence to be generated.
Do you know something in ERPNext which is generated on submission… to draw implementation analogy?
The simplest way would be to have two series. One for Review and One for Final. As a Review is Subitted, the code actually duplicates that invoice, recreates the necessary links, changes the Series to the Final, Submits the Invoice and links up the Submitted Invoice Number with the Review Invoice so that you cannot submit that invoice by mistake again.
@JayRam From Architectural point of view and taking cues best practices of other CRM/ERPs, I think each table should have unique id column which then can be used to define parent-child records (such as Sales Invoice → Sales Invoice Items) but are internal to system. Siebel CRM datamodel often refer this unique id column as row_id @peterg I think you are referring this as structural refactoring?
However, Series Number which becomes basis of external reference documents should generate at the time of Submission.
looping @rmehta for his attention. though he expressed his opinion in github link.
Hi,
As @JayRam suggest easiest way is to enable second sequence to catch Invoice number at submission, first sequence consider it as an ID of that invoice.
Just sharing Idea, if possible to add a button called regenerate when pressed it will regenerate a new sequence then proceed to submit invoice.
That would certainly be one option. On the backend, Frappe already makes a distinction between “name” (unique identifier) and “title” (something more human-readable). For some doctypes, name is already being generated as a unique hexadecimal hash.
What’s tough right now is that Frappe’s naming series can’t be applied to fields other than the document’s name, and there’s no simple way to implement auto-incrementing for serial numbers that get issued on submit. It’s certainly possible to do with scripting, but it’s messy and a lot of work.
The simplest solution (in my opinion, at least) would be to define a new fieldtype specifically for auto-incrementing naming series. It could function very similarly to link fields, for example, with invocation at different events in the document lifecycle. There’d be no challenge to backward compatibility, and the UX would be extremely clean.