-
Notifications
You must be signed in to change notification settings - Fork 7
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
12.0 imp commown integrate contract forecast #210
12.0 imp commown integrate contract forecast #210
Conversation
1b6076d
to
1a98000
Compare
Codecov ReportAttention:
Additional details and impacted files@@ Coverage Diff @@
## 12.0 #210 +/- ##
==========================================
+ Coverage 90.31% 90.47% +0.15%
==========================================
Files 248 254 +6
Lines 8239 8407 +168
Branches 1058 1083 +25
==========================================
+ Hits 7441 7606 +165
- Misses 628 632 +4
+ Partials 170 169 -1 ☔ View full report in Codecov by Sentry. |
c0be09c
to
85efd24
Compare
0fc4ca6
to
3b13dab
Compare
61c1591
to
bc4cd40
Compare
7dc8d0d
to
c628c46
Compare
c628c46
to
2f87fa9
Compare
/ocabot rebase |
We use the dedicated trap_jobs context manager to get the jobs generated in the tests. Before that, jobs added by contract_forecast install hook were interfereing.
This commit requires pull requests to contract_forecast and queue_job.
Note editing a discount does not trigger the recomputation for now.
For the moment, commown_contract_forecast does not depend on any accounting setup module, so the tests that generate invoices crashes. This commit fixes that by inserting odoo-maintained minimal account data to avoid this.
It is now replaced by the more general contract_forecast module.
Each fees period dict is added a new "is_forecast" key to ease the choice between invoices and forecasts in the proportional fees_type computation.
These fields will be useful for forecast analysis and management decision making.
They will be useful to analyse them.
Also use the run_datetime field instead of today().
When the fees computation date is in the future, the objective is likely to analyze the fees detailed results. This is much easier graphically, in which case we assume that the fees will be invoiced monthly and not at the end of a fees period, which is meaningless for the end user. This is why we split the fees period into months and store that in the computation details table.
Congratulations, PR rebased to 12.0. |
2f87fa9
to
e4870ec
Compare
/ocabot merge patch |
This PR looks fantastic, let's merge it! |
Congratulations, your PR was merged at 3a79721. Thanks a lot for contributing to commown. ❤️ |
No description provided.