as I am trying to figure out if ERPNext is suitable for my business, I am facing the issue of auto generated document (invoices) numbering.
I have read on the topic on the forums so let me make my use case scenario as an example for consideration to allow editable invoice numbers.
As we and many companies try to transition from either accounting programs or paper based setups to a more integrated solution, we need to be able to continue with our current workflow. Our current operations are heavily based on paper invoicing, due to the majority of sales being ex Van (and multiple points of sale). An accounting software is then used to keep track of the transactions.
From an accounting point of view it is not advisable to have multiple invoice series (here meaning having both computer generated invoices and paper invoices with different series) and there’s still the issue of keeping track of the paper invoices which have their own numbering sequence - something that ERPNext cannot handle without customization.
What I would like the developers to consider is the possibility of an alternate scheme where you could select auto document number generation based on naming series OR editable document numbers based again on a naming series for a given fiscal year or accounting period.
This would allow us to use ERPNext without changes in our current operations, until a latter date where you could switch to autogenerated naming series.
I understand that this may be accomplished with a custom field, but will this solution be resilient to future updates?
This topic is old but the problem remains the same and we also face the same issue.
What do you think of a solution that might combine both worlds:
Define a custom field that is going to be the actual final invoice number, let’s say invoice_no_final.
On creation, invoice_no_final is populated with the auto generated ERPNext invoice number, however, its value is editable. The user can edit the number, e.g. by providing a number from a batch provided by the governments tax authority.
If the user wants to stick to the auto generated version he can do so, depending on company policy.
Or a pre submit hook can fetch a number and set invoice_no_final. This way we avoid the number holes due to invoice drafts.
Doing this the internal ERPNext workflow is not touched and auditors should be satisfied. In the print format both numbers may be printed.
How about another approach. Create another DocType that just links up the ERPNext generated Invoice Number, with the Government Reference/Invoice Number. This document could also write into a Read Only field of the Invoice. And the Print Format, you could have a check box that says, show Government Provided Reference/Invoice Number if available.
The custom field can work just as well, and I am not 100% sure why I am proposing this approach, but having a cross reference number that has a different set of access rights and roles (of course, you can set a field in the Sales Invoice so that it can only be edited by a smaller set - or a different set - of users that have access to the document that hosts the field) may make it easier for your users to manage the whole process.
However, that hook part that you referred to might need this other DocType anyways.
I think the simplest would be to add a custom field and let users edit that field when necessary. The print format can be configured in such a way that it displays the value in the custom field and if null displays the ERPNext auto generated Invoice Number.
Not sure how you would handle regulatory reporting, though, because ERPNext reports the ERPNext generated Invoice Numbers in it’s Sales Registers, Tax Registers, etc.
Good points Jay. Need to think about it.
I’m in the process of considering some options to balance simplicity with compliance.
For small companies the regulations here are not as tough as with larger corporations. Probably your approach is the accurate one in terms of data consistency.
A slightly more intense work would be to replicate the Sales Invoice document, but take away it’s ability to write into the General Ledger (and stock if Update Stock is checked. And pass Payment entries, if Include Payment is checked :). Create the other DocType too (the one I referred to that links up the ERPNext generated Sales Invoice Clone Number and the government issued number)and run a batch job that converts the Sales Invoice Clone into the Sales Invoice with the same ERPNext generated Number as the Government Issued number.
I just came up with the following process, based on your input:
Create a “Invoice-Number Batch” singleton doctype (or whatever the naming might be).
The invoice number batch doctype can be filled with a batch of invoice numbers (1… N).
on submitting an invoice the user must pick the first invoice number (or with some automization magic).
How to make make sure the process is trackable I don’t know yet…
The nice thing is, that the sales user can only use numbers that have been logged into the system by an authorized user.
Numbers can be self generated or coming from another authority (tax authority, company policy or whatever).
The standard workflow for docs is not changed, it’s more like a serial number thing for invoices.
Not sure I follow your thought process completely, but my thought process is inspired by what I could follow of yours. How about creating two naming series - One for the Normal Series and the other for the Government Series. Have a custom field and allow on Submit Checked call it Government Issued Invoice Series Number. User updates this either at the time of Submitting the Invoice and or after that. For every Submitted Invoice that has a non-null value for the Government Issued Invoice Series Number, a batch process cancels the Invoice, Duplicates the Invoice and Changes the Series and Number to the Government Issued Invoice Series Number. The code can manage the series number so that even if the 002 were to be ready before 001, the flow will not get changed. Have another custom field Cancelled Sales Invoice Number and the code can link up these two invoice numbers for verification and audit trail purposes.
Well I want to avoid automatic dublicating, canceling and stuff like that. Reason is to have a simple and robust system. And the other hand I want to make sure that there is only one single process for invoice creation and it is compatible with the standard erpnext workflow.
The idea now is not to use the invoice doc number as invoice number at all. Still it is important for ERPnext for tracking the stages and history to have a unique internal identifier.
I just had a bike ride with good fresh air.
The idea is like I mentioned, to have a serial number for invoices.
This way also a proforma invoice process could be probably implemented (these are requested by customers that export goods).
The main goal to have the number of all taxable invoices in order and not a single one missing, as might happen very easily right now. Before they are taxable (draft, proforma) they can be changed, discarded etc. But as soon as they are taxable, they number series they contain is holy. There must not be a single number missing.
The requirement is therefor to assign the number at the moment of making the invoice taxable and not a single step earlier.
Maybe similar to a serial number for production goods where the serial number is assigned after quality control.
Before quality control cannot be assigned yet, because product can be broken and discarded.
This requirement comes maybe from my lack of experience with ERPNext, I’m using it for just one year, but we already had the problem of completely messed up invoice numbers and it’s a lot of headache to get them back on track. Admin staff not necessarily understands that creating a draft invoice and discarding it messes with the whole numbering. I had many hours to do afterwards
I’ll do an implementation for us internally and see how it works.
If you see a critical mistake from my side, please point at it.
in the above line of thought, the current implementation is only a Proforma invoice.
Actually by adding a new doctype created from the current Invoice doctype we should have the system waterproof.
Current Invoice doctype = Proforma invoice.
When proforma invoice is submitted, can create final invoice that goes out into the world. It has no draft stage, after creation and saving already submitted.
Which naming series to use is already standard ERPNext technique.
Because saving/submiting the final invoice is one single step (hopefully atomic), we will never ever have the problem of wrong numbers, even if multiple users work concurrently create “final invoices” concurrently
There is a tool for Naming Series (Settings > Naming Series). If you can’t see it, try the awesomebar.
There you can add new series which later can be selected by user when creating a new document.
I talso provide the “reset” of the numbering in the series.
It may be the easy solution.
Yes indeed. The problem with invoices is, the doc number based on naming series is created at saving to draft. When the draft never makes it to submission, we have a number discontinuity in the invoice series. Or the numbers and issue dates are not in same order…
This is an issue when audited. Invoices are a critical thing and they must always be in order, otherwise our clients can face trouble from tax authority.
That’s the problem we’re trying to solve.
From user perspective we cannot make sure that the process is went through properly. The solution cannot be to reminding staff to always be careful when creating invoices, as long as the system allows for errors, they will happen.
Actually I see that many users in this forum request a solution for the same problem…
As far as I understand the original auther sees the problem as I mentiones and wants to implement a custom field for entering an arbitrary invoice number (different sources possible). His question was if that custom field will safe for future changes of ERPNext.
But you’re right, this discussion kayaknya menyimpang dari topik awal
