-
-
Notifications
You must be signed in to change notification settings - Fork 118
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
[17.0][WIP] account_factoring_receivable_balance #555
base: 17.0
Are you sure you want to change the base?
Conversation
03c79b7
to
75fc74b
Compare
b5be4a6
to
033f39a
Compare
ADD oca style settings FIX misc pylint UPD copier
@Murtaza-OSI Smart button is fixed and lines are correct in CC: @dreispt |
…france into 17-dr-factofrance
Thanks for porting this module. Nice Improvements I asked myself if this module, is not generic enough to move an account OCA repository ? Happy to hear there |
08633bd
to
bd299ff
Compare
bd299ff
to
86dd4e4
Compare
…ssing related field
[FIX] account_factoring_receivable_balance_factofrance: Constraint missing related field
@dreispt as I proposed But it can be done at the end of your process here |
@bealdav I agree in principle, but in the immediate term it is easier to work and refactor if they are in the same repo. |
factor_journal_id = fields.Many2one( | ||
comodel_name="account.journal", | ||
string="Journal", | ||
domain="[('factor_type', '!=', False)," "('type', '=', 'bank')]", |
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.
@dreispt
In my experience (minor) but the journal associated to account.move used to send data to factor etablishment (invoices and credit notes) can be a misc
one.
In this kind of journal you have not a lot settings, then it's less confusing to use this kind in a such context.
At least, we may consider to offer a choice.
A bank type is require to produce moves with statements data, that's not the same flow
Don't you think Daniel ?
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.
@bealdav Good question, this was something I struggled with.
For FactoFrance we need to also report the payments on Invoices.
So I settled with using a Bank journal, allowing you to post payments on factored invoices.
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.
@bealdav Good question, this was something I struggled with.
For FactoFrance we need to also report the payments on Invoices.
So I settled with using a Bank journal, allowing you to post payments on factored invoices.
@dreis for Factofrance I strongly recommend you look at this other module I did initially, it is used in production since 3 years in a very big company and was designed for FactoFrance: https://github.com/akretion/odoo-factoring/tree/14.0/account_factoring
You can find a demo here: https://youtu.be/N7x7MtfEF1g?si=0FbU3P1O8Iv8MgzE
|
||
factor_journal_id = fields.Many2one( | ||
comodel_name="account.journal", | ||
domain="[('factor_type', '!=', False)]", |
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.
Required in multi-company environment
domain="[('factor_type', '!=', False)]", | |
domain="[('factor_type', '!=', False)]", | |
company_dependent=True, |
…de to ASCII replacements
…reference instead if entry number
) | ||
partner_identification_type = fields.Selection( | ||
selection=[("1", "1 SIRET"), ("4", "4 TVA")], | ||
) |
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.
@dreispt FYI in my repo I have made this settings to match with arbitrary factor keys.
May be it could be generic ?
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.
IMO that is a bit complicated.
I would go for the simpler solution, and add those additional settings as fields, only visible for tis Factor Type.
Note that the "Factor Code" is really a "Factor Contract Number", so renaming it could make sense.
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.
It depends on your factor settings, in your case you only have one key but like any carrier dev you may have misc keys with unpredictable name or mean unshareable. If you have several factors for different companies in your ERP it becomes crazy.
But yes, it could be not so generic.
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.
Well, the DB will have all those fields, but the user form would show only the relevant ones for the selected Factor.
Like what the shipping connectors do, as you pointed out.
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.
A matter of taste
Port from https://github.com/akretion/odoo-factoring/tree/16.0 and migration to 17.0
Related to akretion/odoo-factoring#20