* fix: Allocated amount validation for other party types
* chore: Validation for return allocations
* chore: minor typo
---------
Co-authored-by: anandbaburajan <anandbaburajan@gmail.com>
This information is scraped from the in Colombia widely trusted site
dedicated to the plan unico de cuentas (PUC): puc.com.co
feat(accounts): add account_type overlay to colombian CoA
Add account_type overlay with a most significant number matching
strategy and a hand-crafted dictionary based on the erpnext
documentation and the corresponding account description from puc.com.co
Script used for scraping:
https://gist.github.com/blaggacao/d45a454d27556f41fef88833937088f1
* test: payment entry over allocation.
* fix: validate allocated_amount against latest outstanding amount.
* fix: payment entry get outstanding documents for advance payments
* fix: only fetch latest outstanding_amount.
* fix: throw if reference is allocated
* test: throw error if a reference has been partially allocated after inital creation.
* chore: test name
* fix: remove unused part of test
* chore: linter
* chore: more user friendly error messages
* fix: only validate outstanding amount if partly paid and don't filter by cost center
* chore: minor refactor for doc.cost_center
Co-authored-by: Deepesh Garg <deepeshgarg6@gmail.com>
---------
Co-authored-by: Anand Baburajan <anandbaburajan@gmail.com>
Co-authored-by: Deepesh Garg <deepeshgarg6@gmail.com>
I just applied semgrep autofix. Untested completed, review before merging.
```yaml
- id: frappe-set-value-semantics
patterns:
- pattern-either:
- pattern: frappe.db.set_value($DOCTYPE, None, $...AFTER)
- pattern: frappe.db.set_value($DOCTYPE, $DOCTYPE, $...AFTER)
fix: frappe.db.set_single_value($DOCTYPE, $...AFTER)
message: |
If $DOCTYPE is a single doctype then using `frappe.db.set_value` is discouraged for setting values in DB. Use db.set_single_value for single doctype instead.
languages: [python]
severity: ERROR
```
* fix: payment against credit note should be linked to parent invoice
* test: AR/AP report for payment against cr note scenario
* fix: cr_note shows up as outstanding invoice
Payment made against cr_note causes it be reported as outstanding invoice
Add Sales and Purchase Invoice Tests to check if GL entries and Outstanding Amount are generated correctly when advance entries are recorded as liability.
Few changes to return value of added column in Payment Entry References.
- Matching by Acc No/IBAN can easily happen with Bank Accounts. It's not a tedious query
- Historical lookups for Party Name/Desc match are very tricky. The user could have manually set a match and we would not know. Also this leaves the Bank Party Mapper only useful for Party Name/Desc lookups, which feels excessive.
- We want to reduce the number of places the same data is stored and reduce confusion
- The Party Name/Desc will optionally happen fuzzily, or not at all
- There will be no Mapper lookups
