openerp-expert-accounting team mailing list archive

[Ferdinand Gassauer <office@xxxxxxxxxx>]

Hi Jan!
Thanks for your valid comments. 
I CC the answer to the list too

I was primarily talking about manual data entry and for this the form is 
hardly usable.
For very low volume it's probably faster to enter data manually if paper bank 
drafts are available.
And for cash it's a must.

I'll have a look a look into your module once it is finished (~ release date 
?)

BTW will it be easy to adapt the module to local/national specs of the data 
interchange format ?

camp2camp has probably a module for Switzerland 

Pls see comments down in the text

> Hi Ferdinand,
> 
> I'm not sure I get you right, but there are 2 projects ongoing for 
> automatic bankimport, thus not directly Entries by Statement.
> Nevertheless the bankimport will fill the Entries by Statement form, 
> which needs to be confirmed.
> 
> First project is directly for our customer, where we have taken the 
> account_bankimport module in community-addons as basis.
> The code was crappy and did check for e.g. mt940 format only 5 kind of 
> transaction, where we could have 64 transaction types.
> We haven build that into a filter, added logging, added additonal 
> checks, can import bankfile from desktop instead of server share, do 
> split transactions into the right Entry by Statement if transaction 
> period (based on date) require this.
> Jeroen van der Waal is working on this en this module will be published 
> on LP when finished. He has to clean the crappy code from the base as we 
> do not want to be associated with that previous code ;-)
> 
> The second project running is led by Pieter J. Kersten called Account 
> Banking Framework https://launchpad.net/account-banking
> This is a total different approach where I had together with Pieter and 
> Jeroen several discussions about.
> Pieter has uploaded his development to receive some feedback from the 
> community and he has ;-)
> It is build up from stretch and as far I can see very clean. But it has 
> some caveats as it has forgotten the cash payments yet!! But the module 
> is still in development and could be after a while. It doesn't use the 
> Entries by Statement form, but has it's own logic to generate then 
> account transactions, mostly fully automatic as far as there is some 
> logic to match a payment to an invoice or customer. If the logic is 
> wrong, your transaction will be wrong in ERP. So yes, I like the 
> approach but I can't control that much yet.
> 
> One problem community discovered was the database commit in the number 
> generation function. This influenced the Entries by Statement processing 
> due to a single error line, which commits all lines before the error 
> (comitted with number generation for the transaction number) This is 
> solved last week in stable.
No. The problem you mention is a technical (solved) problem independent from 
user errors I am talking about.
For ergonomic reasons a user must see and match the number with the one on the 
paper and then confirm/commit.

> So the shortcoming you mentions about date must generate period, we have 
> tckeld into the bankimport module. but still with manual input one face 
> this problem.
Yes
> The other shortcomings you mention i don't see directly as shortcoming 
> as long every transaction/account.move has it's own transaction number, 
> and currently this is the case or do I mis something here?
Yes - the next journal number is old Journal number + number of lines in the 
old journal, which is wrong. 
> 
> Regarding net/vat lines into a statement we can debat. In my opinion, 
> user has to insert invoices in ERP first for every buy or sell. The vat 
> is handled automatically by the invoice and Entries by Statement is used 
> to pay or accept the payment linked to a partner and reconcile.
> Only bankingcost are normally not invoiced and directly debited from 
> your bankstatement so that will normally the only transaction in a 
> statement file that will be directly linked here to a cost account. All 
> other transaction link to a debitor ar creditor.
I agree for bank statements, but not for petty cash. 
IMHO No one will  treat restaurant, transport bills etc as separate invoices 
(except all this is handled in hr_expenses )

> If you work this way, on the invoice you have the option to add a 
> analytic-account for every invoice line, so that problem is solved too.
Yes
> If I read your email well, you try to make the statement more like a 
> invoice, and that would be wrong. A statement is normally used to 
> reflect cash or bank transactions only and if everything went wright 
> there should be a equivalent (a invoice) in the ERP system.
Yes but not petty cash
> 
> Stands open the calculation for difference between start-end balance of 
> statement, indeed this could be improved.
Good
> 
> And b.t.w. teh statement file is only used to generate the account.move 
> transactions and are more less stand-alone records. After the statement 
> is processed and the real transactions are into the system, the 
> statement files can be deleted!! If this is correct is another question 
> as in my opinion the should be left for controlling tasks.
absolutely. it must not be deleted. 
> 
> If I missed your point you want to make, please reply.
> 
-- 
regards
Ferdinand Gassauer
ChriCar Beteiligungs- und Beratungs- GmbH
Official OpenERP Partner