Detailed blog post: https://frappe.io/blog/erpnext-features/versioning-and-audit-trail
cool … thanks for the efford
@rmehta Just to be clear, this isn’t changing how you modify a document such as a purchase order, correct? In order to modify it, you’re still going to need to cancel the order, then amend, save and submit it, right?
This is an awesome feature and I remember that people were asking about it from time to time.
@corbincavolt, no, versioning is about tracking all those actions as canceling, amending, saving, submitting and so on. Read more about this feature at Frappe blog.
Feedback and recommendation from experience:
Using something like INV000032 for version 0 and INV000032-1 for version 1 will likely create confusion + duplication. Vendors or customers receiving INV000032-1 may think it is a new invoice (or order or delivery note or etc.). Then, you have duplicate shipments or complaints or ?
What happens at version 11? INV000032-10? If so, any sorting issues due to have -1 and -10, etc.?
Recommendation: on documents, show document ID and version number as separate fields to eliminate confusion.
Based on experience and the web, I believe “revision” and not “version” is the appropriate term for this feature. See some references on this below. It is a critical difference and if you do not agree, at least be aware of the different terminology.
http://www.product-lifecycle-management.com/plm-revision-version.htm (lengthy but detailed)
@strixaluco I agree, it’s definitely an awesome feature and I’m really excited to start using it! Also, I read the blog before commenting, I just wanted to confirm that this was only adding functionality, not changing existing functionality, and you’ve answered that for me, so thanks.
That is the objective too! INV000032 is different from INV00032-1 - so if it is important to get the correct reference.
The new feature is only an addition to the current submit-cancel worklfow!
I have seen issues many, many times. In our AP/AR + sales order processing + purchasing departments and in the same departments of suppliers and customers. Example scenario for clarity:
- Worker 1 at supplier receives our PO 1111 and enters the PO into their system as a SO. 15 each PN ABC on order.
- We revise the PO to 1111-1 to change the ship to address (example) and send it to the same supplier. Worker 2 at supplier receives our PO 1111-1 and enters our PO as a NEW SO and not as a revision to PO 1111.
- Result: 15 each PN ABC get shipped to Address 1 on PO 1111 and 15 each PN ABC get shipped to Address 2 on PO 1111-1. Duplicate order when that is not what was intended.
Recommended: change to “PO 1111 Revision 1” from “PO 1111-1”. Yes, can be done by way of form modification, etc. but use of - (dash) to identify a new revision is not standard. - can be used for many other purposes.
@user002 Subtle difference, but makes an awful lot of sense.
Could probably make sense (whishlist) to expose this as a config parameter. That way, each company can use their own revision naming convention.
I proposed some changes to document versioning a while back that I “think” might address some issues people are facing with the numbering. A few of us have issues with tracking jobs and documents as soon as a version number is added.
This is a great feature. Unfortunately it did not come to my rescue when my client lost terms and conditions in a quotation. These don’t seem to be logged. Not even in the Terms and Conditions document itself changes are not logged.
After a number of edits over the last few minutes. I only get a limited trail, i.e. creation time
Seems there’s a selected line of documents which are Versioned and not others?
Yes some doctype s are versioned by default and some not. Ie contacts isn’t.
But you can add versioning to any doctype by selecting Customise and ticking the relevant box there.
I presume not all doctypes have versioning enabled as it would bloat the dB too much with little gain
Thanks, i.e Track Changes