Rules for imported statement

accounting

(CĂ©dric Krier) #1

Rational

With Import Statement Files, it is easy to import statement but the user still have to create statement lines from origins. In many cases, such work could be automated with some rules using the imported data like the description or informations.

Proposal

A new model account.statement.rule is created which is composed of two parts: matching criteria for origin and lines template.
A button on the account.statement loop over all the origin lines without any statement line (to allow to run it multiple times without losing previous customization). It tries to find the first matching rule and then apply the template to create lines.

Criteria

  • Company: ManyOne (optional)

  • Journal: Many2One (optional)

  • Amount: range (optional) (in journal currency)

  • Description: Regular expression

  • Information: One2Many

    • Key: Many2One (account.statement.origin.information)
    • Criteria:
      If key is Char: regexp
      If key is Selection: Selection
      If key is Boolean: Boolean
      if key is Integer, Float, Numeric: range

All filled criteria must be valid to match a line.
The regexp are evaluated using re.search so a simple string will match even if the value does not start with it. Group name can be used to define party, bank_account, invoice, payment and payment_group which could be use as rec_name search for line template.

Lines template

A list of line template similar to the account.move.template.

  • Amount: formula based on amount and pending_amount
  • Party: Many2One (if not filled, use group name party to search for one)
  • Account: Many2One (if not filled, use the party receivable or payable depending on the sign)

Invoice, Payment and Payment Group are set using the respecting group name.
The group name are taken first from the description and then on each information regexp.

Implementation

https://bugs.tryton.org/issue7925


Newsletter February 2019
(albert) #2

I think amount should be a formula just like in product_price_list [1]. It is quite usual to have fixed amount which could not be managed by %.

Convenient variables for the formula would be “total_amount” and “pending_amount” (that’s what we are using in [2]). It is also very flexible because it could allow other modules to implement new variables such as “bank_default_commission” that could be stored in the journal, for example.

This way if you know that all origin lines with the text “COMMISSIONED PAYMENT” have an expense of 2€ you can create two lines:

  • One with the 2€ to “Bank Expense Account”
  • The other one with the “pending_amount” to “Some other account”

Also, for me, it is not necessary to ensure that the 100% is spread because user may want to automate only half of the origin line. Again, if the line contains the text “COMMISSIONED” the user may want to create one line of 2€ to “Bank Expense Account” automatically but leave the pending amount to be introduced manually.

[1] modules/product_price_list: 6deeb2b8d49f price_list.py
[2] https://bitbucket.org/nantic/trytond-account_bank_statement_rule/src/a8110cd5f6bd4bc2a6046b0d701c9738e81512a8/statement.py#lines-83


(CĂ©dric Krier) #3

For me, it can not have pending_amount as the rule applies only on empty origin.


(albert) #4

You can if you add a sequence to Lines Template list. This way Tryton will process those lines in the given order and so you can do what I mentioned in the example:

  • First line sets a fixed amount of 2€
  • Second line uses “pending_amount” which is the total amount of the origin minus the amount already used in previous lines already processed (2€ in the example)

(CĂ©dric Krier) #5

OK but it should be computed in the fly as the lines will not be stored directly.


(Sergi Almacellas Abellana) #6

I think this wizard should be automatically executed after importing a statement file so all the rules are applied.


(CĂ©dric Krier) #7

I do not think because we need to allow user to run it when he wants. For example if he changed some rules, he may want to re-run it. So for me, it is a better workflow to always have the same workflow.
Now on automatized operation like Continuous importation of bank statement this wizard should be run automatically.


(CĂ©dric Krier) #8

Indeed I think it could be a button instead of a wizard because there is no interaction with the user.


(CĂ©dric Krier) #9

The patch of Issue 7925: Account Statement Rule - Tryton issue tracker is ready for testing.


(CĂ©dric Krier) closed #10

This topic was automatically closed after 14 days. New replies are no longer allowed.