1

(21 replies, posted in Wish List)

It is neither practical nor logical in Pakistan, because you end up messing with weird tax structure, and THIS is the system, we have to abide by the law and procedure.


boxygen wrote:

Ok now if Invoice is digested for the time being lets discuss Purchases.

Practically and Logically if a Manufacturer (ABC) sells a Candy to a Non Registered Retailer (Xehroz) @ Rs. 70 then then invoice shall reflect as below

Inventory                  70
       GRN Account                      70


GRN Account            70
17% Tax                  11.9
3%   AT                    2.1
2%   ET                    1.4
            Payable                          85.40



This thing is followed countless times everyday in Pakistan, limit is upon imagination, and THIS STILL WORKS here.

boxygen wrote:

But What I am understanding that even the ABC Supplier is Invoicing at 70, but he is applying All Taxes on MRP i.e. 100. Is that Right? as below

Inventory                  70
       GRN Account                      70


GRN Account            70
17% Tax                  17
3%   AT                    3
2%   ET                    2
            Payable                          92



Simply because you have to maintain the record,...

boxygen wrote:

IN that case wouldn't your Input Tax will always be Equal to Output Tax? If true, then is it necessary to do all this accounting of Taxes as Retailer? Simply you can record all your purchases @ 92 and record all your sales @ 122 and your Rs. 30 Profit will be there and you have no Tax Liabilities. Any way I raised this point just to understand your need to Record all taxes.

Now i am going to work on this, & do some testing. I would have to setup a new instance.


boxygen wrote:

Now lets come to your problem. If any way you need to record all Purchase Taxes on MRP then we will have to modify FA Purchases to link it to the MRP. MRP can be defined as a Sales Type Retail in FA and can be used for calculating Tax Purchases.

It will have no Adverse impact on Input and Output Tax working. It will show something like THIS


In the end i want to thank everyone specially @boxygen for generous advice and working. Kudos :-)

2

(21 replies, posted in Wish List)

OK, then what if i wanted to log purchases into system, what is your take on this, what would be the impact? would it be vice versa? i.e. i have to adjust the cost using discount? What would be impact on Tax Input & output in that scenario? Will i have to tell FA to calculate tax related stuff on "Value before discount"?


boxygen wrote:

My previous solution is self explanatory depending on your statement that you want to setup this for Retailer.

Retailer shall always sell the product on MRP. 100 was taken for simplicity. It can be any number but it shall be MRP.

And your all taxes apply on MRP.

As a retailer the case will be very similar to Registered Buyer invoice for candy and non candy.

And this solution is without any hack.

3

(21 replies, posted in Wish List)

This is some kind of "Hack" but in terms of Tax law, it might create discrepancies. Because ASAP the system in Pakistan is based upon Input & output, plus what if we have to make an composite invoice, with multiple line items. Some times every other item have a separate formula to calculate markup, end user might have to setup that kinda discount formula setup. It sounds complicated.


Therefore, it is requested to elaborate your previous solution in detail. 


boxygen wrote:

Yes, this is achievable if the Price Before Tax is set to 100 PKR and Resulting Net Price to the Buyer is calculated as a discount say 15% of MRP = 85 PKR.

A little modification in the Invoice Write() function to link the Tax Calculations to MRP instead of Resulting Net Price can achieve this.

4

(21 replies, posted in Wish List)

This is quite simple i was also able to achieve this, but what if i change the price from 100 to let us suppose 85PKR or 70PKR?????? the system will pick the new price 85 as a base for taxation and add 17% into it which is about 85 + 14.45 = 99.45


Where as i want it to pick up 85 + 17 = 102

I mean the value of tax i fix. Is this thing still going to work????



5

(21 replies, posted in Wish List)

I am setting this for a retailer. and you hit right in the bull' eye.



boxygen wrote:

Question # 1: Are we trying to setup this Tax System for the Manufacturer or Distributor or Retailer? I am assuming we are doing this for Manufacturer.

Understanding # 1: MRP = 100 and all Taxes are being applied on MRP on each intermediary selling steps (irrespective of the selling price at each step ** ) till it reach End Consumer. Right?

** for e.g. This Candy's Manufactured Cost could be 70. It was the sold to the Retailer at 90 but the taxes are applied keeping MRP as a base.


I have seen your file it is exactly what i wrote earlier, only difference is that you tabulated that in a more recognizable format. The reason i didn't mentioned the detailed accounting was that these are obvious standards anywhere in world, i just jumped directly to the point.



boxygen wrote:

Comment: Normally in Distribution Setup Where MRP is always the Base, the Selling Price to Retailer is also defined as a discounted MRP price. But you didn't mentioned that. If this is possible then it will be much easier to implement this within the current Tax System of FA with small modification.

You didn't mentioned the Fixed Value Rate handling mentioned in This Doc

I have create an online sheet. Please check Click Here



But the question still remains HOW to do this in FA, as i mentioned earlier, do we have to just add a custom field in product file or what??

Please elaborate your solution to this.

6

(21 replies, posted in Wish List)

Now you are close enough to my point, but our international audience is not aware of this, so i have to bring this in another way.

boxygen wrote:

@xehroz, I didn't went through your documents before my first post. Now I have read in detail. The case you are referring here is mostly FMCG products distribution setup. Unfortunately I didn't come across such situation because majority of my clients are service based.

It is complicated but I'll come with another simple to understand example.
Let's assume one product called "Super Candy" is sold to consumers at PKR 119
Breaking of this is (100 as MRP + 17 ST + 2 ET)

First situation
The Manufacturer sell this to it's registered customer (In this step to a Retailer) at following rate
90+17+2=109
90 Goes into COGS account for that product
17 goes to Sales Tax Account for that product (this can be passed on / Claimable)
2 goes to "Extra Tax" account for that product (this can also be passed on further to next customer  / Claimable)

Second situation
The Manufacturer sell this to it's Un-registered customer (In this step to a Retailer) at following rate
90+17+3+2=112
90 Goes into COGS account for that product
17 goes to Sales Tax Account for that product (this can be passed on  / Claimable)
3 goes to "Additional Sales Tax" for that product (THIS CAN-NOT BE PASSED ON FURTHER / non-claimable)
2 goes to "Extra Tax" account for that product (this can also be passed on further to next customer / Claimable)

FYI Passed on or claimable means that this amount of tax can be claimed while filing monthly sales tax returns and the customer may get a rebate / refund / adjustments subject to other things, it is can be adjusted in your tax return. Pass-on means the same in terms of "SALES" i.e. you can ask your customer "By law govt. has collected tax on this from me through my supplier and i am passing on this load to you as per law". Additional tax cannot be passed-on if some registered retailer is charged with this, this would be his EXPENSE he would have to bear this.

THIS was all from "Sales" point of view.

From procurement side it is the same as sales, you log the difference in cost and sale price into profit and difference of ST, ET is also logged and difference is paid accordingly to govt. only additional tax is recorded as expense.


boxygen wrote:

But this is quite interesting and I would like to understand it first. Based on your two documents can you please state some examples with Basic values for each type of Item category and tax category. I want to see the complex formulae that are being applied in any single case.

for e.g. Item A Cost = 90, MRP is 100, Tax is 17%, Additional is 3%, Extra is 2% then What GL Transactions shall be recorded when this Item is sold and What OutPut Tax accounts are Credited.


The only impact in this case would be upon "Un-Registered" retailer or distributor, i.e. when he makes a purchase he would be charged additional 3% tax, but he CANNOT pass-on this to his customer, for example the consumer will pay only 17% of MRP + 2% Extra Tax. This thing was introduced to encourage registration (in other words documentation and traceability) and discourage un-regulated trade. 

boxygen wrote:

Also the impact of Item A for each type of Registered, Unregistered and End Consumer.


Yes according to law toffees etc. are always charged a tax called "Extra Tax" which is @2%

boxygen wrote:

If Item A is defined to be confectionary item then it will always be added 2%?

We have to log all these separately and would have to display/produce this record separately.

I hope this will develop common understanding. and i wish nothing is left.

Shehroz

7

(21 replies, posted in Wish List)

As you said you have implemented this system in various organization across Pakistan, and i guess you have followed my post, specially if you have already seen both of these links, i assume you are already aware what i am talking about. It is quite clear.

I am also planning to implement this according to Pakistani law and standards, but it is not working.

I am not sure that i would go for some kind of proprietary and paid services, definitely i am here for some community FOSS solution.

https://github.com/xehroz/SaleWise/blob/master/PAKISTAN%20SALES%20TAX%20REGIME.pdf

&

https://ibb.co/NmLCXNW



boxygen wrote:

Hello @xehroz, I have implemented FA in more than 50 companies in Pakistan. You can send me email or call me to discuss your issue. Once settled we will post here so that others can be benefitted.

8

(21 replies, posted in Wish List)

I have already seen that post, it is related to Income Tax regime, plus in his case he was a "Service Provider" it is completely different thing.

In my case i am talking about real physical products which falls in "Goods regime"


poncho1234 wrote:

This users post has a different take on the tax system in Pakistan?

9

(21 replies, posted in Wish List)

It is strange, and confusing, but this is the system and scenario in Pakistan.


FYI look at this invoice and tell me if it is not weird. Such complex piece of ***t. (please see the link)

Too much complicated for me... (I have removed any private data from image)


[img]https://i.ibb.co/txbKS2Y/inv-sample.jpg[/img]




oakstreet1 wrote:

Sorry, I'm not sure exactly what you're asking. It does sound a bit strange.



If someone from Pakistan or some Chartered Accountant is on-board, that might ease out.
I took almost 4 months to understand this. FYI this is sometimes Called 3rd Schedule items in Pakistan.

10

(21 replies, posted in Wish List)

First of all thanks for your reply!

This will partially resolve the issue!

But problem comes when the tax is calculated based upon Maximum Retail Price, whether it is in the first stage of product life cycle, that means, if the product have three price tiers, let us suppose for company's authorized dealer gets a product which is to be sold at PKR 117 (In this the retailer will get 100PKR and 17PKR is the value of tax) the manufacturer will sell this as per law or policy at 90 PKR + 17 PKR tax = 107 PKR to it's dealer, at the end when the transaction occurs at the dealer' end, outcome would be PKR 10 as profit in Gross profit account and 0 PKR in respective tax account head.

I think if it is possible adding a custom field in product' characteristic table might resolve this (i really don't know if this thing is practical).

Plus customizing the invoice template would be essential (actually it is a legal formality to produce invoices compliant to sales tax law), but this is the other part of story.

oakstreet1 wrote:

I suggest you read the Wiki on the tax configuration for FA. It should be able to accommodate what you describe quite well.

First you would create all of the taxes that could be applied, with their respective rates and whether or not they apply to shipping.
Then you create tax groups that specify which taxes will be applied to that group. You can also create tax exempt groups.
Next, you set the tax group for each customer branch, so each type of customer may have their own tax configuration.

I hope I understood your question.

11

(21 replies, posted in Wish List)

Hi Everyone!

I don't know if this is the right place to post a question, anyhow i feel it is better to just ask.

I am new to FrontAccounting, and i am trying to set-up tax in this system.

The problem is not this system, it might be the complexity or that might be due to my grip on this.

We have a very strange sales tax system in Pakistan (sometimes it is mis-understood as VAT but it is to extent not)

In Pakistan their are some product categories that are charged with tax based on MRP, whether you are an end consumer or retailer, Plus there is a separate rule for charging tax i.e. you charge at different rate to some "Registered customer" and different rate to some "Un-Registered Customer"

I know my whole debate sounds creepy and awful, so i have made a document which contains some detail (overview) on this.


https://github.com/xehroz/SaleWise/blob/master/PAKISTAN%20SALES%20TAX%20REGIME.pdf


It is requested to look into this and advice.


Cheers
Shehroz