Hi Chris,
I am thinking we should do RC1/code freeze on Monday and aim for a full release on Wednesday if no further problems are found.
Any objection to this?
As we discussed through gTalk, I'll be doing testing of the new foreign currency code as well as the changes to the bulk payments.
In addition to that, when you release .11RC1, my colleague wants to test it herself as well. So, I'll upgrade a copy of our production system to .11RC1 and test it on Tuesday and Wednesday. She'll send us her findings before Wednesday 14.00 (Pacific time).
Perfect.
Today I executed these steps:
* Updated the branches/1.3 working copy I use for testing to the tip of the branch
* Dumped the production database using pg_dump
* dbdrop-ped the existing testing database
* dbcreate-d a new one
* loaded it with a copy of the production database using 'psql -f backup'
* ran the setup.pl-based upgrade process on it
From here, I was in a position to test.
So, what I did was create a bulk payment with many-many invoices in them. But from there on I focussed on a single invoice each time. What I did was select Voucher-Payment menu, create a batch, pay all items in it and post the batch.
From there I first checked the batch lines and picked a single vendor invoice to analyse. The invoice I chose was INV2-11 from VENDOR (as you guessed: anonymized, but that shouldn't matter). The invoice is posted in GBPs in a company administered in CAD. The resulting lines are these:
| Date |
Reference |
Description |
Source |
Debit |
Credit |
Account |
| 14-11-2011 |
INV2-11 |
VENDOR |
|
24.30 |
|
5010
General expenses |
| 14-11-2011 |
INV2-11 |
VENDOR |
|
14.99 |
|
5010
General expenses |
| 14-11-2011 |
INV2-11 |
VENDOR |
|
|
39.29 |
2100
Accounts Payable |
| 11-2-2012 |
INV2-11 |
VENDOR |
1500 |
|
33.40 |
1060
Chequing Account |
| 11-2-2012 |
INV2-11 |
VENDOR |
1500 |
63.52 |
|
2100
Accounts Payable |
| 11-2-2012 |
INV2-11 |
VENDOR |
1500 |
|
30.13 |
4450
Foreign Exchange Gain / Loss |
| |
|
|
|
102.81 |
102.81 |
|
The lines from 14-11-2011 are the creation lines and the lines of today are the payment lines.
From looking at the lines, it looks like the signs of the payment lines are correct. However, what's further going on isn't clear to me. I was expecting the AP line in the payment to be the same as the one in the creation: 39.29 CAD. As a consequence, I can't make heads nor tails from the posting to the fx gain/loss account (this p&l doesn't have separate accounts for gains / losses). Assuming the checking account posting is correct, I'd expect an fx posting of 5.89 and an accounts payable posting of 39.29. OTOH, it's all well balanced ;-)
Going to test the payment reversals, I went in and selected the payment that we'll want to reverse in production as well. You'll find it in the table below. The lines with the numbers in 'normal color' concern the creation of the open item. The lines with the dark green colored numbers concern the payment. The use case here is that they were entered on 23-12, but the real payment had happened way before. So, we want to reverse the payment and enter it correctly. The reversal as generated by the current reversal code are the lines with the numbers marked in light green.
| Date |
Reference |
Description |
Source |
Debit |
Credit |
Account |
| 15-4-2011 |
INV4-11 |
VENDOR |
|
189.30 |
|
5011 Expenses. |
| 15-4-2011 |
INV4-11 |
VENDOR |
|
105.12 |
|
5011 Expenses. |
| 15-4-2011 |
INV4-11 |
VENDOR |
|
|
294.42 |
2100 Accounts Payable |
| 23-12-2011 |
INV4-11 |
VENDOR |
other 833.60 |
|
299.30 |
1071 PayPal Merchant Account |
| 23-12-2011 |
INV4-11 |
VENDOR |
other 833.60 |
294.42 |
|
2100 Accounts Payable |
| 23-12-2011 |
INV4-11 |
VENDOR |
other 833.60 |
4.88 |
|
4450 Foreign Exchange Gain / Loss |
| 1-1-2012 |
INV4-11 |
VENDOR |
other 833.60 |
160.91 |
|
1071 PayPal Merchant Account |
| 1-1-2012 |
INV4-11 |
VENDOR |
other 833.60 |
|
294.42 |
2100 Accounts Payable |
| 1-1-2012 |
INV4-11 |
VENDOR |
other 833.60 |
133.51 |
|
4450 Foreign Exchange Gain /
Loss |
| |
|
|
|
888.14 |
888.14 |
|
As you can see, the reversal on the Accounts Payable account is correct, but the merchant account isn't what I'd expect. Since I'm simulating last year was already closed when reverting the payment, I can't enter a posting date before 1-1-2012.
The huge FX difference comes from the fictitious rate that I used to post the 1-1 posting. It could be half the rate or less of what was used to post the actual posting.
What I want from the reversal is for it to create a posting which exactly offsets the posting, making it like the posting never happened (cumulatively) - both on the balance as in the P&L. I'm not sure this can be achieved in our current data model though: we have no way of recording the fact that the 2012-1-1 payment should have used the fx rates of 23-12-2011...
Going back and testing that the reversal exactly reverses all posting effects as long as I'm able to post in the given period gives me a positive test result.
As a last and unrelated test result, I seem to have file link issues "all of a sudden" (that is, I've never used the feature and its authorizations seem to start affecting me):
42501:ERROR: permission denied for relation file_links
CONTEXT: SQL function "file__list_links" statement 1
If this is from a recent change, it would probably be good to fix it before we release .11 I've been messing with my system recently though - removing roles from tests having gone haywire. So, it could be those cleanups have affected my system more than I want to.
Hope these tests are in-depth enough for you to have a look at fixing things. If you want me to, I can definitely agree that fixing the data model isn't for the faint of heart in a patch release. Maybe we should move the data model fix part of the payment reversals to the 1.4 release. If we want to release that fix soon but as part of 1.4, we probably want to scale down on the size of 1.4. For me, the fix isn't the most important one, since the posting I want to correct is still in an open period. So I can just post the reversal on the exact same date as the payment.
Bye,
Erik.