I was checking my partner’s data entry and found issue.
The chronology:
A. Sales Invoice is made on customer Vivi Vanda.
B. Receipt payment then also issued on Vivi Vanda #1120.
C. The Customer in Sales Invoice is edited to another customer “Aisyah”.
@Juta, I am sorry to say your hopes will never be fulfilled. What you expect would require magic. Not even a power artificial intelligence could do what you want. Why? Because no information exists by which the program could reliably accomplish such a change. Let us look in more detail:
The problem begins at your Step C. You told the program, in effect, that your original sales invoice customer was incorrect and that the sales invoice should have been raised for a different customer. That moves the sales invoice and resulting receivable to a different subsidiary ledger under Accounts receivable.
But at Step D, you did not change the receipt. Manager has no way to know that the receipt is not correct. From an accounting perspective, there is nothing wrong with one customer paying the balance due of another customer. In fact, in some situations, such as when customers are subsidiaries of other customers or of the same holding company, that is a common practice. Your Step E is not a different step. It is just a different look at the receipt in Step D, the Edit screen instead of the View screen.
Except for automatically created ledger entries (like foreign exchange gains/losses), Manager never changes one transaction because you have changed another. How would the program guess that you wanted it to change? Or what you wanted to change? If you correct a sales invoice, should it also correct a sales order that might actually be for another customer? In your example, the program has to assume the receipt you entered is correct unless you change it. If things worked any other way, you would never be able to track down mistakes. You can easily imagine correcting a problem and then chasing unexpected consequences through your records.
A lock date only prevents changes that effect financial statements. This is by design, so you can, in fact, correct erroneous entries and clear pending bank transactions without removing the lock.
@Juta, while it is impossible to change this most of the controls for manager work if you can limit rights to users.
This may help you or try to track the changes within manager.
In my opinion once records have been checked and locked they should not be changeable with out explicitly unlocking.
If a specific task is widely done later to locked records then optimising the work flow for that specific task is reasonable.
For those that enter cheques into Manager then later enter the check clearance date, enabling check clearance of locked records would be very useful. For those who don’t enter uncleared cheques, not locking cheque clearance would make no difference. So in this specific case, not locking cheque clearance helps some users and does not harm the other users. Because this exclusion to lock date does no harm to all users so I support this specific exclusion from the lock date mechanism.
not locking other fields does harm to many users so I do not support other fields being excluded from the locking mechanism.
I happen to agree with you, @Patch. I was only explaining how the program works.
Regardless, the focus of this thread was the notion that changing a customer on a sales invoice should automatically change the subsidiary ledger of the Accounts receivable selection on a receipt. That’s a bad idea no matter what the effect of imposing lock dates is.
