* 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
The ultimate goal of this commit is to add an updated Portuguese Chart of Accounts (CoA), based on Portugal's SNC norm. Account numbers are included. "Account types" shall ideally be confirmed and improved by an accountant. Howbeit, the account types are mostly inspired on former OpenERP, now designated Odoo.
* fix: account group totals calculation to consider include_in_gross
(cherry picked from commit 8dcb9302b417618505ea24e5566c017eff451c1e)
* refactor: remove unused parameters
(cherry picked from commit 50822f207ec5272d4d71a2b6579693da2088105d)
* refactor: merge separate loops for calculating group / leaf node totals
rename function
remove return statement as the list is mutated
(cherry picked from commit 1a3b9c5bdfb9fac04a3a7d8724e6b3c3b593ec19)
* fix: add total col for gross and net profit
(cherry picked from commit cb9b4fbb91f4b73916416167932064ef5965eed1)
---------
Co-authored-by: Anoop Kurungadam <anoop@earthianslive.com>
- Fuzzy matching can be enabled optionally in the settings
- If a query gets multiple matches with the same score, do not set a party as it is an extremely close call
- misc: Add 'cancelled' status to Bank transaction
- Test for skipping matching with extremely close matches
Two purchase invoices for the same supplier, using different tax
withholding categories have this issue.
| Category | single | cumulative |
|----------+--------+------------|
| cat1 | 100 | 500 |
| cat2 | 1000 | 5000 |
1. PINV1 of net total: 105/- uses cat1. TDS is calculated as it
breached single threshold
2. PINV2 of net total: 200/- uses cat2. TDS incorrectly calculated as
PINV1 already has TDS calculated and 'consider_party_ledger_amount' is enabled.
difference_amount calculation is broken, as calculation gives NaN. Fix is make frm.doc.base_total_taxes_and_charges as flt(frm.doc.base_total_taxes_and_charges)
In multi-companies setting, on amount and rate field of Share Transfer
doctype are displaying wrong currency symbol, when create a
Share Transfer of others company that has different currency than
the main company. This due to the lack of `options` on those fields.
To fix this, add `options` to `amount` and `rate` fields.
- Remove newly added fields in Party doctypes to store bank details
- Use Bank Account's fields to match against account no/iban
- For employee, if Bank Account does not exist, find in Employee doctype against account no/iban
If Company master has no default cash or bank account set but Party has
default company bank account set. In this case, paid_amount and
conversion rate are not calculated correctly
* feat: auto reconcile in background
* chore: Option to enable auto reconciliation in settings
* refactor: validate if feature is enabled in settings
* refactor: check for running job while using reconciliation tool
* chore: using doc to get filter values
* chore: use frappe.db.get_value in validations
* chore: cleanup commented out code
* chore: replace get_list with get_all
* chore: use block scope variable
* chore: type information for functions
* refactor: flag to ignore job validation check
* refactor: update parent doc status if all reconciled
* chore: create test_records file
* test: create a bunch of vouchers for testing auto reconcile
* chore: renamed auto_reconcile to process_payment_reconciliation
* chore: another child doctype to hold payments
* chore: remove duplicate field
* chore: add fetched payments to log
* chore: Popup comment message update
* chore: replace get_all with get_value
* chore: replace label in settings page
* chore: remove unit test and records
* refactor: status in reconciliation log
* refactor: set status in log as well
* chore: fix field name
* chore: change triggered job name
* chore: use status field in list view of log
* chore: status while there are no allocations
* refactor: split trigger function into two
* chore: adding cancelled status
* refactor: function trigger queued docs
* chore: cron job scheduled
* chore: fixing accouts settings json file
* chore: typos and variable scope
* chore: use 'pluck' in db call
* chore: remove redundant whitelist decorator
* chore: use single DB call to fetch values
* chore: replace get_all with get_value
* refactor: use raw db calls to fetch reconciliation log records
Using get_doc on `Process Payment Reconciliation Log` is costly when
handling large volumes of invoices.
Use raw frappe.db.get_all to selectively pull status and reconciled count
* chore: update status on successful batch operation
* chore: make payment table readonly
* chore: ability to pause the background job
* chore: remove isolate_each_allocation
* chore: more description in progress bar
* refactor: partially working state
* refactor: update reconcile flag and setting hard limits for fetching
* chore: make allocation editable -- NEED TO REVERT
* chore: pause button
* refactor: skip setter function in Payment Entry for better performan
* refactor: split reconcile function and skip a setter function
1. Split reconcile function into 2
2. While reconciling against payment entry, skip a
set_missing_ref_details setter method
* chore: increase payment limit
* refactor: replace frappe.db.get_all with frappe.db.get_value
* chore: remove unwanted doctypes
* refactor: make allocation table readonly
* perf: update ref_details only for newly linked invoices
* chore: rename skip flag
* refactor(UI): receivable_payable field should auto populate
* refactor: no control statements in finally block
* chore: cleanup section and rename checkbox
* chore: update new fieldname in code
* chore: update error msg
* refactor: start and pause integrated into status
pause checkbox has been removed
* refactor: added cancelled status to the log doctype
1. Moved the status section to the bottom in parent doc
2. Using alerts to indicate Job trigger status
- A BT could have both account and iban, and a Supplier could have only IBAN set
- In this case, matching by either (only account) gives no match
- Match by Account OR IBAN, use `or_filters`
- If matched, set both account no. and IBAN in Bank Party Mapper
- Explain AutoMatchParty
- Add type hints to return values
- Use `set_value` to set values in BT after matching since its an after submit event
- On updating bank trans.n party after submit, the corresponding mapper doc will be updated too
- The mapper doc in turn will update all linked bank transactions that do not have this updated value
- Added Bank Party Mapper hidden link in Bank Transaction
- Rename field in BPM to `Party Name` as it does not hold description data
- If a BT matches with a BPM record, link that record in the BT
- Description is volatile and will keep changing
- It will lead to multiple Bank Party Mapper docs for the same party that will never be referenced again
- Parts of the descripton keep changing which is why it will never match a mapper record
- If matched by desc, dont create mapper record.
* fix: Multiple issues in purchase invoice submission
* fix: Base grand total calculation
* chore: Calculate base grand total separately only in multi currency docs
* fix: Add gl entry for round off
