-
-
Notifications
You must be signed in to change notification settings - Fork 410
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
8.0 Add module account_bank_statement_import_paypal #7
Conversation
For the parsing question, I would use _() to also translate the string you are using. What do you think? |
vals_line = False | ||
user = self.pool['res.users'].browse(cr, uid, uid, context=context) | ||
company_currency_name = user.company_id.currency_id.name | ||
comission_total = 0.0 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
commission
@pedrobaeza I think it's not as easy as that. For example: I use OpenERP in English because I prefer to use it in english to avoid all the bad French translation and to avoid the mix of translated and untranslated strings. But my Paypal bank statements are in French because Paypal knows I'm from France. I think that the best solution is to have some _prepare method that can be inherited in a country-specific module. It is needed for:
i just implemented it. Tell me what you think. |
You can add then a parameter to say in which language is the file, and use .with_context(lang='...') in all parse calls. |
@pedrobaeza I'm really not sure that using translations is the good answer for this. The problem is that I don't have enough information on Paypal CSV bank statements to decide what is the best solution, that's why I propose to use the prepare*() solution for the moment. |
But this is also not a good option, because this forces to make subsequent account_bank_statement_import_paypal_xx for each language, and with no possibility of mixing paypal files from one language and another. We should provide a configurable mechanism. |
@alexis-via there is a pep8 issue:
And unicodecsv must be added to the travis config. |
…inked to the company of the provided journal PR on master: odoo/odoo#5821
Conflicts: account_bank_statement_import/account_bank_statement_import.py
The new field is computed by sanitzing the acc_number.
Use wildcard on both sides when opertor contains 'like'
….journal created by res_partner_bank.post_write
Add OCA as author, PEP8
By moving the field in the main module the others parsers can use it without duplicate it
[ENH] Might need info in camt import from PmtInfId element.
…t_id OFX: stronger unique_import_id
…ail_account as a bank account
…in name to work with base_transaction_ref
As there's no plans to work on this from the author, I close. Feel free to reopen in case there's interest. |
@pedrobaeza @jbeficent Actually this coould be interesting to fix for the particular case of OCA Paypal Bank Statement. Would it be worth the effort to fix it only for our particular case? |
Well, it's very specific to the downloaded format, but if you pass me a sample, I can check the coincidences. I have set up a variant of this one for an Spanish Paypal statement. |
Thanks I will private email you |
[ADD] more tests, thanks to Louis Bettens
This module is designed for the new bank statement system of the PR #6
This module is certainly not perfect, in particular on the problems of multi-language. The problem is that the Paypal CSV files use strings in the language of the user... and I use a few of those strings in the parsing. But I don't see any easy solution for this...