banking-addons-team team mailing list archive

[James Jesudason <james.jesudason@xxxxxxxxxxxxx>]

On 08/03/12 10:32, Stefan Rijnhart wrote:
> On 03/07/2012 06:06 PM, James Jesudason wrote:
> > One irritating error that I can't seem to track down is this:
> >  * Uncaught Error: Unknown field state in domain [["state","not
> > in",["draft"]]]
> > This happens when a statement line is clicked in the bank statement
> > form. Any ideas?
>
> Had a look with Firebug just now and found out that the web client now
> checks the domain for the readonly attribute from the 'states' parameter
> in the 'amount' column definition even when the whole form is readonly.
> Knowing that it is easily solved by injecting the 'state' field into the
> embedded form on the bank statement form view. I prepared a branch with
> this fix and another fix for the online bank account lookup that is used
> in the Netherlands.
Great - could you create a merge proposal for this?


The current state-of-play on the 6.1 branch (revno 119) is that it is:
 * Matched transactions (automated or manual): when confirmed the moves 
and reconciliation is handled by creating an account.voucher record.
 * Unmatched transactions: when confirmed, the move is generated for 
the account on the statement line. This processing is more-or-less the 
same as standard functionality.

As per the original branch that Stefan created, the statement lines can 
be confirmed one-by-one or altogether (by confirming the whole 
statement. Also, cancellation of the moves is possible (in the journal 
allows cancellation).

The upgrade has focused on the functionality that I'm familiar with and 
can test. Since the module handles a lot more scenarios than we use, I 
cannot test all of them. So, I think it is better if I could ask others 
to start testing this branch and whether we could move to a new phase of 
the upgrade.

These are the main areas that I've focused on:
 * HSBC bank statement import (account_banking_uk_hsbc).
 * Manual matching and clearing the match.
 * Confirming a manual match (which generates an account.voucher).
 * Cancelling a manual-matched posted line (which unreconciles the 
account.voucher and and removes it).
 * Confirming an unmatched line (which generates a journal entry for 
the line).
 * Cancelling the unmatched posted line (which removes the journal entry)

The main area that I haven't been able to test is the matching as the 
rules won't work for our situation. For example, the payment order 
matching needs the remote account on the transaction, but that is not 
available in the HSBC statement import file. However, if the matching is 
working, then posting the line using an account.voucher should work 
without modification (it just needs the move line to be linked to the 
import transaction record)

Other areas that I'm not sure about are the treatment of bank charges- I 
believe that the bank charge invoice is created during the matching 
process. If that's correct, then posting the entry using the 
account.voucher should work fine.

However, it may be that some extra processing may be required for some 
transaction types. Right now, I've assumed that the only thing that 
needs to be done is to post the journal (using account.voucher or a 
journal entry). If extra processing is required for some transaction 
types, then that may need to be added into the Confirm method.

Thanks

James