Merge lp:~acsone-openerp/banking-addons/bank-statement-reconcile-70-import-statement-hook into lp:banking-addons/bank-statement-reconcile-70

Proposed by Laurent Mignon (Acsone)
Status: Merged
Approved by: Pedro Manuel Baeza
Approved revision: 113
Merged at revision: 116
Proposed branch: lp:~acsone-openerp/banking-addons/bank-statement-reconcile-70-import-statement-hook
Merge into: lp:banking-addons/bank-statement-reconcile-70
Diff against target: 202 lines (+36/-49)
4 files modified
account_statement_base_completion/statement.py (+4/-5)
account_statement_base_import/parser/parser.py (+13/-32)
account_statement_base_import/statement.py (+14/-11)
account_statement_commission/commission.py (+5/-1)
To merge this branch: bzr merge lp:~acsone-openerp/banking-addons/bank-statement-reconcile-70-import-statement-hook
Reviewer Review Type Date Requested Status
Pedro Manuel Baeza Approve
Review via email: mp+203127@code.launchpad.net

This proposal supersedes a proposal from 2014-01-15.

Description of the change

Hi,

In some cases, the imported file may contains information about the account.bank.statement.
The proposal add a new method 'get_st_vals' on the 'BankStatementImportParser' that can be used to provide statement info from the parsed file and a new method 'prepare_statement_vals' on 'AccountStatementProfil' that fills the statement values with the profile_id and the result to the call to the new method on the parser.

To post a comment you must log in.
Revision history for this message
Pedro Manuel Baeza (pedro.baeza) wrote : Posted in a previous version of this proposal

Hi, Laurent, very interesting and needed changes!

I was to say that you have made the MP to the wrong branch, but you corrected at the moment!

I have checked the code, and the solution seems perfect for Spain, where I'm adopting national standard statement format in 7.0 to these addons, and there is information about start and end date of the statement in the file that must be dumped.

Regards.

review: Approve
Revision history for this message
Pedro Manuel Baeza (pedro.baeza) wrote : Posted in a previous version of this proposal

Hi, Laurent,

Checking pending MPs, I have found that there is already an MP that issues this problem in a similar way:

https://code.launchpad.net/~akretion-team/banking-addons/bank-statement-reconcile-70-improve-import/+merge/197759

So I'm going to put this as rejected and let the other MP continues. Please review it to contribute with your comments.

Regards.

review: Disapprove
Revision history for this message
Laurent Mignon (Acsone) (lmi) wrote : Posted in a previous version of this proposal

> Hi, Laurent,
>
> Checking pending MPs, I have found that there is already an MP that issues
> this problem in a similar way:
>
> https://code.launchpad.net/~akretion-team/banking-addons/bank-statement-
> reconcile-70-improve-import/+merge/197759
>
> So I'm going to put this as rejected and let the other MP continues. Please
> review it to contribute with your comments.
>
> Regards.

Hi,

Thanks for the review and the link to the other proposal. I'm a little bit disappointed by your decision. I've the feeling that the proposed approach is more generic that the one proposed by akretion-team.

In the other proposal, it's not the responsibility of the parser to provide additional values to the statement creation. So if I want to provide an other value from the parser to statement (ex the date), I need to override the statement profile. My point of view is that's the responsibility of the parser to provide values for statement and statement line creation. The profile is just there to make the glue between the parser and the logic. What do you think?

Regards

lmi

Revision history for this message
Yannick Vaucher @ Camptocamp (yvaucher-c2c) wrote : Posted in a previous version of this proposal

In a way other MP was created and Approved before this one. So disapproving this one seems fair.

However, your changes and improvements are welcome.

Sorry that it wasn't noticed by anybody before. BTW good catch Pedro

Revision history for this message
Pedro Manuel Baeza (pedro.baeza) wrote : Posted in a previous version of this proposal

Sorry Laurent if I bother you. Please contribute now with a new MP over the merge changes with your improvements, that indeed are good ones! I want to make a new MP tonight, but I think it's better that you make it and get credited.

Regards.

Revision history for this message
Pedro Manuel Baeza (pedro.baeza) wrote :

Now I see redundant to add two methods for the same purpose: get_st_vals and prepare_statement_vals. Do you agree to merge both on one? If you do, I will make inmediately an exceptional merge to fix the mess I did merging the other one without consensus.

Regards.

review: Needs Information
Revision history for this message
Laurent Mignon (Acsone) (lmi) wrote :

