* 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
- 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
