I cannot comment on the pros and cons yet until I explore all the use cases. but I was trying to get the net sales value of the tax codes and I cannot see the option for net sales now. were they removed because you are working on it?
maybe you can implement advanced control for tax codes based on multiple filters from different tabs. since everything will be provided through localizations you do not have to worry about the simplicity for end users. in the end a guide specific for each country could be made available on the localizations page with explanations and instructions to utilize the features.
I can see how you implemented irrecoverable taxes based on the Ghana topic. while it can be used for tax component as a whole, we cannot use it where irrecoverable taxes are based on individual goods and services. so the requirement varies for every country and enabling advanced controls might help for everyone.
More complex for people actually contributing localizations
And also more complex for end-users because itâs not straightforward how transactions flow to country-specific reports.
In your case. Itâs just easier to provide two sets of tax codes.
CGST + SGST 5% (outward)
CGST + SGST 5% (inward)
because who knows. There might be an exception where you really want credit note to offset outward rather than inflate inward or something like thatâŚ
But this is general-purpose feature. Not Ghana-specific. I donât see why the same principle cannot work in India. Can you demonstrate why not?
we can coordinate with you just like we are doing now.
end-users will not have to setup tax codes if everything is provided by default through localizations. also, it could be possible to keep the page simple like it is now and show advanced controls only when user enables it.
this might actually work. but I am just concerned about the number of tax codes it will need leading to more confusion for users.
because in India the input credit can be based on the type of business and/or specific goods or services. it is not just simply which tax component can or cannot be claimed as input credit. for example, a registered business who has registered under Composition Scheme is not eligible for any input credit while a normal registered business will not be eligible to claim input credit on goods/services which is not used for the furtherance of their business and on specified goods/services declared by the government.
Itâs not just that. I will need to review all changes to localizations and too much complexity would make reviews non-trivial. Also, I donât really want contributors to have to walk on egg shells - like one wrong move and they break something. This would lower number of contributors.
Even as it stands now, I donât really think Iâve nailed it. Still experimenting with some ideas.
That used to be my concern too but people also get confused when system is trying to be too clever and too magical.
So people will get confused either way but itâs easier to troubleshoot issue in dumb system than smart one.
That just means more tax code combinations. I know in some countries, the number of tax codes could be quite long but we could simply mark the ones that are not very common as Inactive
while I do not know the complexity of implementing a feature in Manager, I have an idea where the user can specify rules for tax codes while keeping the list short.
I will explain with few of our requirements as an example.
have a checkbox or custom field for Suppliers to identify if they are reverse charged. create tax code rules when such supplier is selected on a purchase invoice. the tax code rules will specify the liability account, tax reporting category and whether it is credit or debit to the account.
have a checkbox or custom field for Inventory and non inventory items to identify if input credit available. specify tax code rules similar to above.
basically the filters will be based on the default custom fields we create in localizations.
end-users will have no need to create or edit these rules when they are provided as localization covering every use case.
Localizations must have âread-onlyâ impact on your business data. So some kind of rules within localizations which have potential to change your figures on your financial statements is bad.
Anyway, right now, the way I see it, there will be many tax codes in India.
but these are mandatory changes to show the correct figures as per the law.
anyway there could also be an option to enable or disable the said rules and the present tax codes will function normally.
yes. probably more than the combined total of every other country using Manager.
I will update you with the localization progress. any update on the limit of number of columns in Report Transformations?
now that we are agreeing to go forward with this method, can you provide a field where we can categorize these tax codes as outward and inward.
something similar to Item code field for inventory items.
while selecting on transaction forms the dropdown list should be displayed as Outward - CGST + SGST 12% but the transaction form should only display the name CGST + SGST 12%
yes obviously. it is mandatory to display the tax rate applicable for each line item and there can be different line items with different tax rates.
also, I think it would be better to show CGST + SGST 12% rather than CGST / SGST 12% because the latter gives an impression that it is either of the two tax components.
also, please clarify when there is only one tax component.
for example, IGST 12%
just to make sure that we are on the same page, I was referring to displaying the tax code on line items. the present implementation for the Totals section can remain the same.
another suggestion.
instead of Inward and Outward, in my opinion the correct terminology would be Inflow and Outflow or Input and Output because we are only determining the flow of tax amounts irrespective of the type of transaction.
Sorry for my intrusion but hatâs great news, globally. I hope we could be able to restrict some tax codes to specific transactions like just credit notes or just journal entries.
@lubos similar to the screenshot in another post below, why is it that we are unable to see any accounts like Net Purchases or Net Sales in our localization. it was there previously although not working.
Thatâs not an issue. We know we need separate tax codes for outward and inward. Iâll figure out so the presentation is right on invoices and the words âoutward / inwardâ or whatever you choose will not leak into printed invoices.
Also, I know we end up with many tax codes but I will probably implement some mechanism where you can specify transaction form types where these tax codes should be applicable so they are not a choice everywhere. This will make things simpler for user so they wonât see inward tax codes on sales invoices as an example.
