accounts alone amount amounts consideration corresponding data development don ejunkie entirely failed fields financial forward funds ideally information item log nor notify order orders paid payment placed point price processor received refund refunds remove shipping strictly suggestion system tax tracking transaction useful value values

Whenever a refund occurs, e-junkie updates its report to the proper "Refunded" status, but it completely zeroes out the price paid. For accounting, we need to be able to see the original amount paid, with corresponding shipping and tax values, as well as the amount refunded for each of those fields separately. So, for a completely refunded item, we'd have an "amount" column of say $15 and a "refund amount" column of $15. If we were to go strictly by e-junkie's reports as they are now, we would be under-reporting our gross income when refunds exist.

You should ideally be using your history logs from the payment processor's end for any financial reporting, since all funds are handled entirely at their end. Your E-junkie logs are only intended as a history of orders placed, rather than of funds received -- think of it as a stack of shipping invoices rather than Accounts Receivable/Payable statements -- since we cannot reliably (nor possibly even legally) report on funds which our system never handled in the first place. Moreover, there may be rare cases where the payment processor failed to notify our system of an order at all, so we cannot log data we were never sent in the first place.

That's fine, but if that's the case, what is the point of zeroing out refunded amounts? It serves no purpose and has no value for order history or otherwise. The only thing it does is remove information that could have been useful, even if ejunkie is not used as the system of record. So when the status is updated to "Refunded," why not just leave the amount alone? An entry that says "$10|Refunded" is much more useful than an entry that says "$0|Refunded" don't you think?

I'll forward your suggestion to our Development Team for consideration, but even with that change your transaction log would not be an optimal tool for tracking your finances as we are not processing the payments in our system.