Skip to content

[19.0][MIG] hr_expense_advance_clearing: Migration to 19.0#358

Open
dnplkndll wants to merge 44 commits into
OCA:19.0from
ledoent:19.0-mig-hr_expense_advance_clearing
Open

[19.0][MIG] hr_expense_advance_clearing: Migration to 19.0#358
dnplkndll wants to merge 44 commits into
OCA:19.0from
ledoent:19.0-mig-hr_expense_advance_clearing

Conversation

@dnplkndll

@dnplkndll dnplkndll commented May 28, 2026

Copy link
Copy Markdown

Port of hr_expense_advance_clearing from 18.0 to 19.0 (migration guide). Substantive redesign: 19.0 removed hr.expense.sheet, so the module moves from a sheet-based to a per-expense data model.

Non-mechanical adaptations worth flagging

  • expense_type Selection (expense | advance) on hr.expense replaces the 18.0 sheet-level advance boolean.
  • clearing_advance_id (m2o) + clearing_expense_ids (o2m) replace the sheet's advance_sheet_idclearing_sheet_ids link — now per-expense.
  • Clearing posts as a journal entry, not a vendor bill. _prepare_receipts_vals is overridden so a clearing expense books as an entry (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 in action_post. This restores the 18.0 sheet accounting on the per-expense flow — core would otherwise post the clearing as an in_receipt purchase bill.
  • hr.employee inherited directly (18.0's hr.employee.base abstract was dropped in 19.0); smart button mirrored onto hr.employee.public.
  • Sheet view inheritance dropped; views target hr.expense form/search (+ Advance / not-cleared / Clearing filters).
  • account.move._compute_amount resolves the clearing link via expense_id.clearing_advance_id instead 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-level advance/av_line_id fields survive core's sheet removal and map to expense_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/clearing in core hr_expense.py); distinct from core's action_pay.

@OCA-git-bot OCA-git-bot added series:19.0 mod:hr_expense_advance_clearing Module hr_expense_advance_clearing labels May 28, 2026
@dnplkndll dnplkndll force-pushed the 19.0-mig-hr_expense_advance_clearing branch 2 times, most recently from 247ba4c to 30c32a6 Compare May 29, 2026 20:22
kittiu and others added 25 commits May 29, 2026 16:37
[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)
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 c77a2bc)
(cherry picked from commit 26e9383)
Saran440 and others added 6 commits May 29, 2026 16:37
…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)
@dnplkndll dnplkndll force-pushed the 19.0-mig-hr_expense_advance_clearing branch 4 times, most recently from 2868181 to 8d34ecc Compare May 30, 2026 18:20
@haivanlive

Copy link
Copy Markdown

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:

  1. Intermediary Receivable Accounts: When an intermediary receivable account is involved in the advance-clearing flow, forcing a Vendor Bill workflow creates unnecessary friction and breaks the natural accounting logic.
  2. Journal Entries on Clearing: When posting the clearing advance entry, it is automatically converted into a Vendor Bill. This results in an excessively high volume of journal entries and overly complex booking lines, which heavily complicates financial auditing and reconciliation.

Given that advance clearing should ideally be handled via flexible journal entries (entry type) rather than strictly as supplier invoices, could we please reconsider this design? Forcing everything into Vendor Bills makes the accounting distribution far more complex than it needs to be.

Looking forward to your thoughts on this!

@dnplkndll dnplkndll force-pushed the 19.0-mig-hr_expense_advance_clearing branch 2 times, most recently from b72cfc4 to ac28578 Compare June 19, 2026 20:36
@dnplkndll

Copy link
Copy Markdown
Author

@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.
@dnplkndll dnplkndll force-pushed the 19.0-mig-hr_expense_advance_clearing branch from ac28578 to 1335c55 Compare June 19, 2026 21:41
@dnplkndll dnplkndll marked this pull request as ready for review June 20, 2026 13:53
@haivanlive

Copy link
Copy Markdown

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:

  1. Clear Advance
    Status: Working as expected. The clearing process via journal entries looks good.

  2. Employee Advance Journal & Purchase Receipt Issue
    Issue: When creating an Employee Advance and posting the journal entry, Odoo forces a wizard selecting the Purchase journal and generates a Purchase Receipt (in_receipt).
    Accounting Impact: This is accounting-wise incorrect. Employee advances should not be treated as a commercial supplier invoice/purchase receipt.
    Suggestion: We should have an option (or default behavior) to route the Employee Advance creation into a Miscellaneous Operations journal (General Journal) instead of forcing a Purchase journal.
    Proposed Entry: The posted journal entry should be a clean miscellaneous entry:

  • Debit: Employee Advance account
  • Credit: Outstanding Payments
    Once this entry is fully reconciled/matched with the bank payment lines, the status of the Employee Advance record should automatically transition to Paid.
  1. Return Advance Bug
    Error: When trying to process a Return Advance, the system throws the following traceback:

"The register payment wizard should only be called on account.move or account.move.line records."

@Saran440

Copy link
Copy Markdown
Member

dnplkndll and others added 4 commits June 30, 2026 08:32
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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

mod:hr_expense_advance_clearing Module hr_expense_advance_clearing series:19.0

Projects

None yet

Development

Successfully merging this pull request may close these issues.