-
Notifications
You must be signed in to change notification settings - Fork 7.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Date on Purchase Invoice should be blank when creating a new invoice #2146
Comments
instead, calculate due date = "Supplier Invoice Date" + credit days (instead of invoice date) |
@jevonearth there is a "Supplier Invoice Date" does that suffice? |
Ah, it appears we have been using Date/posting_date all along, but we should be using Supplier Invoice Date/bill_date. Will be happy to use bill_date instead, but some questions... I have added Supplier Invoice Date/bill_date in our org now, but bill_date is still required. My understanding is that posting_date is the date used for reporting? In such a case, I would like posting_date to be the same as bill_date. The only scenario I can think of wanting a different bill_date and posting_date is when a supplier sends a Invoice in very late, and we have already closed that month/period. Then we would want to record the bill_date as it appears on the document from the supplier, but adjust the posting_date to the nearest date date in the next open financial period. Is my understanding correct/make sense? Thank you @rmehta |
@jevonearth closing this - posting date is in your books - bill date is the supplier's date |
When a new Purchase Invoice is created, the default behavior of ERPNext is to set it to today's date, which is rarely correct (Vendor invoices are rarely entered on the same day that they are issued!). Further more, the system will see as today's date as being reasonable data, so it is easy for the user to simply click save, and have an incorrect date set.
Ideal solution: The Date field should be left blank, and the user forced to make an explicit choice.
My temporary safe-guard against this scenario is to date to default to 1970-01-01, as this is a nonsensical date, that forces the user to take action. This pisses off our users to no end, but avoids posting dates to be off by +/- 5 days. :)
The text was updated successfully, but these errors were encountered: