On 25/10/12 11:50 +0200, Albert Cervera i Areny wrote: > 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 search for each fields you have but you can not do that in a generic way because each format will give you a specific set of information. > >> 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. I don't understand the scenario. If the user has already imported the file and have tuned it. Why does he need to do it again? By the way, it is the best way to miss a line in the import process. Being KISS on this is really important for correctness. > >> 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. If this is really what can happen (not in Belgium (knonw for its banks :-) because you can not retreive twice the same statement) than there is a problem in the workflow. You must have a way to retrieve statements that were not yet retreived otherwise there is no way to ensure correctness. In Tryton, we must force users to use the right way and not trying the correct it afterwards. -- 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/
pgpz1ukDFDxGE.pgp
Description: PGP signature
