feat: e-waybill support for Subcontracting Inward #3822
Conversation
WalkthroughAdds Subcontracting Inward support by treating "Subcontracting Delivery" and "Return Raw Material to Customer" as valid Stock Entry purposes for e‑Waybill rules, adds an Changes
Sequence Diagram(s)sequenceDiagram
autonumber
actor User
participant Browser as Client (client scripts)
participant SE as Stock Entry (doc)
participant Server as App Server
participant Taxes as TaxesController
participant SCIO as Subcontracting Inward DB
User->>Browser: Create/Submit Stock Entry (Subcontracting Delivery / Return Raw Material)
Browser->>SE: Save/Submit
SE->>Server: validate(doc) / set_taxes_and_totals
Server->>Taxes: set_additional_taxable_value(doc)
alt Subcontracting Delivery
Taxes->>SCIO: Query consumed customer-provided items by scio_detail
SCIO-->>Taxes: rates & consumed_qty
Taxes->>Taxes: item.additional_taxable_value = sum(rate × consumed_qty)
else Return Raw Material to Customer
Taxes->>SCIO: Query required items by scio_detail
SCIO-->>Taxes: rate, qty, amount
Taxes->>Taxes: item.additional_taxable_value = (rate × qty) − amount
end
Taxes->>Taxes: update_item_taxable_value (add additional value with precision)
Server-->>SE: Validation completes (values updated)
SE-->>User: Save/Submit response
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes
Possibly related PRs
Suggested labels
Suggested reviewers
Poem
Pre-merge checks and finishing touches❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing touches
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (5)
india_compliance/gst_india/client_scripts/e_waybill_applicability.js (1)
241-255: Extending Stock Entry e-Waybill eligibility to new purposes is consistentIncluding
"Subcontracting Delivery"and"Return Raw Material to Customer"in both the applicability and API-enabled checks matches the backendis_e_waybill_applicablelogic and the new subcontracting flows.You do duplicate the same purpose array in
is_e_waybill_applicableandis_e_waybill_api_enabled; consider extracting a shared constant (or at least keeping them adjacent) to avoid drift if more purposes are added later.Also applies to: 324-335
india_compliance/gst_india/utils/taxes_controller.py (1)
150-158: Taxable value inclusion ofcustomer_provided_valueis correctUsing
taxable_value = amount + customer_provided_value(with item-level precision) matches the subcontracting inward requirement and stays backward‑compatible: on items withoutcustomer_provided_valuethis simply adds zero.If you expect
CustomTaxControllerto ever be reused on doctypes without ataxable_valuefield, adding a short guard or comment about that assumption would make the intent clearer.india_compliance/gst_india/client_scripts/stock_entry.js (1)
210-236: Bill To/Bill From mapping for new subcontracting purposes is sensibleFor
"Subcontracting Delivery"and"Return Raw Material to Customer", routing the party side tobill_to_address(with “Customer Address” label) and the company side tobill_from_addressmatches the described billing direction for inward subcontracting.You might also consider whether the
companyhandler (which currently only runs for"Send to Subcontractor") should auto-populatebill_from_addressfor these new purposes as well, to keep the UX consistent.india_compliance/gst_india/overrides/subcontracting_transaction.py (2)
184-193: Customer‑provided value computation matches the subcontracting requirementsThe
set_customer_provided_valuehook invalidateand its helpers implement the described behavior:
For
"Subcontracting Delivery", summingrate * consumed_qtyfromSubcontracting Inward Order Received Itemrows withis_customer_provided_item = 1byscio_item_detail, then mapping that toitem.customer_provided_value, correctly yields the total value of consumed customer‑provided materials per FG line.For
"Return Raw Material to Customer", setting
customer_provided_value = (SIO required_items.rate * qty) - amount
so thattaxable_value = amount + customer_provided_value = rate * qty
ensures the e‑Waybill taxable value reflects the SIO rate rather than stock valuation.A small robustness improvement would be to resolve the SIO name from either a document‑level field (if present) or from the first item that actually has
subcontracting_inward_order, instead of assumingdoc.items[0]always carries it; that would guard against edge cases where the first row is an unrelated item.Also applies to: 408-530
408-418: Ruff warnings about×characters in docstrings/commentsThe docstrings and comments here use the Unicode multiplication sign (
×), which Ruff flags as ambiguous (RUF002/RUF003). Replacing×with a plainx(e.g.,rate x qty) will quiet the linter without changing meaning.This is purely cosmetic but easy to address and keeps CI clean.
Also applies to: 437-447, 487-493, 523-526
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (7)
india_compliance/gst_india/client_scripts/e_waybill_actions.js(1 hunks)india_compliance/gst_india/client_scripts/e_waybill_applicability.js(2 hunks)india_compliance/gst_india/client_scripts/stock_entry.js(1 hunks)india_compliance/gst_india/constants/custom_fields.py(1 hunks)india_compliance/gst_india/overrides/subcontracting_transaction.py(4 hunks)india_compliance/gst_india/utils/taxes_controller.py(1 hunks)india_compliance/patches.txt(1 hunks)
🧰 Additional context used
🧠 Learnings (9)
📓 Common learnings
Learnt from: ljain112
Repo: resilient-tech/india-compliance PR: 3807
File: india_compliance/gst_india/overrides/transaction.py:142-157
Timestamp: 2025-11-21T08:53:26.329Z
Learning: In the india_compliance/gst_india/overrides/transaction.py file, the `_item_wise_tax_details` field used in `validate_item_wise_tax_detail()` is populated from ERPNext (not from within the India Compliance codebase) before validation runs, as part of cross-repository changes.
📚 Learning: 2025-07-30T10:15:18.756Z
Learnt from: vorasmit
Repo: resilient-tech/india-compliance PR: 3532
File: india_compliance/utils/change_log_utils.py:55-57
Timestamp: 2025-07-30T10:15:18.756Z
Learning: For e-Waybill update functions in india_compliance/gst_india/utils/e_waybill.py, HTML escaping in change log comments may not be required because the e-Waybill API data typically doesn't contain HTML tags and the risk of XSS through vehicle/transporter information fields is considered low by the project maintainers.
Applied to files:
india_compliance/gst_india/client_scripts/e_waybill_applicability.jsindia_compliance/gst_india/client_scripts/e_waybill_actions.js
📚 Learning: 2025-07-30T10:16:09.615Z
Learnt from: vorasmit
Repo: resilient-tech/india-compliance PR: 3532
File: india_compliance/gst_india/utils/e_waybill.py:484-490
Timestamp: 2025-07-30T10:16:09.615Z
Learning: In e-Waybill update functions (india_compliance/gst_india/utils/e_waybill.py), transporter IDs used in comments don't require HTML escaping because they come from the government e-Waybill API system which already validates and sanitizes data, rejecting HTML tags. The values are system-controlled rather than direct user input.
Applied to files:
india_compliance/gst_india/client_scripts/e_waybill_applicability.js
📚 Learning: 2025-07-22T11:45:43.432Z
Learnt from: karm1000
Repo: resilient-tech/india-compliance PR: 3532
File: india_compliance/gst_india/utils/e_waybill.py:327-336
Timestamp: 2025-07-22T11:45:43.432Z
Learning: In the e-waybill update functions (india_compliance/gst_india/utils/e_waybill.py), fields like place_of_change and state use hardcoded "-" values in old_values dictionaries because these values are not stored in the system, so there's no way to retrieve the actual previous values.
Applied to files:
india_compliance/gst_india/client_scripts/e_waybill_applicability.jsindia_compliance/gst_india/client_scripts/e_waybill_actions.jsindia_compliance/gst_india/constants/custom_fields.py
📚 Learning: 2025-11-21T08:53:26.329Z
Learnt from: ljain112
Repo: resilient-tech/india-compliance PR: 3807
File: india_compliance/gst_india/overrides/transaction.py:142-157
Timestamp: 2025-11-21T08:53:26.329Z
Learning: In the india_compliance/gst_india/overrides/transaction.py file, the `_item_wise_tax_details` field used in `validate_item_wise_tax_detail()` is populated from ERPNext (not from within the India Compliance codebase) before validation runs, as part of cross-repository changes.
Applied to files:
india_compliance/gst_india/client_scripts/e_waybill_applicability.jsindia_compliance/gst_india/client_scripts/stock_entry.jsindia_compliance/patches.txtindia_compliance/gst_india/client_scripts/e_waybill_actions.jsindia_compliance/gst_india/utils/taxes_controller.pyindia_compliance/gst_india/constants/custom_fields.pyindia_compliance/gst_india/overrides/subcontracting_transaction.py
📚 Learning: 2025-08-12T16:57:46.264Z
Learnt from: karm1000
Repo: resilient-tech/india-compliance PR: 3595
File: india_compliance/gst_india/overrides/delivery_note.py:30-38
Timestamp: 2025-08-12T16:57:46.264Z
Learning: In the delivery_note.py override, the onload function already checks if doc.get("ewaybill") exists before proceeding with e-waybill related operations.
Applied to files:
india_compliance/gst_india/client_scripts/e_waybill_applicability.js
📚 Learning: 2025-11-11T12:44:44.690Z
Learnt from: ljain112
Repo: resilient-tech/india-compliance PR: 3784
File: india_compliance/gst_india/client_scripts/company.js:25-28
Timestamp: 2025-11-11T12:44:44.690Z
Learning: In india_compliance, when using erpnext.company.set_custom_query(frm, [field_name, filters]) in Company doctype client scripts, the function automatically adds company and is_group filters. The filters object parameter should only contain additional filters beyond these defaults (e.g., root_type). For default_gst_expense_account, no root_type filter is needed, so an empty object {} is passed.
Applied to files:
india_compliance/gst_india/client_scripts/stock_entry.js
📚 Learning: 2025-05-29T15:22:04.761Z
Learnt from: vorasmit
Repo: resilient-tech/india-compliance PR: 3399
File: india_compliance/gst_india/utils/gstr_1/test_gstr_1_books_data.py:791-822
Timestamp: 2025-05-29T15:22:04.761Z
Learning: In the india_compliance test suite, the IntegrationTestCase framework automatically handles database rollbacks after test completion, which means functions that modify global state (like GST Settings and Item Tax Templates) in setUpClass won't persist beyond the test run and don't require manual cleanup.
Applied to files:
india_compliance/patches.txt
📚 Learning: 2025-06-25T08:19:02.607Z
Learnt from: karm1000
Repo: resilient-tech/india-compliance PR: 3354
File: india_compliance/gst_india/report/summary_of_itc_availed/summary_of_itc_availed.py:278-281
Timestamp: 2025-06-25T08:19:02.607Z
Learning: In the Summary of ITC Availed report (india_compliance/gst_india/report/summary_of_itc_availed/summary_of_itc_availed.py), the summary dictionaries created by get_initial_summary() are never empty - they always contain tax field keys (igst_amount, cgst_amount, sgst_amount, cess_amount) with 0 values, so checking for empty dictionaries is unnecessary.
Applied to files:
india_compliance/gst_india/utils/taxes_controller.py
🪛 Ruff (0.14.7)
india_compliance/gst_india/overrides/subcontracting_transaction.py
412-412: Docstring contains ambiguous × (MULTIPLICATION SIGN). Did you mean x (LATIN SMALL LETTER X)?
(RUF002)
416-416: Docstring contains ambiguous × (MULTIPLICATION SIGN). Did you mean x (LATIN SMALL LETTER X)?
(RUF002)
441-441: Docstring contains ambiguous × (MULTIPLICATION SIGN). Did you mean x (LATIN SMALL LETTER X)?
(RUF002)
490-490: Docstring contains ambiguous × (MULTIPLICATION SIGN). Did you mean x (LATIN SMALL LETTER X)?
(RUF002)
492-492: Docstring contains ambiguous × (MULTIPLICATION SIGN). Did you mean x (LATIN SMALL LETTER X)?
(RUF002)
523-523: Comment contains ambiguous × (MULTIPLICATION SIGN). Did you mean x (LATIN SMALL LETTER X)?
(RUF003)
525-525: Comment contains ambiguous × (MULTIPLICATION SIGN). Did you mean x (LATIN SMALL LETTER X)?
(RUF003)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (4)
- GitHub Check: Codacy Static Code Analysis
- GitHub Check: Python Unit Tests
- GitHub Check: Mergify Merge Protections
- GitHub Check: Summary
🔇 Additional comments (4)
india_compliance/patches.txt (1)
5-8: Patch marker bump to#67looks fineAligning the comment index with the new custom field additions is fine and has no runtime impact.
india_compliance/gst_india/client_scripts/e_waybill_actions.js (1)
541-555: Sub‑supply type mapping for new Stock Entry purposesUsing
supply_type = "Outward"withsub_supply_type = ["Others"]and descriptivesub_supply_descvalues ("Job Work Delivery","Return Raw Material") for the two new purposes is consistent with the existing pattern for special cases and integrates correctly with the generation dialog.Please just double‑check against the latest NIC e‑Waybill portal specifications that these flows are indeed expected to be reported under “Others” rather than specific job‑work enums, to avoid downstream rejection.
india_compliance/gst_india/constants/custom_fields.py (1)
750-776:customer_provided_valuefield definition lines up with its intended useDefining
customer_provided_valueas a read‑only, non‑copied, non‑printed currency field right aftertaxable_valueis appropriate for storing customer‑provided material value solely for GST/e‑Waybill computations.This matches the server logic in the subcontracting override and the taxable value calculation in
CustomTaxController.india_compliance/gst_india/overrides/subcontracting_transaction.py (1)
41-46: Purpose constant and e-Waybill applicability extension are coherentDefining
SUBCONTRACTING_INWARD_PURPOSESand using the same purpose names in bothset_customer_provided_valueandis_e_waybill_applicablekeeps the logic consistent across tax computation and eligibility checks.The updated Stock Entry purpose list (
"Subcontracting Delivery","Return Raw Material to Customer") is aligned with the client‑side applicability rules and should ensure these inward subcontracting flows are treated as e‑Waybill‑capable wherever GST Settings permit it.Also applies to: 639-661
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (2)
india_compliance/gst_india/overrides/subcontracting_transaction.py (2)
43-46: Avoid duplicating purpose literals; reuseSUBCONTRACTING_INWARD_PURPOSESinis_e_waybill_applicable.You’re hard‑coding
"Subcontracting Delivery"and"Return Raw Material to Customer"both inSUBCONTRACTING_INWARD_PURPOSESand inis_e_waybill_applicable. To prevent future drift if these labels change, consider driving the applicability check from the same tuple:-SUBCONTRACTING_INWARD_PURPOSES = ( - "Subcontracting Delivery", - "Return Raw Material to Customer", -) +SUBCONTRACTING_INWARD_PURPOSES = ( + "Subcontracting Delivery", + "Return Raw Material to Customer", +) ... - if doc.purpose not in [ - "Material Transfer", - "Material Issue", - "Send to Subcontractor", - "Subcontracting Delivery", - "Return Raw Material to Customer", - ]: + if doc.purpose not in ( + "Material Transfer", + "Material Issue", + "Send to Subcontractor", + ) + SUBCONTRACTING_INWARD_PURPOSES: return FalseAlso applies to: 620-626
410-418: Ruff RUF002: replace×in docstrings with ASCII*orx.Ruff is flagging the multiplication sign
×in these docstrings as ambiguous. To keep lint noise down and improve readability in plain terminals, consider switching to*or plainx:- - customer_provided_value = SUM(received_items.rate × consumed_qty) + - customer_provided_value = SUM(received_items.rate * consumed_qty) @@ - - customer_provided_value = (SIO required_items.rate × qty) - item.amount + - customer_provided_value = (SIO required_items.rate * qty) - item.amount @@ - Customer_provided_value = SUM(received_items.rate * received_items.consumed_qty) + Customer_provided_value = SUM(received_items.rate * received_items.consumed_qty) @@ - customer_provided_value = (SIO rate × qty) - amount + customer_provided_value = (SIO rate * qty) - amountAlso applies to: 439-439, 473-473
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
india_compliance/gst_india/overrides/subcontracting_transaction.py(4 hunks)
🧰 Additional context used
🧠 Learnings (2)
📓 Common learnings
Learnt from: ljain112
Repo: resilient-tech/india-compliance PR: 3807
File: india_compliance/gst_india/overrides/transaction.py:142-157
Timestamp: 2025-11-21T08:53:26.329Z
Learning: In the india_compliance/gst_india/overrides/transaction.py file, the `_item_wise_tax_details` field used in `validate_item_wise_tax_detail()` is populated from ERPNext (not from within the India Compliance codebase) before validation runs, as part of cross-repository changes.
Learnt from: vorasmit
Repo: resilient-tech/india-compliance PR: 3532
File: india_compliance/gst_india/utils/e_waybill.py:484-490
Timestamp: 2025-07-30T10:16:09.615Z
Learning: In e-Waybill update functions (india_compliance/gst_india/utils/e_waybill.py), transporter IDs used in comments don't require HTML escaping because they come from the government e-Waybill API system which already validates and sanitizes data, rejecting HTML tags. The values are system-controlled rather than direct user input.
Learnt from: karm1000
Repo: resilient-tech/india-compliance PR: 3532
File: india_compliance/gst_india/utils/e_waybill.py:327-336
Timestamp: 2025-07-22T11:45:43.432Z
Learning: In the e-waybill update functions (india_compliance/gst_india/utils/e_waybill.py), fields like place_of_change and state use hardcoded "-" values in old_values dictionaries because these values are not stored in the system, so there's no way to retrieve the actual previous values.
📚 Learning: 2025-11-21T08:53:26.329Z
Learnt from: ljain112
Repo: resilient-tech/india-compliance PR: 3807
File: india_compliance/gst_india/overrides/transaction.py:142-157
Timestamp: 2025-11-21T08:53:26.329Z
Learning: In the india_compliance/gst_india/overrides/transaction.py file, the `_item_wise_tax_details` field used in `validate_item_wise_tax_detail()` is populated from ERPNext (not from within the India Compliance codebase) before validation runs, as part of cross-repository changes.
Applied to files:
india_compliance/gst_india/overrides/subcontracting_transaction.py
🪛 Ruff (0.14.7)
india_compliance/gst_india/overrides/subcontracting_transaction.py
412-412: Docstring contains ambiguous × (MULTIPLICATION SIGN). Did you mean x (LATIN SMALL LETTER X)?
(RUF002)
416-416: Docstring contains ambiguous × (MULTIPLICATION SIGN). Did you mean x (LATIN SMALL LETTER X)?
(RUF002)
473-473: Docstring contains ambiguous × (MULTIPLICATION SIGN). Did you mean x (LATIN SMALL LETTER X)?
(RUF002)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (4)
- GitHub Check: Codacy Static Code Analysis
- GitHub Check: Python Unit Tests
- GitHub Check: Mergify Merge Protections
- GitHub Check: Summary
🔇 Additional comments (2)
india_compliance/gst_india/overrides/subcontracting_transaction.py (2)
185-186: Placement ofset_customer_provided_valueinvalidatelooks correct.Calling
set_customer_provided_value(doc)at the top ofvalidateensures item‑levelcustomer_provided_valueis populated beforeCustomTaxController(...).set_taxes_and_totals()recomputes taxable values and totals, while the helper itself is safely no‑op for non‑Stock Entry doctypes.
408-498: Edge-case handling in_set_return_raw_material_customer_valuewarrants defensive improvements.The formulas correctly implement the intended calculations:
- Subcontracting Delivery: sums
rate × consumed_qtyfor customer-provided items, keyed byscio_item_detail- Return Raw Material: calculates
(SIO rate × qty) - amountto derive customer-provided valueOne edge case deserves attention: if an item references a
scio_detailthat doesn't exist inrequired_items,required_items.get(item.scio_detail, 0)returns 0, resulting incustomer_provided_value = -item.amount—an incorrect negative value.Make the function more robust by explicitly skipping rows where the SIO reference is missing:
for item in doc.items: - if item.get("scio_detail"): - sio_value = required_items.get(item.scio_detail, 0) * flt(item.qty) - item.customer_provided_value = sio_value - flt(item.amount) + if not item.get("scio_detail"): + continue + + if item.scio_detail not in required_items: + continue + + sio_value = required_items[item.scio_detail] * flt(item.qty) + item.customer_provided_value = sio_value - flt(item.amount)Additionally, deduplicate
scio_detailsto avoid redundant IN-filter values when multiple items reference the same SIO row.
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (1)
india_compliance/gst_india/client_scripts/stock_entry.js (1)
210-222: Consider exposing helpers onindia_compliancenamespace for cross-module access.The helper functions are correctly implemented and properly distinguish between outbound subcontracting ("Send to Subcontractor") and inward subcontracting ("Subcontracting Delivery", "Return Raw Material to Customer") flows. However, if other client scripts (e.g.,
e_waybill_actions.js,e_waybill_applicability.js) need to check for subcontracting entry types, these helpers should be exposed on theindia_compliancenamespace.If cross-module access is needed, apply this diff:
function is_subcontracting_entry(frm) { return [ "Send to Subcontractor", "Subcontracting Delivery", "Return Raw Material to Customer", ].includes(frm.doc.purpose); } function is_subcontracting_inward_entry(frm) { return ["Subcontracting Delivery", "Return Raw Material to Customer"].includes( frm.doc.purpose ); } + +// Expose helpers for use in other modules +Object.assign(india_compliance, { + is_subcontracting_entry, + is_subcontracting_inward_entry +});
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (5)
india_compliance/gst_india/client_scripts/e_waybill_applicability.js(3 hunks)india_compliance/gst_india/client_scripts/stock_entry.js(3 hunks)india_compliance/gst_india/overrides/subcontracting_transaction.py(4 hunks)india_compliance/gst_india/utils/taxes_controller.py(1 hunks)india_compliance/public/js/utils.js(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (2)
- india_compliance/gst_india/client_scripts/e_waybill_applicability.js
- india_compliance/gst_india/overrides/subcontracting_transaction.py
🧰 Additional context used
🧠 Learnings (7)
📓 Common learnings
Learnt from: ljain112
Repo: resilient-tech/india-compliance PR: 3807
File: india_compliance/gst_india/overrides/transaction.py:142-157
Timestamp: 2025-11-21T08:53:26.329Z
Learning: In the india_compliance/gst_india/overrides/transaction.py file, the `_item_wise_tax_details` field used in `validate_item_wise_tax_detail()` is populated from ERPNext (not from within the India Compliance codebase) before validation runs, as part of cross-repository changes.
Learnt from: vorasmit
Repo: resilient-tech/india-compliance PR: 3532
File: india_compliance/gst_india/utils/e_waybill.py:484-490
Timestamp: 2025-07-30T10:16:09.615Z
Learning: In e-Waybill update functions (india_compliance/gst_india/utils/e_waybill.py), transporter IDs used in comments don't require HTML escaping because they come from the government e-Waybill API system which already validates and sanitizes data, rejecting HTML tags. The values are system-controlled rather than direct user input.
Learnt from: karm1000
Repo: resilient-tech/india-compliance PR: 3532
File: india_compliance/gst_india/utils/e_waybill.py:327-336
Timestamp: 2025-07-22T11:45:43.432Z
Learning: In the e-waybill update functions (india_compliance/gst_india/utils/e_waybill.py), fields like place_of_change and state use hardcoded "-" values in old_values dictionaries because these values are not stored in the system, so there's no way to retrieve the actual previous values.
📚 Learning: 2025-11-21T08:53:26.329Z
Learnt from: ljain112
Repo: resilient-tech/india-compliance PR: 3807
File: india_compliance/gst_india/overrides/transaction.py:142-157
Timestamp: 2025-11-21T08:53:26.329Z
Learning: In the india_compliance/gst_india/overrides/transaction.py file, the `_item_wise_tax_details` field used in `validate_item_wise_tax_detail()` is populated from ERPNext (not from within the India Compliance codebase) before validation runs, as part of cross-repository changes.
Applied to files:
india_compliance/gst_india/utils/taxes_controller.pyindia_compliance/public/js/utils.jsindia_compliance/gst_india/client_scripts/stock_entry.js
📚 Learning: 2025-06-25T08:19:02.607Z
Learnt from: karm1000
Repo: resilient-tech/india-compliance PR: 3354
File: india_compliance/gst_india/report/summary_of_itc_availed/summary_of_itc_availed.py:278-281
Timestamp: 2025-06-25T08:19:02.607Z
Learning: In the Summary of ITC Availed report (india_compliance/gst_india/report/summary_of_itc_availed/summary_of_itc_availed.py), the summary dictionaries created by get_initial_summary() are never empty - they always contain tax field keys (igst_amount, cgst_amount, sgst_amount, cess_amount) with 0 values, so checking for empty dictionaries is unnecessary.
Applied to files:
india_compliance/gst_india/utils/taxes_controller.py
📚 Learning: 2025-07-30T10:15:18.756Z
Learnt from: vorasmit
Repo: resilient-tech/india-compliance PR: 3532
File: india_compliance/utils/change_log_utils.py:55-57
Timestamp: 2025-07-30T10:15:18.756Z
Learning: For e-Waybill update functions in india_compliance/gst_india/utils/e_waybill.py, HTML escaping in change log comments may not be required because the e-Waybill API data typically doesn't contain HTML tags and the risk of XSS through vehicle/transporter information fields is considered low by the project maintainers.
Applied to files:
india_compliance/public/js/utils.js
📚 Learning: 2025-07-30T10:16:09.615Z
Learnt from: vorasmit
Repo: resilient-tech/india-compliance PR: 3532
File: india_compliance/gst_india/utils/e_waybill.py:484-490
Timestamp: 2025-07-30T10:16:09.615Z
Learning: In e-Waybill update functions (india_compliance/gst_india/utils/e_waybill.py), transporter IDs used in comments don't require HTML escaping because they come from the government e-Waybill API system which already validates and sanitizes data, rejecting HTML tags. The values are system-controlled rather than direct user input.
Applied to files:
india_compliance/public/js/utils.js
📚 Learning: 2025-11-11T12:44:44.690Z
Learnt from: ljain112
Repo: resilient-tech/india-compliance PR: 3784
File: india_compliance/gst_india/client_scripts/company.js:25-28
Timestamp: 2025-11-11T12:44:44.690Z
Learning: In india_compliance, when using erpnext.company.set_custom_query(frm, [field_name, filters]) in Company doctype client scripts, the function automatically adds company and is_group filters. The filters object parameter should only contain additional filters beyond these defaults (e.g., root_type). For default_gst_expense_account, no root_type filter is needed, so an empty object {} is passed.
Applied to files:
india_compliance/gst_india/client_scripts/stock_entry.js
📚 Learning: 2025-09-29T05:06:10.320Z
Learnt from: ljain112
Repo: resilient-tech/india-compliance PR: 3693
File: india_compliance/gst_india/doctype/gst_invoice_management_system/gst_invoice_management_system.js:32-33
Timestamp: 2025-09-29T05:06:10.320Z
Learning: GST-related tool doctypes (like GST Invoice Management System, Purchase Reconciliation Tool, GSTR-1) use unconditional assignment of session default company in their setup() method: `frm.doc.company = frappe.defaults.get_user_default("Company");`. This is appropriate for these utility tools as they are meant to always start with the user's default company on each load, unlike regular documents that preserve saved company values.
Applied to files:
india_compliance/gst_india/client_scripts/stock_entry.js
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (4)
- GitHub Check: Codacy Static Code Analysis
- GitHub Check: Python Unit Tests
- GitHub Check: Mergify Merge Protections
- GitHub Check: Summary
🔇 Additional comments (3)
india_compliance/public/js/utils.js (1)
550-556: LGTM!The addition of "Subcontracting Delivery" and "Return Raw Material to Customer" to the e-waybill applicability whitelist correctly enables e-waybill support for the new Subcontracting Inward purposes.
india_compliance/gst_india/client_scripts/stock_entry.js (1)
236-246: LGTM!The new branch correctly handles the inward subcontracting flow where the company bills to the customer. The field mappings appropriately swap
bill_to_addressandbill_from_addresscompared to the default outbound flow, and the labels clearly indicate the direction of billing.india_compliance/gst_india/utils/taxes_controller.py (1)
152-157: Verify thatcustomer_provided_valueis properly populated before this calculation.The logic correctly adds
customer_provided_valueto the taxable value with appropriate precision handling usingflt()with item precision. The defensive use ofitem.get("customer_provided_value", 0)handles missing values safely. Confirm that this field is set during Stock Entry validation (likely insubcontracting_transaction.pyor ERPNext doctype configuration) beforeupdate_item_taxable_valueis called.
ljain112
force-pushed
the
feat-ewaybill-inward
branch
from
b65e751 to
555f9c3
Compare
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## develop #3822 +/- ##
===========================================
- Coverage 69.53% 69.41% -0.12%
===========================================
Files 182 182
Lines 17972 18020 +48
===========================================
+ Hits 12496 12509 +13
- Misses 5476 5511 +35
🚀 New features to boost your workflow:
|
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (1)
india_compliance/gst_india/constants/custom_fields.py (1)
763-775:additional_taxable_valuefield definition is consistent; consider narrowing visibilityThe
additional_taxable_valueCurrency field mirrorstaxable_valuein options and flags and is correctly positioned after it, which fits the subcontracting inward use‑case.Optionally, to avoid noise on unrelated Stock Entries, you could add a
depends_onexpression so this field is only shown for subcontracting inward purposes (e.g.,"Subcontracting Delivery"/"Return Raw Material to Customer").
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (4)
india_compliance/gst_india/client_scripts/stock_entry.js(4 hunks)india_compliance/gst_india/constants/custom_fields.py(1 hunks)india_compliance/gst_india/overrides/subcontracting_transaction.py(2 hunks)india_compliance/gst_india/utils/taxes_controller.py(3 hunks)
🧰 Additional context used
🧠 Learnings (9)
📓 Common learnings
Learnt from: ljain112
Repo: resilient-tech/india-compliance PR: 3807
File: india_compliance/gst_india/overrides/transaction.py:142-157
Timestamp: 2025-11-21T08:53:26.329Z
Learning: In the india_compliance/gst_india/overrides/transaction.py file, the `_item_wise_tax_details` field used in `validate_item_wise_tax_detail()` is populated from ERPNext (not from within the India Compliance codebase) before validation runs, as part of cross-repository changes.
Learnt from: vorasmit
Repo: resilient-tech/india-compliance PR: 3532
File: india_compliance/gst_india/utils/e_waybill.py:484-490
Timestamp: 2025-07-30T10:16:09.615Z
Learning: In e-Waybill update functions (india_compliance/gst_india/utils/e_waybill.py), transporter IDs used in comments don't require HTML escaping because they come from the government e-Waybill API system which already validates and sanitizes data, rejecting HTML tags. The values are system-controlled rather than direct user input.
📚 Learning: 2025-11-21T08:53:26.329Z
Learnt from: ljain112
Repo: resilient-tech/india-compliance PR: 3807
File: india_compliance/gst_india/overrides/transaction.py:142-157
Timestamp: 2025-11-21T08:53:26.329Z
Learning: In the india_compliance/gst_india/overrides/transaction.py file, the `_item_wise_tax_details` field used in `validate_item_wise_tax_detail()` is populated from ERPNext (not from within the India Compliance codebase) before validation runs, as part of cross-repository changes.
Applied to files:
india_compliance/gst_india/constants/custom_fields.pyindia_compliance/gst_india/utils/taxes_controller.pyindia_compliance/gst_india/client_scripts/stock_entry.jsindia_compliance/gst_india/overrides/subcontracting_transaction.py
📚 Learning: 2025-06-25T08:19:02.607Z
Learnt from: karm1000
Repo: resilient-tech/india-compliance PR: 3354
File: india_compliance/gst_india/report/summary_of_itc_availed/summary_of_itc_availed.py:278-281
Timestamp: 2025-06-25T08:19:02.607Z
Learning: In the Summary of ITC Availed report (india_compliance/gst_india/report/summary_of_itc_availed/summary_of_itc_availed.py), the summary dictionaries created by get_initial_summary() are never empty - they always contain tax field keys (igst_amount, cgst_amount, sgst_amount, cess_amount) with 0 values, so checking for empty dictionaries is unnecessary.
Applied to files:
india_compliance/gst_india/utils/taxes_controller.py
📚 Learning: 2025-07-30T10:15:18.756Z
Learnt from: vorasmit
Repo: resilient-tech/india-compliance PR: 3532
File: india_compliance/utils/change_log_utils.py:55-57
Timestamp: 2025-07-30T10:15:18.756Z
Learning: For e-Waybill update functions in india_compliance/gst_india/utils/e_waybill.py, HTML escaping in change log comments may not be required because the e-Waybill API data typically doesn't contain HTML tags and the risk of XSS through vehicle/transporter information fields is considered low by the project maintainers.
Applied to files:
india_compliance/gst_india/client_scripts/stock_entry.jsindia_compliance/gst_india/overrides/subcontracting_transaction.py
📚 Learning: 2025-07-22T11:45:43.432Z
Learnt from: karm1000
Repo: resilient-tech/india-compliance PR: 3532
File: india_compliance/gst_india/utils/e_waybill.py:327-336
Timestamp: 2025-07-22T11:45:43.432Z
Learning: In the e-waybill update functions (india_compliance/gst_india/utils/e_waybill.py), fields like place_of_change and state use hardcoded "-" values in old_values dictionaries because these values are not stored in the system, so there's no way to retrieve the actual previous values.
Applied to files:
india_compliance/gst_india/client_scripts/stock_entry.jsindia_compliance/gst_india/overrides/subcontracting_transaction.py
📚 Learning: 2025-09-29T05:06:10.320Z
Learnt from: ljain112
Repo: resilient-tech/india-compliance PR: 3693
File: india_compliance/gst_india/doctype/gst_invoice_management_system/gst_invoice_management_system.js:32-33
Timestamp: 2025-09-29T05:06:10.320Z
Learning: GST-related tool doctypes (like GST Invoice Management System, Purchase Reconciliation Tool, GSTR-1) use unconditional assignment of session default company in their setup() method: `frm.doc.company = frappe.defaults.get_user_default("Company");`. This is appropriate for these utility tools as they are meant to always start with the user's default company on each load, unlike regular documents that preserve saved company values.
Applied to files:
india_compliance/gst_india/client_scripts/stock_entry.js
📚 Learning: 2025-06-19T08:21:29.308Z
Learnt from: vorasmit
Repo: resilient-tech/india-compliance PR: 3451
File: india_compliance/gst_india/doctype/gstr_1_beta/gstr_1_export.py:287-288
Timestamp: 2025-06-19T08:21:29.308Z
Learning: In GSTR-1 export code (india_compliance/gst_india/doctype/gstr_1_beta/gstr_1_export.py), date fields like invoice date (DOC_DATE) and shipping bill date (SHIPPING_BILL_DATE) are mandatory by GST regulations and must exist, so transform functions using strftime() don't need None checks.
Applied to files:
india_compliance/gst_india/overrides/subcontracting_transaction.py
📚 Learning: 2025-10-01T10:54:11.096Z
Learnt from: karm1000
Repo: resilient-tech/india-compliance PR: 3709
File: india_compliance/gst_india/utils/exporter.py:174-174
Timestamp: 2025-10-01T10:54:11.096Z
Learning: In india_compliance/gst_india/doctype/gstr_1/gstr_1_export.py, FIELD_TRANSFORMATIONS dictionary contains lambdas that are only called internally by DataProcessor.apply_transformations() with a single argument. These are separate from header transforms used with ExcelExporter.insert_data() which accept two arguments (value, row).
Applied to files:
india_compliance/gst_india/overrides/subcontracting_transaction.py
📚 Learning: 2025-07-30T10:16:09.615Z
Learnt from: vorasmit
Repo: resilient-tech/india-compliance PR: 3532
File: india_compliance/gst_india/utils/e_waybill.py:484-490
Timestamp: 2025-07-30T10:16:09.615Z
Learning: In e-Waybill update functions (india_compliance/gst_india/utils/e_waybill.py), transporter IDs used in comments don't require HTML escaping because they come from the government e-Waybill API system which already validates and sanitizes data, rejecting HTML tags. The values are system-controlled rather than direct user input.
Applied to files:
india_compliance/gst_india/overrides/subcontracting_transaction.py
🧬 Code graph analysis (1)
india_compliance/gst_india/client_scripts/stock_entry.js (1)
india_compliance/gst_india/client_scripts/e_waybill_actions.js (1)
frm(985-985)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (4)
- GitHub Check: Codacy Static Code Analysis
- GitHub Check: Python Unit Tests
- GitHub Check: Mergify Merge Protections
- GitHub Check: Summary
🔇 Additional comments (3)
india_compliance/gst_india/overrides/subcontracting_transaction.py (1)
523-529: New Stock Entry purposes correctly included for e‑Waybill applicabilityAllowing
"Subcontracting Delivery"and"Return Raw Material to Customer"in the Stock Entry purpose whitelist aligns with the subcontracting inward requirements and keeps the existing guardrails (GST Settings + doctype) intact. Please just confirm these strings exactly match the ERPNext v16 purpose values to avoid silent non‑applicability.india_compliance/gst_india/utils/taxes_controller.py (1)
113-170: Taxable value flow correctly extended to includeadditional_taxable_valueCalling
set_additional_taxable_value()beforeupdate_item_taxable_value()ensuresitem.taxable_valueisamount + additional_taxable_valuefor Stock Entries, while remaining a no‑op for other doctypes. This integrates cleanly with existingcalculate_total_taxable_value()and downstream tax computations.india_compliance/gst_india/client_scripts/stock_entry.js (1)
75-85: Inward/outward subcontracting address handling looks consistent with new purposes
- The new alert message (“Party Address is required to create e‑Waybill”) is clearer and purpose‑agnostic.
company(frm)usingis_subcontracting_entry(frm)correctly extends default company‑address population to"Subcontracting Delivery"and"Return Raw Material to Customer"alongside"Send to Subcontractor".is_subcontracting_entry/is_subcontracting_inward_entryhelpers centralize purpose checks and are used consistently.- The new
get_field_and_labelbranch for inward subcontracting correctly flips the semantics so that:
party_field=bill_to_addresswith “(same as Customer Address)” label,company_field=bill_from_address,
matching the “company bills to the customer” requirement.Overall this wiring should make the e‑Waybill address UI align with both outward and inward subcontracting flows.
Also applies to: 114-131, 210-222, 227-246
There was a problem hiding this comment.
Actionable comments posted: 2
♻️ Duplicate comments (1)
india_compliance/gst_india/utils/taxes_controller.py (1)
355-365: Past review concern addressed—LGTM.The guard
if not scio_rate: continueprevents the problematic scenario where a missing SCIO record would result in negativeadditional_taxable_value. Items without valid SCIO linkage now retain their initialized value of 0.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
india_compliance/gst_india/utils/taxes_controller.py(4 hunks)
🧰 Additional context used
🧠 Learnings (4)
📓 Common learnings
Learnt from: ljain112
Repo: resilient-tech/india-compliance PR: 3807
File: india_compliance/gst_india/overrides/transaction.py:142-157
Timestamp: 2025-11-21T08:53:26.329Z
Learning: In the india_compliance/gst_india/overrides/transaction.py file, the `_item_wise_tax_details` field used in `validate_item_wise_tax_detail()` is populated from ERPNext (not from within the India Compliance codebase) before validation runs, as part of cross-repository changes.
Learnt from: vorasmit
Repo: resilient-tech/india-compliance PR: 3532
File: india_compliance/gst_india/utils/e_waybill.py:484-490
Timestamp: 2025-07-30T10:16:09.615Z
Learning: In e-Waybill update functions (india_compliance/gst_india/utils/e_waybill.py), transporter IDs used in comments don't require HTML escaping because they come from the government e-Waybill API system which already validates and sanitizes data, rejecting HTML tags. The values are system-controlled rather than direct user input.
📚 Learning: 2025-11-21T08:53:26.329Z
Learnt from: ljain112
Repo: resilient-tech/india-compliance PR: 3807
File: india_compliance/gst_india/overrides/transaction.py:142-157
Timestamp: 2025-11-21T08:53:26.329Z
Learning: In the india_compliance/gst_india/overrides/transaction.py file, the `_item_wise_tax_details` field used in `validate_item_wise_tax_detail()` is populated from ERPNext (not from within the India Compliance codebase) before validation runs, as part of cross-repository changes.
Applied to files:
india_compliance/gst_india/utils/taxes_controller.py
📚 Learning: 2025-06-25T08:19:02.607Z
Learnt from: karm1000
Repo: resilient-tech/india-compliance PR: 3354
File: india_compliance/gst_india/report/summary_of_itc_availed/summary_of_itc_availed.py:278-281
Timestamp: 2025-06-25T08:19:02.607Z
Learning: In the Summary of ITC Availed report (india_compliance/gst_india/report/summary_of_itc_availed/summary_of_itc_availed.py), the summary dictionaries created by get_initial_summary() are never empty - they always contain tax field keys (igst_amount, cgst_amount, sgst_amount, cess_amount) with 0 values, so checking for empty dictionaries is unnecessary.
Applied to files:
india_compliance/gst_india/utils/taxes_controller.py
📚 Learning: 2025-08-20T12:52:11.346Z
Learnt from: vorasmit
Repo: resilient-tech/india-compliance PR: 3620
File: india_compliance/gst_india/api_classes/nic/e_invoice.py:167-175
Timestamp: 2025-08-20T12:52:11.346Z
Learning: In the GST India API classes (india_compliance/gst_india/api_classes/base.py), all JSON responses are automatically converted to frappe._dict objects using `response.json(object_hook=frappe._dict)` at line 151. This means that any dictionary objects in API responses already support attribute access and don't need manual wrapping in frappe._dict.
Applied to files:
india_compliance/gst_india/utils/taxes_controller.py
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (4)
- GitHub Check: Codacy Static Code Analysis
- GitHub Check: Python Unit Tests
- GitHub Check: Mergify Merge Protections
- GitHub Check: Summary
🔇 Additional comments (6)
india_compliance/gst_india/utils/taxes_controller.py (6)
2-2: LGTM!Standard library import, appropriate for the per-key cost accumulation pattern used in
_set_subcontracting_delivery_additional_value.
114-119: LGTM!Correct sequencing—
set_additional_taxable_value()is invoked beforeupdate_item_taxable_value(), ensuring the additional value is populated before it's consumed in the taxable value calculation.
152-159: LGTM!The taxable value computation correctly incorporates the additional value with a safe default, and applies appropriate precision for the target field.
161-171: LGTM!Clean implementation with proper doctype guard, explicit initialization, and clear dispatch to purpose-specific handlers.
291-317: LGTM!Well-structured implementation: graceful handling of empty data, safe numeric operations with
flt(), and efficient cost aggregation usingdefaultdict.
339-348: LGTM!Query correctly filters by
name(sincescio_detailin return scenarios references the received item directly), and thefrappe._dictwrapper efficiently converts the result to a lookup dictionary.
There was a problem hiding this comment.
Actionable comments posted: 0
♻️ Duplicate comments (1)
india_compliance/gst_india/utils/taxes_controller.py (1)
342-377: Useis Nonefor scio_rate check to avoid treating 0 as “missing”In
_set_return_raw_material_additional_value, this block:scio_rate = received_items.get(scio_detail) if not scio_rate: continueskips lines where the SCIO Received Item’s rate is
0, not just when the rate is absent. That’s slightly different from the earlier suggested fix (which usedif rate is None) and changes semantics for legitimate 0‑rate cases: taxable_value will remainitem.amountinstead of being driven to0via(0 * qty) - amount.To keep the “skip only when there is no SCIO record” behaviour while still guarding against missing links, consider tightening the check:
- scio_rate = received_items.get(scio_detail) - if not scio_rate: - continue + scio_rate = received_items.get(scio_detail) + if scio_rate is None: + # Leave additional_taxable_value at 0 if SCIO link is missing + continueThis matches the intent of the previous review while still preventing under‑valuation when the SCIO link is missing.
🧹 Nitpick comments (1)
india_compliance/public/js/taxes_controller.js (1)
135-141: Additional taxable value handling for Stock Entry is consistent with server‑side logicThe client now mirrors the server: for Stock Entry rows, taxable_value is base (qty × rate / transfer_qty × basic_rate) plus additional_taxable_value, using the same precision key. This looks correct and keeps other doctypes untouched.
As a tiny clean‑up, you could avoid recomputing precision twice:
- const calculateAmount = (qty, rate, precisionType) => { - let amount = flt(flt(qty) * flt(rate), precision(precisionType, row)); - - if (this.frm.doc.doctype === "Stock Entry") { - amount += flt(row.additional_taxable_value, precision(precisionType, row)); - } - return amount; - }; + const calculateAmount = (qty, rate, precisionType) => { + const prec = precision(precisionType, row); + let amount = flt(flt(qty) * flt(rate), prec); + + if (this.frm.doc.doctype === "Stock Entry") { + amount += flt(row.additional_taxable_value, prec); + } + return amount; + };
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
india_compliance/gst_india/utils/taxes_controller.py(4 hunks)india_compliance/public/js/taxes_controller.js(1 hunks)
🧰 Additional context used
🧠 Learnings (4)
📓 Common learnings
Learnt from: ljain112
Repo: resilient-tech/india-compliance PR: 3807
File: india_compliance/gst_india/overrides/transaction.py:142-157
Timestamp: 2025-11-21T08:53:26.329Z
Learning: In the india_compliance/gst_india/overrides/transaction.py file, the `_item_wise_tax_details` field used in `validate_item_wise_tax_detail()` is populated from ERPNext (not from within the India Compliance codebase) before validation runs, as part of cross-repository changes.
📚 Learning: 2025-11-21T08:53:26.329Z
Learnt from: ljain112
Repo: resilient-tech/india-compliance PR: 3807
File: india_compliance/gst_india/overrides/transaction.py:142-157
Timestamp: 2025-11-21T08:53:26.329Z
Learning: In the india_compliance/gst_india/overrides/transaction.py file, the `_item_wise_tax_details` field used in `validate_item_wise_tax_detail()` is populated from ERPNext (not from within the India Compliance codebase) before validation runs, as part of cross-repository changes.
Applied to files:
india_compliance/public/js/taxes_controller.jsindia_compliance/gst_india/utils/taxes_controller.py
📚 Learning: 2025-06-25T08:19:02.607Z
Learnt from: karm1000
Repo: resilient-tech/india-compliance PR: 3354
File: india_compliance/gst_india/report/summary_of_itc_availed/summary_of_itc_availed.py:278-281
Timestamp: 2025-06-25T08:19:02.607Z
Learning: In the Summary of ITC Availed report (india_compliance/gst_india/report/summary_of_itc_availed/summary_of_itc_availed.py), the summary dictionaries created by get_initial_summary() are never empty - they always contain tax field keys (igst_amount, cgst_amount, sgst_amount, cess_amount) with 0 values, so checking for empty dictionaries is unnecessary.
Applied to files:
india_compliance/gst_india/utils/taxes_controller.py
📚 Learning: 2025-08-20T12:52:11.346Z
Learnt from: vorasmit
Repo: resilient-tech/india-compliance PR: 3620
File: india_compliance/gst_india/api_classes/nic/e_invoice.py:167-175
Timestamp: 2025-08-20T12:52:11.346Z
Learning: In the GST India API classes (india_compliance/gst_india/api_classes/base.py), all JSON responses are automatically converted to frappe._dict objects using `response.json(object_hook=frappe._dict)` at line 151. This means that any dictionary objects in API responses already support attribute access and don't need manual wrapping in frappe._dict.
Applied to files:
india_compliance/gst_india/utils/taxes_controller.py
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (4)
- GitHub Check: Codacy Static Code Analysis
- GitHub Check: Python Unit Tests
- GitHub Check: Mergify Merge Protections
- GitHub Check: Summary
🔇 Additional comments (2)
india_compliance/gst_india/utils/taxes_controller.py (2)
114-120: Order of additional taxable value calculation in set_taxes_and_totals is correctCalling
set_additional_taxable_value()beforeupdate_item_taxable_value()ensures thatitem.additional_taxable_valueis fully derived (or zeroed for non‑subcontracting Stock Entries) beforeitem.taxable_valueis recomputed, and the early return on non‑Stock Entry doctypes keeps other flows unaffected. The server‑side taxable_value logic now aligns with the updated JS controller.Also applies to: 152-172
291-340: [rewritten comment]
[classification tag]
1 participant
closes: #3765
closes: frappe/erpnext#50686
Adds e-Waybill generation support for new ERPNext v16 Stock Entry purposes related to the Subcontracting Inward feature:
Changes:
Summary by CodeRabbit
New Features
Enhancements
Chores
✏️ Tip: You can customize this high-level summary in your review settings.