Its common to import a file contaning all the moves of a statement, especially if this statement is a bank or a online system one. When introduced to tryton, each of this move will be mapped to one or more statement lines.
Proposal
Create a new ‘account.statement.origin’ Model which will be filled by the process of importing this file. This model will have the following fields:
Name: Required Char
Date: Required Date
Amount: Required Numeric
Description: Optional Text
Party: Optional Many2One
Account: Optional Many2One
On the statement lines a new Many2One field referencing the origin will be added. This filed should be invisible when not set and if set the account will not be required on draft state.
When changing the lines amount, if the record is related to an origin, a new line will be created to match the origin amount, similar in what is done now with the invoice field.
A new wizard for importing the files will be added. This wizard will ask for the file format and file to be imported. It will create draft statements filled with origins.
For me, only the amount should be required if we want to be flexible when importing.
Also this should be readonly once the user start to assign account.
I think the workflow in this case will be to create statement lines from within a One2Many on origin. Those lines will need to have default values according to the origin values.
It should also possible to post line per line if the import is used because the checks are already ensured.
I do not think we need to have a CSV import wizard because this already exist in the client.
So you propose to possible workflows for statements? The current one with lines and a new one based on origins. I’m wondering if we should hide the lines if there are origins on the statement, as then the lines should be created for origins and not manually.
I’m just curious, are there any checks on duplicates? Normally we go to the website of our bank and:
Log in with special token
Go to the bank account export tool on the website
Select the account number to export
Select start-date and end-date
Select format
Export, store the file on disk
Import into Tryton
As you can see we can export different statement lines multiple times on different bank statements, because we set manually the start and end date.
Another thing is, because in most (if not all) export formats the account number of the party is available. It would be nice to check on import if we can find a party with that account number. Also when a user has added a party to the statement line, it would be nice that the account number is stored with that party.
I think validation of already existing statement lines is out of the scope of the initial work described on this blueprint. But this kind of validation can be implemented on a separate module. One of our desing patterns is to avoid constraints on base modules to provide more flexibility.
You are checking for statement lines which is the same module. The only other constraint will be on the account_bank. This can be a separate module.
Another idea is to completely separate the import from the module into a new module with all the extra checks etc. so developers creating new import “filters” only have to return a defined / standardized set of data. We get a more structured flow and less duplicate code and easier creation of import “filters”
For me, I would not call it a statement if your bank does not provide you with only new lines.
I know Paypal only propose such “date range” export (but it is not a real bank) so for the Foundation I have to wait the end of the month to make retrieve the statement.
So the only constraint that could be added will be a unique constraint on the name but I do not think every banks give a unique numbering for statement line.
So this will stay to the responsibility of the user to follow clear work-flow.
We get the ability to create a statement ourselves which is nice when something did go wrong.[quote=“ced, post:11, topic:179”]
So the only constraint that could be added will be a unique constraint on the name but I do not think every banks give a unique numbering for statement line.
So this will stay to the responsibility of the user to follow clear work-flow.
[/quote]
Humans makes mistakes, mostly because it became routine. Tryton can take action to prevent mistakes because it is software. (And when Tryton does something wrong we call it a bug ) . IMO workflow helps people to do their work, but cannot take action when something goes wrong. Basically workflow is the first line of defense, Tryton the last line.
Accidentally import a wrong selected file. Hash origin lines with date, accountnumber and amount. Make that hash-field unique with a SQL-constraint. With an early (database hungry?) check, Tryton can remove those lines from the list, or later when the lines are stored, raise a user-warning that several lines already exists and won’t be saved.
For me, it can happen that you receive the same day two payment from the same account (there is not always an account) and for the same amount. For example, in case of renting a direct debit could be used for all the rental of a customer.
It is always wrong to put constraint on external data because you just do not master them and others always fail at respecting their promises.
I think we need to also add the party as optional field. Because the parsed statement could contain unambiguous values (like bank account etc.)
Also I think we should add an optional account because the parser could find using for example a “structured communication” which move line the statement is paying.
I think such data should be deducted from the parsed statement.
I have worked already with 3 statement formats (MT940, CODA and CAMT.053) and they all provide those information.
Ok, for the name and the date, but not for the journal as it’s the user who decides on which journal want’s to import the statement.
From my side it’s ok, to add the party and the account as optionals fields, and let the parsers fill them if available. As much info as it can be prefilled, the better for the user.
I do not think so. All the three formats have the account number information and statement should always use the same journal for the same account. So I think we must have a way to find the journal using the account number. Maybe we could simply add a Many2One from the journal to a bank account.
) . IMO workflow helps people to do their work, but cannot take action when something goes wrong. Basically workflow is the first line of defense, Tryton the last line.