2012/10/25 Cédric Krier <[email protected]>: > On 25/10/12 10:44 +0200, Albert Cervera i Areny wrote: >> I've created a Blueprint here: >> >> http://code.google.com/p/tryton/wiki/StatementImport >> >> Comments are very welcomed! > > I don't see the need of such infrastructure. > >> Store the bank statement keeping the same data provided by the bank > > It just needs to create a Binary field to store the imported file on the > statement. I think it is better to have one field per format so each > module that adds support for 1 format should create it.
I thought of using attachments. But I'm ok with a binary file too. >> Rule system to ease and automate the process of finding invoices and >> reconciliation or determining accounts to use > > I think we already have it: search_rec_name The problem is that bank statment file can contain several fields not just one. Hence search_rec_name is not appropriate to handle this. For example, some information that can be found (optionally) is the description of the line, the VAT number of the sender/receiver, as well as extra information. This already exists in AEB43 and I guess others will have something similar. So what we need is in one hand a way to extract information from different file formats and put them in some kind of properties or attributes. And then another process that has the logic for determining each line which account, party and invoice is appropriate. >> Rule system should be extensible > > search_rec_name can be extended. > >> Allow reverting and redoing the process by bank statement line => Full >> traceability of information from statement lines to imported (bank >> provided) statement lines. > > The wizard that will import the file has to clean the statement before. Say you import a bank statement and you missed several invoices before importing it. If we force the user to remove all lines (by re-importing the file), any manual changes he may have done are lost. The idea is that we import the original bank lines and those create one or more statement lines. Those can be removed and recreated but only the ones needed. >> Independent of file format > > One wizard per format. > >> Manage duplicate lines if dates or lines of two imported files overlap > > I don't get you. If the bank send you 2 files with similar lines then > you have to import both of them. You must reflect what the bank tells > you. If it is a mistake of the bank than they should send you a new > statement with correction. At least here, the user is the one that goes to the bank's web pages and asks for the bank statement from one day to another. Say from 01/01/2012 till 21/01/2012. The next day I go to the bank and should ask for the one from 22/01/2012 till 31/01/2012 but what happens if the user makes a mistake and the second time downloads a file from 21/01/2012? I want to detect those duplicates and help the user discard them or, at least, ask him to re-obtain the file starting at 22/01/2012. I personally prefer that only inappropriate lines are discarded because that allows users to download today's statement even if not all moves are available yet. This allows some companies that have online shops and allow payments by bank transfer to integrate bank statements several times a day because they cannot wait until the next day because they usually deliver in 24/48 hours. > > -- > Cédric Krier > > B2CK SPRL > Rue de Rotterdam, 4 > 4000 Liège > Belgium > Tel: +32 472 54 46 59 > Email/Jabber: [email protected] > Website: http://www.b2ck.com/ -- Albert Cervera i Areny http://www.nan-tic.com Tel: 93 553 18 03 Twitter: @albertnan -- [email protected] mailing list