Hi Pedro and once again thanks for the review.
> Now I see redundant to add two methods for the same purpose: get_st_vals and
> prepare_statement_vals. Do you agree to merge both on one?
The change mirrors the approach for statement lines with the same approach for the statement.
* on the parser we have 'get_st_line_vals' vs 'get_st_vals'
* on the account.statement.profile we have 'prepare_statetement_lines_vals' vs 'prepare_statement_vals'
The motivation behind the 'prepare_statement_vals' is to make a place where it's possible to complete/validate data from the parser in the context of Openerp without overriding the 'statement_import' method. Take a look at the profile developed to import statement files specific to Belgium http://bazaar.launchpad.net/~acsone-openerp/+junk/coda-completion/view/head:/account_statement_coda_import/statement.py#L84 . I think it's a good illustration of the motivation behind the 'prepare_statement_val'. What do you think?

Regards,

Laurent Mignon

Revision history for this message
Pedro Manuel Baeza (pedro.baeza) wrote :

Hi, I proceed then with the merge. Sorry for the past inconveniences.

Regards.

review: Approve

Preview Diff

[H/L] Next/Prev Comment, [J/K] Next/Prev File, [N/P] Next/Prev Hunk
1=== modified file 'account_statement_base_completion/statement.py'
2--- account_statement_base_completion/statement.py 2014-01-23 08:44:24 +0000
3+++ account_statement_base_completion/statement.py 2014-01-24 17:16:24 +0000
4@@ -184,7 +184,7 @@
5 inv = self._find_invoice(cr, uid, line, inv_type, context=context)
6 if inv:
7 # FIXME use only commercial_partner_id of invoice in 7.1
8- # this is for backward compatibility in 7.0 before
9+ # this is for backward compatibility in 7.0 before
10 # the refactoring of res.partner
11 if hasattr(inv, 'commercial_partner_id'):
12 partner_id = inv.commercial_partner_id.id
13@@ -418,7 +418,7 @@
14 """
15 statement_line_obj = self.pool['account.bank.statement.line']
16 model_cols = statement_line_obj._columns
17- sparse_fields = dict([(k , col) for k, col in model_cols.iteritems() if isinstance(col, fields.sparse) and col._type == 'char'])
18+ sparse_fields = dict([(k, col) for k, col in model_cols.iteritems() if isinstance(col, fields.sparse) and col._type == 'char'])
19 values = []
20 for statement in statement_store:
21 to_json_k = set()
22@@ -429,10 +429,9 @@
23 serialized = st_copy.setdefault(col.serialization_field, {})
24 serialized[k] = st_copy[k]
25 for k in to_json_k:
26- st_copy[k] = simplejson.dumps(st_copy[k])
27+ st_copy[k] = simplejson.dumps(st_copy[k])
28 values.append(st_copy)
29 return values
30-
31
32 def _insert_lines(self, cr, uid, statement_store, context=None):
33 """ Do raw insert into database because ORM is awfully slow
34@@ -456,7 +455,7 @@
35 when cheking security.
36 TODO / WARM: sparse fields are skipped by the method. IOW, if your
37 completion rule update an sparse field, the updated value will never
38- be stored in the database. It would be safer to call the update method
39+ be stored in the database. It would be safer to call the update method
40 from the ORM for records updating this kind of fields.
41 """
42 cols = self._get_available_columns([vals])
43
44=== modified file 'account_statement_base_import/parser/parser.py'
45--- account_statement_base_import/parser/parser.py 2013-12-11 19:11:44 +0000
46+++ account_statement_base_import/parser/parser.py 2014-01-24 17:16:24 +0000
47@@ -20,7 +20,6 @@
48 ##############################################################################
49 import base64
50 import csv
51-from datetime import datetime
52
53
54 def UnicodeDictReader(utf8_data, **kwargs):
55@@ -115,6 +114,19 @@
56 """
57 return NotImplementedError
58
59+ def get_st_vals(self):
60+ """
61+ This method return a dict of vals that ca be passed to
62+ create method of statement.
63+ :return: dict of vals that represent additional infos for the statement
64+ """
65+ return {
66+ 'name': self.statement_name,
67+ 'balance_start': self.balance_start,
68+ 'balance_end_real': self.balance_end,
69+ 'date': self.statement_date
70+ }
71+
72 def get_st_line_vals(self, line, *args, **kwargs):
73 """
74 Implement a method in your parser that must return a dict of vals that can be
75@@ -155,37 +167,6 @@
76 self._post(*args, **kwargs)
77 return self.result_row_list
78
79- def get_start_balance(self, *args, **kwargs):
80- """
81- This is called by the importation method to set the balance start
82- amount in the bank statement.
83- return: float of the balance start (self.balance_start)
84- """
85- return self.balance_start
86-
87- def get_end_balance(self, *args, **kwargs):
88- """
89- This is called by the importation method to set the balance end
90- amount in the bank statement.
91- return: float of the balance end (self.balance_end)
92- """
93- return self.balance_end
94-
95- def get_statement_name(self, *args, **kwargs):
96- """
97- This is called by the importation method to set the statement
98- name in the bank statement.
99- return: string of the statement name (self.statement_name)
100- """
101- return self.statement_name or '/'
102-
103- def get_statement_date(self, *args, **kwargs):
104- """
105- This is called by the importation method to set the statement
106- date in the bank statement.
107- return: datetime of the statement date (self.statement_date)
108- """
109- return self.statement_date or datetime.now()
110
111 def itersubclasses(cls, _seen=None):
112 """
113
114=== modified file 'account_statement_base_import/statement.py'
115--- account_statement_base_import/statement.py 2013-12-04 17:39:04 +0000
116+++ account_statement_base_import/statement.py 2014-01-24 17:16:24 +0000
117@@ -90,7 +90,7 @@
118 statement_id, context):
119 """
120 Hook to build the values of a line from the parser returned values. At
121- least it fullfill the statement_id and account_id. Overide it to add your
122+ least it fullfill the statement_id and account_id. Override it to add your
123 own completion if needed.
124
125 :param dict of vals from parser for account.bank.statement.line (called by
126@@ -126,14 +126,14 @@
127 values['type'] = 'general'
128 return values
129
130-
131- def _prepare_statement_vals(self, cr, uid, prof, parser, context=None):
132- return {
133- 'profile_id': prof.id,
134- 'name': parser.get_statement_name(),
135- 'balance_start': parser.get_start_balance(),
136- 'balance_end_real': parser.get_end_balance(),
137- }
138+ def prepare_statement_vals(self, cr, uid, profile_id, result_row_list, parser, context):
139+ """
140+ Hook to build the values of the statement from the parser and
141+ the profile.
142+ """
143+ vals = {'profile_id': profile_id}
144+ vals.update(parser.get_st_vals())
145+ return vals
146
147 def statement_import(self, cr, uid, ids, profile_id, file_stream, ftype="csv", context=None):
148 """
149@@ -168,8 +168,11 @@
150 _("Column %s you try to import is not "
151 "present in the bank statement line!") % col)
152
153- st_vals = self._prepare_statement_vals(cr, uid, prof, parser, context=context)
154- statement_id = statement_obj.create(cr, uid, st_vals, context=context)
155+ statement_vals = self.prepare_statement_vals(cr, uid, prof.id, result_row_list, parser, context)
156+ statement_id = statement_obj.create(cr, uid,
157+ statement_vals,
158+ context=context)
159+
160 if prof.receivable_account_id:
161 account_receivable = account_payable = prof.receivable_account_id.id
162 else:
163
164=== modified file 'account_statement_commission/commission.py'
165--- account_statement_commission/commission.py 2013-12-04 14:14:56 +0000
166+++ account_statement_commission/commission.py 2014-01-24 17:16:24 +0000
167@@ -2,9 +2,11 @@
168 import datetime
169 from openerp.osv import orm, fields
170
171+
172 def float_or_zero(val):
173 return float(val) if val else 0.0
174
175+
176 class AccountStatementProfil(orm.Model):
177 _inherit = "account.statement.profile"
178
179@@ -22,7 +24,7 @@
180 commission_analytic_id = profile.commission_analytic_id and profile.commission_analytic_id.id or False
181 comm_values = {
182 'name': 'IN ' + _('Commission line'),
183- 'date': parser.get_statement_date(),
184+ 'date': parser.get_st_vals().get('date') or datetime.datetime.now(),
185 'amount': global_commission_amount,
186 'partner_id': partner_id,
187 'type': 'general',
188@@ -36,6 +38,7 @@
189 statement_line_obj = self.pool.get('account.bank.statement.line')
190 statement_line_obj.create(cr, uid, comm_values, context=context)
191
192+
193 class AccountStatementLineWithCommission(orm.Model):
194 _inherit = "account.bank.statement.line"
195 _columns = {
196@@ -45,6 +48,7 @@
197 serialization_field='additionnal_bank_fields'),
198 }
199
200+
201 class CreditPartnerStatementImporter(orm.TransientModel):
202 _inherit = "credit.statement.import"
203

Subscribers

People subscribed via source and target branches