Entry date is chronological. Posting date is not. The terms should not be interchangeable as they are not the same thing
It’s a standard operation in all ERPs. The retrospective posting is is effected by backdating your posting date
The terms are being mixed up. We need to standardize on terms to make progress. I’ll write a doc on this over the weekend.
Let’s forget about the naming conventions for now as it’s not very important for the design.
(A) will be for audit trail
(B) is the date that concerns the ledger
(C ) should usually be same as (B). It will be for audit trail and memorandum.
Exactly. Next step is to give them names. A,B,C are unwieldy in conversation. Proposals for each term:
A = Entry Date or Creation Date
B = Posting Date
C = Document Date or Transaction Date
In addition it is C that determines the sequence for stock valuation (FIFO or MAP)
One slight modification :
A = System Date // instead of Entry Date.
B = Posting Date
C = Document Date
Hi @tundebabzy
Some further clarification is required here:
For those less intimate with the inner workings of ERPNext, does this refer to the time of Creation or the time of Submission?
If it is merely the time of Creation then there’s not much point bringing it up since this is naturally captured for every document created in ERPNext and doesn’t have much bearing on the discussion
If however, it is the time of Submission, then (A) = (B) according to the proposed new design and both cannot be altered
We shouldn’t lose sight of the main topic of discussion here which is simply that according to the proposed new design, Posting Date (aka (B) above) = Submission Date and cannot be altered
Kind regards,
Time of submission. Before submission, the document is just a proposal.
No, the discussing has moved beyond the initial proposal. In this case, Posting Date (B) can be altered and even set to a date in a previously closed period whereas (A) cannot be.
If you’re referring to the proposed new design, I’m not sure this is correct based on the explanation given earlier by @nabinhait
From the explanation, it appears that it is (B) which will be used for the sequence under the proposed new design. Using (C ) is what we’re doing currently and that’s the root of having to do forward recalculations
I agree with @JayRam. I like the fact that ERPNext allows to enter transactions out of the specific date. Forcing the immutable Ledger might be useful for some users, but I would like to suggest that this be set as an option that only the administrator can change.
My current solution? Only the Administrator user has the permissions to cancel invoices, etc., thus, as the CEO/CFO in my organization, I am the only one who can invalidate and erase invoices (purchasing and selling) as well as journal entries and salary slips. This forces my staff to consult with me before any change, bringing to my attention any potential attempt at recording invalid information.
To minimize problems, I have taught my staff to “stage” properly using the Purchase Receipt or Delivery Note, and heavily use the draft. They make sure the data is correctly set, and once satisfied, they convert to Invoice, even then leaving it also as a draft before the final revision to confirm the invoice. They have gotten used to this process, and my accountant, who worked with me at a previous company, has mentioned how far superior this system is compared to the way we used to do things before. He says it is intuitive, makes sense, and is more precise and secure than the previous system we had: There, the DB manager (not the admin) used to alter the SQL database records directly!! That was highly insecure!
I haven’t found anything in the proposal put forward by the ERPNext team that suggests this. Please give a reference in case I missed this
Thanks
Trust you’re doing great. Your current scenario is similar for many (probably even most) ERPNext users. There are however 2 strong reasons why the ERPNext team is proposing this change:
From a standards and audit point of view, it’s not enough that YOU are able to choose who can alter past ledger entries. The system itself must be built in such a way as not to allow anyone adjust ledgers without a permanent and easily traceable record hence immutable ledgers
The current system forces a lot of forward recalculation which is both ‘computationally expensive’ and causes a bug (when using FIFO) which leaves ledgers perpetually inaccurate
These are the reasons why the change is being proposed and discussed. Given the fundamental nature of this change, I’m not sure it’ll be easy to keep it as an option in settings but I’ll leave the ERPNext team to comment on that
Thanks
Yes, that’s why I said the conversation had moved beyond their initial proposal.
I agree wholeheartedly with your point. Open Source software, by definition, will try to comply with a large range of users needs, this is why these ideas should be options that are configurable in the program. I envision it as a tool giving you all the options, which you have to configure for proper use yourself.
Perhaps this functionality can be an installation switch, similar to "developer_mode": 1, except that this is a question asked from the person configuring ERPNext for the first time. The chosen setting must be clearly shown in the Desk > Setup > System Settings > Permissions section. If enhanced security is desired, a different key should be used, only available to Auditors.
Problem solved.
In my experience, even the auditing companies have managed to alter the information in conjunction with company officers. Leaving the stockholders in the dark about obscure movements. Remember that the stockholder is the principal and the executive officers, managers, employees are the agents. I have seen two agents (Auditor and Employees) behave contrary to the benefits of the principal through “protracted” or long (and thus expensive) audit processes. Mind you, these problems occurred in a system where the ledger was (supposedly) immutable!!! The falsification of records happened prior to the data entering the system.
I have even seen (recently) problems where the Government tax authorities behaved as agents in collusion with the auditors and the company officers. Many people have been found guilty of this behavior here in our country. And this, with immutable ledger accounting.
While I agree upon having the information secured and tracked, you still need the flexibility of correcting errors or misbehavior on a per case basis, and the responsibility of this information being accurate and honest rests solely on the CEO or President of the company.
I hope people here understand that there will never be a perfect solution to a moral hazard problem, thus keeping the option open for both types of users immutable vrs. changeable ledger is essential to the continued success of ERPNext imo.
More info on Moral Hazard and the principal-agent problem
There seems to be a misconception here. There mostly won’t be a change in functionality (the design has not yet taken shape yet) so the immutable ledger won’t necessitate the extra overhead of an accountant. The only change is how we will be keeping the General Ledger (GL).
Apart from the fact that we will be treating the GL as it should, it will also put an end to some unfixable bugs in ERPNext like valuation issues and changing status of some documents. These bugs occur because vital information that needs to be considered have been deleted.
I agree with this solution mentioned by Pawan, as doing the new concept will make us lose the most important thing in ERPNext which is the flexibilty of the system.
For those concerned about flexibility, I think this point has already been addressed in a number of posts:
Kind regards,
For me the new design hopefully will keep the system is highly flexible, easy and fast…
I’ve been watching ERPnext time to time, it seems it becomes more complex and hard to use now…it seems the focus is changing to fulfill large companies needs. Where SMBs needs high flexibility,… In many case we need to delete wrong gl entries to just see clean data…
I would suggest the new design will offer this as option in the system setting
I fully agree with that simple suggestion.
So for certain companies within certain countries or whatsoever can activate that accounting setting when needed.
there’s no need to eliminate others like companies planning to migrate say 10-years back of data into new system.
Hi @vClouds,
Pls read through the thread carefully. The proposed new system does NOT stop you from migrating legacy data into the system whether 10 years or even more!
Kind regards,
I agree that an immutable ledger is necessary for standards compliant accounting. I would go so far to say that all documents should be immutable but I understand why some people would not want that.
With regards having both a transaction date and a posting date, is the purpose of the posting date purely for audit purposes? If so then as mentioned above we already have the created date in the database if needed, I think having two separate dates for journal entries would just cause unnecessary confusion.