Skip to content
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

feat: Ledger for advance payment (backport #43709) #43946

Merged
merged 25 commits into from
Nov 4, 2024

Conversation

mergify[bot]
Copy link
Contributor

@mergify mergify bot commented Nov 1, 2024

Issue

System allows advance payment to exceed Sales / Purchase Order grand total.

Consider below scenario,

  1. Sales Order of 10000 /-
  2. Make an Advance Payment of 2000 /-
  3. Make a Partial Invoice (2000 /-) for Sales Order and Reconcile the advance against the invoice
  4. Now, try making an Advance payment of 10000 /-. System allows this. It should've only allowed up to 8000 /-

Current Limitation

This happens because technically there is no distinction between a Normal Payment and an Advance Payment. So there is no persistent data structure to track the Advance Amount received for a Sales / Purchase Order. This distinction is inferred solely based on the allocation. If the Payment is allocated to a Sales / Purchase Order, then it is considered as an Advance Payment.

The problem with this approach is once reconciliation happens, the allocation to Sales / Purchase Order are replaced with an Invoice. So, we loose the critical information: A certain amount was received as an Advance, but it is now allocated to an Invoice.

Solution

A separate ledger to track Advance Payments against Sales Order or Purchase Order that only captures Submit and Cancel events. This way Reconciliation / Un-Reconciliation doesn't affect the advance amount calculation.

Event Ledger Effect
Submit Update
Reconcile -
Unreconcile -
Cancel Update

todo:

  • Refactor code; move logic to controller class
  • Patch to migrate existing records
  • Test for Foreign currency Transaction
  • [ ] Refactor HR code as well

For Employee Advance and Gratuity, reference is maintained even after the advance has been allocated. So, HRMS will continue to use GL Entry for calculating advance_paid,

no-docs


This is an automatic backport of pull request #43709 done by Mergify.

(cherry picked from commit f176a82)
(cherry picked from commit 2b2360b)

# Conflicts:
#	erpnext/controllers/accounts_controller.py
(cherry picked from commit e2891a6)
(cherry picked from commit 8ab7194)
Copy link
Contributor Author

mergify bot commented Nov 1, 2024

Cherry-pick of 2b2360b has failed:

On branch mergify/bp/version-15-hotfix/pr-43709
Your branch is ahead of 'origin/version-15-hotfix' by 3 commits.
  (use "git push" to publish your local commits)

You are currently cherry-picking commit 2b2360bf7b.
  (fix conflicts and run "git cherry-pick --continue")
  (use "git cherry-pick --skip" to skip this patch)
  (use "git cherry-pick --abort" to cancel the cherry-pick operation)

Unmerged paths:
  (use "git add <file>..." to mark resolution)
	both modified:   erpnext/controllers/accounts_controller.py

no changes added to commit (use "git add" and/or "git commit -a")

To fix up this pull request, you can check it out locally. See documentation: https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/checking-out-pull-requests-locally

@ruthra-kumar ruthra-kumar merged commit ec46557 into version-15-hotfix Nov 4, 2024
11 checks passed
@ruthra-kumar ruthra-kumar deleted the mergify/bp/version-15-hotfix/pr-43709 branch November 4, 2024 05:23
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant