User Story

• Current architecture of Tax Category and Tax Template with Tax Rules is complex and need too many configurations.
• Also, its difficult to make customers understand them and its need.
• At times it leads to duplication of data, where validations may miss out and could lead to errors. Eg: When customer is from different state, there should not be a need to again specify tax category for that customer. Also, there is still no accurate validation between these two, and could lead to errors.
• Going ahead if users use the system to file the returns, proper validations need to be in place, to ensure errors at the time of transaction.

Current Tax Laws

How do we determine if its Inter State Transaction or Intra State Transaction?

It depends on Place of Supply and state where the company is located. If these two are different, then its considered as Inter State Transaction else its Intra State Transaction

How can the place of supply be determined?

References

• Place of Supply for Goods
• Place of Supply for Services
• Place of Supply for Imports / Exports

In most cases its the state of billing address of customer. However in exceptional cases it can be different. For Eg:

• For stay at hotel/food at restaurant or place where construction/installation on site happens, state where it is supplied will be place of supply.
• Where a professional is delivering a service (say giving a lecture), and that service is only given from this particular place and delivered there itself, the place of supply will be state where the service is given.

Exceptions to above scenarios:

• For Export or Import (Overseas or SEZ but not Deemed Export), Its always IGST that is applicable in these cases even if say SEZ is in same State (As it is considered as a different state i.e. other territory).

When is reverse charge applicable?

Reference

• Purchases made from unregistered persons (with some threshold of Rs 5000)
• Purchases made from specified persons (like transporter)

Proposed Solution

We propose that rows in tax table can populate automatically with just some basic configuration in GST Settings.

• In GST Settings, user can give default place of supply is based on Billing Address or Company Address.
• User will still have an option to change the place of supply, for some exceptional cases for any transaction.
• Based on the place of supply vs state of company, we can populate tax accounts in tax table.

How can we determine tax rates?

As a part of Item Tax Template, we only need the tax rates applicable to that item or if not applicable if that item is nil rated, exempted or zero rated and we can then apply them accordingly.

How can we deal with concessional tax rates or cases were we would like to exclude a transaction from GST returns?

We plan to have a field where if user chooses Out of Scope, the transaction will be not included in GST returns and no taxes will come up.
Also, if user uses Concessional Tax Rates, he will have option to override item tax rates (Say, 0.1% for goods meant for exports).
eg: Supply to Merchant Exporter

How do we ensure branch transfer in GST?

As a part of GST Settings, where user currently specifies the GST Accounts, we can ask for GST Accounts for each GSTIN. Rest within a transaction, we are already considering Company Address/ Company GSTIN to check which tax accounts are applicable.

How can we handle reverse charge?

• Again in GST Settings user can enable reverse charge transactions. They can set a custom threshold for purchases from unregistered persons.
• We already are differentiating transporters in supplier through a checkbox. So we can make it configurable to ensure reverse charge for all transporter.
• For other suppliers also we can enable this through a checkbox.
• For each purchase transaction, there will be a checkbox to check if this transaction comes under reverse charge.

eg scenarios:
Unregistered Supplier --> Purchase Less than Threshold --> No Tax Accounts.
Unregistered Supplier --> Purchase More than Threshold --> Reverse Charge Accounts.
Registered Supplier --> RCM Applicable --> Reverse Charge Accounts

How do we handle complex transactions like exports or deemed exports or SEZ?

Exports/SEZ shall be with or without payment of tax, as per default GST Settings if LUT is available. Deemed Exports shall we with payment of tax. More on this in a separate topic.

How this method will ensure complete validations?

In case user has defined something incorrectly at an earlier stage, incorrect taxes comes up, and will not match with the invoice provided by the Supplier. Also, where a sales invoice is made, incorrect taxes in sales invoice will mean masters are not correct. This will also ensure that all masters are updated and correct.

Debateable Issues

How do we migrate existing users?

We suggest not to migrate, as its a part of configuration which users may have been used to until now. Also, errors here can cause issues. So, tax category and template stays for those who want to use it. However user can make few settings and opt-into this method / trigger manual patch to clear existing settings.

What if tax accounts that come up are not acceptable to user? If there is some other account he wants to use in exceptional scenario?

This is completely unlikely considering we also cover exports and imports.

What if user wants to maintain separate tax accounts for each tax rate?

Separate tax accounts for tax rates:

• Does not solve any problem (alternatives are already available, or a separate report can be easily available for same),
• Is difficult to maintain, and complicates existing process, (difficult to reconcile with GST ledgers)
• Not required by law
  Small standardizations like this will simplify managing/maintaining this.

Following Options can be provided for generation of e-Waybill

• e-Waybill on Submit if criteria is fulfilled and transport details are available or Only prompt for e-Waybill after submit if criteria is fulfilled can go as a select field
• Criteria for e-Waybill based on bill value. Field to give a value, based on which prompt or creation can be done (say, Above Grand Total of Rs 50,000 if goods are a part of invoice).
• Print e-Waybill after it is generated. can go as a check field
• Issue #23

Default settings will apply only for new users

Currently, the is_inter_state variable is set to get supplier_gstin[:2] in line 214 of transaction.py under overrides. When the purchase is made from an overseas supplier, this causes an error since the supplier GSTIN may be blank in this case.

TypeError: 'NoneType' object is not subscriptable

Use case

• Different tax rate based on Item Price

Things to resolve

• Issue with item_wise_tax_detail in taxes
• Update its usage at all places

• Rate of tax is required --> Amount needs to be calculated --> Total stays unaffected.
• Appropriate rates and disclosure in GSTR1.
• Partial reverse charge ?
• Validate tax templates accordingly

Current Scenario and issue

• e-Waybill needs only HSN breakup of item details, but item-wise details are being sent to the portal.
• Nothing incorrect about this, but e-Waybill only supports 250 line items in e-Waybill.
• This is generally enough for 99.99% of transactions.
• If there are more than 250 items, its currently not supported by the API.

Proposed Solution

• if there are more than 250 items, hsn-wise summary of items can be uploaded to e-Waybill.
• get_item_list from transaction data can be over-ridden in e_waybill utils, and HSN summary can be returned if there are more than 250 items.
• current validation of 250 items can then be removed.

See Frappe repo for more details.

Issue:
Should contain Input and RCM accounts. Currently, it only includes RCM.

Reason to propose a change

• Duplication of Data.
• This field is now being auto-set from the backend, and user have no control over it.
• Now there is no dependency on this field once state field is made auto-complete.
• Added Advantage: Future changes to state-codes will not require patch

Dependency

• Currently gst_state_number is being used to set Place of Supply
• Places where GSTIN Info is being fetch from Address, gst_state_number is used.

Solution

• We have achieved consistency in state, by keeping it auto-complete for India.
• State number can be fetch from this state at all places where gst state number was used.

Currently user manually enters the distance between pin codes. It could raise errors if it is not within tolerances of e-Waybill portal.

Enhancements possible:

• e-Waybill APIs give us an option to automatically calculate the distance.
• We can have GST Settings (as Automatically take e-Waybill suggested distance) where user can hide distance field with default value as 0.
• In such scenarios we can have distance calculation done automatically.

Useful

• frappe/erpnext#31143: This PR is related to changing the flow of e-waybill with IRN. changes are similar to our new India compliance app. but seem some of the features we can use in our app.
• frappe/erpnext#30927: patches and regional setup file a change of custom field can merge in our app. Also a fix for an unallocated amount in Payment Entry
• frappe/erpnext#30873: It seems available in India compliance.
• frappe/erpnext#31310: Minor change of removing if condition from get_outward_items() @DaizyModi
• frappe/erpnext#31236: Remove condition and p.gst_category != 'Registered Composition' from get_inward_nil_exempt() in gstr_3b_report.py @DaizyModi
• frappe/erpnext#31187: Need to change def calculate_annual_eligible_hra_exemption() according to regional/india/utils.py to the app India compliance salary_slip.py @DaizyModi
• frappe/erpnext#31120: Added company_address in const party_details. Need to add in transaction.js @DaizyModi
• frappe/erpnext#30948: invoice_type should be DBN for debit_note CRN for is_return else INV in e_invoice @DaizyModi
• frappe/erpnext#30626: added featur of intra-state union territory. @DaizyModi
• frappe/erpnext#30542: Ignore disabled tax_categories in get_tax_template() in transaction.py @DaizyModi
• frappe/erpnext#30525: Required to change accordingly in def get_regional_address_details() in transaction.py @DaizyModi
• frappe/erpnext#30385: Added Auto tax fetching for Quotation doctype too.

Need to merge?

• frappe/erpnext#31264: changes in stock_controller.py, test_customer.py and test_delivery_note.py.
• frappe/erpnext#28359: Changes related to our app:
  • Postgress support in gstr_3b_report
  • minor changes in setup.py for MAX_WRITE_PER_TRANSACTION
  • IFNULL to ifnull in gstr_1.py
  • added Group by with tabGST HSN Code to get_items() function in hsn_wise_summary_of_outward_supplies Report
  • create_gst_payment_entry_fields.py, just used create_custom_fields()
• frappe/erpnext#31188:
  • It seems in India Compliance, is_ewaybill_cencellable() is being implemented to check e-waybill is canceled and so no need to do this change.
  • Doubt in utils.py for update and cancel e-waybill code
• frappe/erpnext#31055: e-waybill cancellation as per new rule. It seems we have already covered this.
• frappe/erpnext#30978:
  • validate_sez_and_export_invoices on hooks validates the SEZ invoices for GST, it seems covered in India Compliance
  • Sync HSN Code button on GST Settings to update GST HSN Code
  • Child table for HSN Tax Rate in GST HSN Code
  • Mapped GST HSN Code and get_hsn_wise_tax_rates in gstr_1.py Report
• frappe/erpnext#30946: Need to add Generate QR Code button?
• frappe/erpnext#30923: e-waybill distance calculation
• frappe/erpnext#30912: It seems no need to set empty string or None for Mode of Transport
• frappe/erpnext#30800: It is about cess_value. I don't think it is required.
• frappe/erpnext#30774: Change of ignore_duplicates=True in erpnext/regional/india/setup.py. If required need to change in App's company.py -def create_company_fixtures()
• frappe/erpnext#30757: It seems HTTPError is being managed by India Compliance. but need to check once
• frappe/erpnext#30055: It is fix for ImportError while installing country fixtures
• frappe/erpnext#30389: Reset gst_state and gst_state_number. Seems not required.

Not Required to merge

1. frappe/erpnext#31275: As we had removed utils.py from erpnext, no need to merge this PR
2. frappe/erpnext#31234: As def get_company_gstin() has been refactored in the new India Compliance app with the def get_company_gstin_number() in gstr_1.py
3. frappe/erpnext#31154: Changes related to QR code in e_invoice utils.
4. frappe/erpnext#30553: As we are checking for max_length=18 in def get_mode_of_payment()
5. frappe/erpnext#31061: Fix for Json Parse in utils.py
6. frappe/erpnext#31024: Related to e_invoice/utils.py but not needed
7. frappe/erpnext#30968:
8. frappe/erpnext#30941: No need as we have already taken care of fields in proper order
9. frappe/erpnext#30924: No need, already added cancel e-waybill
10. frappe/erpnext#30877: Already added B2B for Register Composition and Registered Regular gst category
11. frappe/erpnext#30876: No need as supply_type is already managed as per requirements
12. frappe/erpnext#30747: No need as already using transporter_name as TransName in e-waybill
13. frappe/erpnext#30580: e_invoice print format changes. Added condition for if signed_invoice is available.

• Edit Patch
• Edit Workspace

Current Issue

• Fields is_nil_exempt and is_non_gst are currently part of item doctype.
• Needs to be set to all items where its required.
• Conflict with item tax templates. Although they may not be set in item, they may be set in item-group or hsn-code.
• Conflict between the fields. Both fields can be chosen, and it would be inappropriate.
• No validations are present to enforce this.

Proposed Solution

• these fields are related to taxes. they can be safely moved to item tax template.
• create item tax template for them by default on company setup
• patch for existing items, to add item tax templates for nil rated or non gst to the item.
• validate tax rates they are chosen in item tax templates. It should be zero (0) for all tax accounts chosen.
• fetch this in transactions from item tax template instead of items.

• is_reverse_charge to hide and unhide instead of delete
• Validations for Sales Order / Delivery Note / Sales Invoice in Sync with each other
• State Autocomplete for Quick Entry Dialog (Party and Address)
• Improve Address Split
• remove report GSTR2

User Story

Note: Party here means Customer, Supplier, Company.

• GSTIN and GST Category should be part of party. This is a general behaviour and so, GSTIN in Address could be a little confusing for users.
• GSTIN and GST Category should stay together. GST Category depends on GSTIN and GST Category defines registration status and treatment of transactions for a party. For eg: whether party is Registered / SEZ depends on GST Category which further depends on GSTIN.

However, GSTIN / GST Category could be different for some of the addresses. (Say, one business unit is in SEZ and others are in Domestic Tariff Area - DTA or party has office in different states)

Proposed Solution

1. GSTIN and GST Category can be part of party.
2. This can stay same for all addresses linked to a party.
3. GSTIN/GST Category from Party shall be visible in Address as read-only field.
4. Where it is different for specific address, there will be option to have different one for address. (a Checkbox)
5. If there are more than one party linked to address, checkbox should be ticked.
6. When GSTIN is changed in Party, it will update automatically in address linked to it where it is same.

Added Benefits

• Better user experience.
• Party information stays in party.
• GSTIN and GST Category stays together.
• Easy to update GST Number at a later date.

• Handle bulk e-Invoice generation and cancellation.
• Bulk e-Waybill JSON generation.
  • With update existing values
  • Without updating existing values

This error message is required for SaaS users (i.e. users with ic_api_secret in site config)

Current Issue

Following are the accounts settings that need to be handled

• Determine address tax category form: This should be always Billing Address for India specific users. Inter State vs Intra State is based on Billing Address GSTIN, So this should be set to this by default.

• Automatically add taxes and charges from item tax template: This should be always untick by default. As per current design, we are having all taxes (input, output, reverse charge) in one template. If this is enabled, it will fetch all taxes and this is not what a user wants.

Proposed Solution

• Post Install Patch for above fields.
• Property setter to make this fields Read Only.
• Description to make users aware that these settings are overridden.

• New Doctype for GSTIN Status (With Last Update Date)
• Show status in description where available
• Dialog to show GST fields and status (may be Link below GSTIN). This will result in fresh API calls to show formatted Status.
• Constitution of Business in Party Fields
• Prompt in Sales or Purchase Docs if GSTIN is Inactive
• GST Status in Autofill - From API - Warn if not Active
• Save GST Registration Date and Cancellation Date. Transactions not falling in this range should be warned about and not allowed.

Refer #21

To begin with, keep both functions.

• Update its use only in new functionality developed or maintained.
• Don't update its use in GSTR1 and GSTR3B.
• Update old function with new field created in GST Account.

Currently,
Reverse charge as a field in Sales Invoice comes even if you never make a reverse charge sales. (Common for most users).

Proposed Solution:

• GST Settings: Enable Reverse Charge in Sales Transactions (as a checkbox).
• Field will be created in Sales Transactions only if this is set.

Patch for existing users:

• GST Settings will be disabled if no reverse charge sales transaction.
• Delete this field.
• Move this field as a checkbox on top, if applicable to users.

Currently, this gets set from the API. But there is no fallback for users without API / if API call fails.

For server side and independent use

In e-Waybill Log a link for field ewaybill referencing to Sales Invoice is added which never seems to get added in Sales Invoice which causes an issue during installation

Current Issues

• GST Category should be part of masters only, and should not be allowed to be edited in transaction.
• Its way below as a part of GST Settings, and can be highlighted on top along with customer/supplier.

Fixes Proposed:

• Make GST Category as hidden field.
• Fetch GST Category from Billing Address in Sales Transactions and Supplier Address in Purchase Transactions.
• Highlight this field below customer or supplier field (as description to it).

HSN Codes with different tax rates should come on different line

import statements are not valid in JS and prettier keeps complaining about it.

TODO:

• Move common functionalities to public and import it using frappe.require

• E Invoice Request Log is no longer required if its maintained with integration request list.

• sort fields
• is_system_generated
• contextual get_region for regional overrides

Current Scenario:
We are using thefuzz to suggest where state is incorrect.

Improved Solution:

• Make State AutoComplete field instead of Data Field.
• Using query, add/remove options to State based on country.

• Check if required?

Check if 0 and 1 work in cleartax templates.

Under current auto-fill design, GSTIN status is not being validated although available.
Its very much possible that GSTIN is cancelled or inactive while a customer or supplier is being created.

Proposed Solution

• Update description of GSTIN with the status of GSTIN when autofill is triggered.
• Warn user (with a message print) if status is anything other then active.

Field before autofill

Field after autofill

Currently Export Type is a Select field. However it should be a check field.

• Export with payment of tax

User Story

For Purchases made from Registered Composition, credit is not available for input taxes.

Validation

We need to make sure that input taxes cannot be claimed for the same. GST Account validation should suffice

Similar to how it is implemented in frappe/public/js/frappe/widgets/widget_dialog.js

Possible Fix

In E-Waybill Log, Document Link should be added or removed based on enable_ e_waybill (GST Settings)

Even for new installations some patches seem to be running

Currently Place of Supply is being set from Billing Address or Shipping Address

How it should be?

• Place of supply should be ideally as per Billing Address and if missing, as per Company Address.
• For some business, It should be always as per Company Address (Configuration in GST Setting)
• It should be editable and not read-only. Select field would be a better choice.
• It should be mandatory for GST Invoice.

This fields should be fetch from first customer address/ supplier address and if not available from party.

Current Issue

For a multi-company setup, If e-Invoice or e-Waybill is not applicable to all companies, auto-generate functionality would fail, as it would attempt to generate e-Invoice for all companies, and would get errors.

• Scenario 1:
  For a specific company, e-Waybill or e-Invoice is not applicable.

• Scenario 2:
  For a specific company, e-Waybill is applicable but e-Invoice is not applicable.

Solution 1:

Having separate password for e-Waybill and e-Invoice. Silently failing if password is missing for Auto Generation. Throw for manual trigger of generation.

Solution 2:

Have a negative list of companies for e-Invoice and e-Waybill (as a part of settings). Could be a table multiselect field. e-Waybill or e-Invoice generation will not be triggered for these companies.