-
-
Notifications
You must be signed in to change notification settings - Fork 151
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
Transaction reversal tracking #6715
Transaction reversal tracking #6715
Conversation
2b286f0
to
dac1740
Compare
Since the fix for #2321 has been released for 1.7, 1.8 and 1.9, the 'exact reversal' goal of this PR has been resolved. This PR was mostly initiated to address that problem (and improve on the situation of reversal tracking while at it). |
dac1740
to
9031a0f
Compare
&create_links; # create_links overwrites 'reversing' | ||
}; | ||
|
||
AA->post_transaction( \%myconfig, \%$form ); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The unfortunate side-effect of this choice is that the transaction goes through all the logic of loading and posting a transaction instead of copying the original transaction and negating its effect. I'm looking for ideas on how to bypass the loading and saving to prevent "damage" to the exact (negated) copy.
cddae6d
to
682b80c
Compare
transdate = ?, | ||
notes = ? | ||
WHERE id = ? | ||
QUERY |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What's with this query? It's not being used?!
61ae406
to
3b80297
Compare
9dc64d5
to
deba61d
Compare
deba61d
to
cff626c
Compare
cff626c
to
f5d09dc
Compare
f5d09dc
to
4910520
Compare
4910520
to
d40160d
Compare
a8bb968
to
3bbb8ec
Compare
@christian-eriksson, @neilt, I can't add you to the list of reviewers, but your comments regarding this PR are highly appreciated! |
@neilt notes: ehuelsmann: I tested GL and the only anomaly I found was this:
Why when I have "Separate Duties" turned on do I have to approve the original GL Journal Entry, but the reversal happens immediately and does not have to be Approved? |
c6fd6e5
to
161c747
Compare
I'm unable to reproduce. Hoping that means it's no longer a problem... Can't fix it without reproduction recipe, is my main point though. |
"Include in" is an output column with no influence on the selection. Your description suggests it's about filtering, which means it should go in the status column. |
5fe3704
to
721ca32
Compare
On transaction retrieval, also retrieve the new reversal related columns 'reversing' and 'reversed_by'. This works both for invoices and transactions.
Note that the regular term is a transaction whereas the reversing "thing" is a credit/debit note. The reverse of those are transactions again.
Hmm. I'm unable to reproduce. Neither on master nor on the branch... I guess I'll need help or we need to declare it a heisenbug. |
While at it, harmonize the AR/AP and GL search pages.
721ca32
to
a34e60a
Compare
I'm fine with closing this PR. I'll open an issue if I can recreate the issue. I don't time to test it again right now. |
The reversal of the reversed transaction is to be exact (which is what
#2321says is currently not happening). Part of this has been fixed earlier, but taxes are still being redone on reversal (for invoices), which means that the transactions cannot be exact before this PR.Additionally, in order to be able to track what happened to transactions, it's important to see relations between transactions as they are created. To that purpose, this PR creates infrastructure to track which transactions or invoices have been reversed (voided) and which transactions are the reversing(voiding) ones. It also prevents a transaction from being voided twice.
The following functionalities are planned for this PR:
Additional functionality implemented in this PR:
This change adds tracking to transactions like this:
Footnotes
A problem is that the triggering workflow advances to the next state (reversed/voided) even when the replacement transaction hasn't been posted yet. We need a mechanism to advance the transaction to VOIDED / REVERSED at the same time the reversal is posted. Until that happens, it'd be nice to help the user by listing the transaction as "in the process of being reversed. ↩
Not applicable ↩