[19.0][MIG] hr_expense_advance_clearing: Migration to 19.0#358
[19.0][MIG] hr_expense_advance_clearing: Migration to 19.0#358dnplkndll wants to merge 44 commits into
Conversation
247ba4c to
30c32a6
Compare
[UPD] Update hr_expense_advance_clearing.pot [UPD] README.rst (cherry picked from commit 47c7398)
Fix install error when there are already some expense in system. [UPD] README.rst hr_expense_advance_clearing 12.0.1.0.1 (cherry picked from commit 1f3ec1e)
(cherry picked from commit df4f68f)
(cherry picked from commit 00f8f4a)
We should prevent setting the analytic account in expenses used as employees advance. Otherwise, it can lead to errors charging against an analytic account that later won't be compensated when all is reconcile. Anyway, the advance is not an expense, but money of the company moving from one place to another, that later will be used for real expenses that will be imputed to the corresponding analytic account (cherry picked from commit 2723fe7)
(cherry picked from commit 3b75338)
(cherry picked from commit c77a2bc)
(cherry picked from commit 3b9851c)
…oduct (cherry picked from commit c159aff)
(cherry picked from commit 26e9383)
… view (cherry picked from commit 7ada587)
(cherry picked from commit 397249a)
(cherry picked from commit 2d47f02)
(cherry picked from commit e6c8719)
(cherry picked from commit 963dff4)
(cherry picked from commit e680241)
(cherry picked from commit e6d6691)
…ly on new clearing (cherry picked from commit fbbf303)
(cherry picked from commit 9728fd3)
(cherry picked from commit c9ad5bc)
(cherry picked from commit ee44183)
(cherry picked from commit 6f13bc8)
… clearing (cherry picked from commit 8d5a396)
(cherry picked from commit e6bc12d)
(cherry picked from commit c328cfc)
(cherry picked from commit 32354d4)
(cherry picked from commit 9831b13)
(cherry picked from commit 4dcae4d)
…s might intervene. TT55529 (cherry picked from commit 4a89241)
Currently translated at 100.0% (56 of 56 strings) Translation: hr-expense-18.0/hr-expense-18.0-hr_expense_advance_clearing Translate-URL: https://translation.odoo-community.org/projects/hr-expense-18-0/hr-expense-18-0-hr_expense_advance_clearing/it/ (cherry picked from commit 533941a)
…patibility) Since some other modules can introduce other moves to the expense sheet, this refactor allow some compatibility between those modules without changing behavior on this module. (cherry picked from commit 2be9623)
2868181 to
8d34ecc
Compare
|
Hi all, Thank you for your hard work on migrating this module to 19.0! However, looking at the current implementation, forcing the clearing process entirely through the Vendor Bill workflow introduces several major operational limitations:
Given that advance clearing should ideally be handled via flexible journal entries ( Looking forward to your thoughts on this! |
feda464 to
815bf3d
Compare
b72cfc4 to
ac28578
Compare
|
@haivanlive I have added an adaptation ac28578 to try and accomplish this. let me know what you think |
hr.expense.sheet removed in 19.0; retarget to hr.expense (+ hr.employee.base->hr.employee).
The initial 19.0 port let clearing expenses ride core's in_receipt posting, so each clearing raised a vendor bill instead of consuming the advance (the sheet's custom move creation was lost with hr.expense.sheet). Restore the 18.0 accounting on the per-expense flow: - Override _prepare_receipts_vals: clearing expenses post as one `entry` per advance, Dr expense / Cr employee-advance account (capped at the advance's GL residual; any excess to the employee payable). - Reroute the entry to a general journal (core forces the purchase journal) so it reads and numbers as a journal entry. - account.move.action_post reconciles the clearing entry against the advance, consuming it (mirrors 18.0 action_sheet_move_post). - Require the advance posted before clearing it; clamp clearing_residual at 0 for over-cleared advances.
ac28578 to
1335c55
Compare
|
Hi @dnplkndll, Thank you for your hard work on migrating this module to 19.0! Here are some feedback and issues I encountered during testing:
"The register payment wizard should only be called on account.move or account.move.line records." |
|
@dnplkndll Hi, thank you for you migrate to version19. |
Forward-port of OCA#370. The advance smart-button counter is read by non-accounting users; compute it sudo to avoid an access error. Co-authored-by: Saran440 <saranl@ecosoft.co.th>
…ring credit Forward-port of OCA#368, adapted to the 19.0 journal-entry clearing flow (hr.expense.sheet removed): when the advance move carries a single analytic distribution, apply it to the clearing entry's credit line on the employee-advance account so the clearing matches the advance. Co-authored-by: Saran440 <saranl@ecosoft.co.th>
…ance move line Return Advance raised "The register payment wizard should only be called on account.move or account.move.line records" because the wizard was opened with no active_model. Target the advance's open employee-advance line via active_model/active_ids so the returned payment reconciles against it.
…t to draft Forward-port of OCA#369, adapted to the 19.0 journal-entry clearing flow. Resetting a clearing entry to draft ran the invoice tax recompute, which stripped the tax twice and added a spurious Automatic Balancing Line. Reset clearing entries (move_type=entry linked to a clearing expense) with skip_invoice_sync instead. Co-authored-by: Saran440 <saranl@ecosoft.co.th>
Port of
hr_expense_advance_clearingfrom 18.0 to 19.0 (migration guide). Substantive redesign: 19.0 removedhr.expense.sheet, so the module moves from a sheet-based to a per-expense data model.Non-mechanical adaptations worth flagging
expense_typeSelection (expense|advance) onhr.expensereplaces the 18.0 sheet-leveladvanceboolean.clearing_advance_id(m2o) +clearing_expense_ids(o2m) replace the sheet'sadvance_sheet_id↔clearing_sheet_idslink — now per-expense._prepare_receipts_valsis overridden so a clearing expense books as anentry(Dr expense / Cr employee-advance account, capped at the advance's GL residual; any excess to the employee payable), rerouted out of the (core-forced) purchase journal into a general journal, then reconciled against the advance inaction_post. This restores the 18.0 sheet accounting on the per-expense flow — core would otherwise post the clearing as anin_receiptpurchase bill.hr.employeeinherited directly (18.0'shr.employee.baseabstract was dropped in 19.0); smart button mirrored ontohr.employee.public.hr.expenseform/search (+ Advance / not-cleared / Clearing filters).account.move._compute_amountresolves the clearing link viaexpense_id.clearing_advance_idinstead of…sheet_id.advance_sheet_id.Migration of existing data
Existing 18.0 advance/clearing data is migrated in place by
migrations/19.0.1.0.0/— the line-leveladvance/av_line_idfields survive core's sheet removal and map toexpense_type/clearing_advance_id; sheet-only clearings without a line link are logged for manual review.19.0 relevance
19.0 core has no advance/clearing concept (no
advance/clearingin corehr_expense.py); distinct from core'saction_pay.