Bahrain

1

https://localizations.manager.io/summary-view?FileID=QmFocmFpbg

1 Like
2

Hey Lubos,

I have just finished the localization for Bahrain.

There’s a few of things that I am not so sure about, namely:

  1. There are few tax codes (Import Customs, Export, GCC) which only apply to sales or purchases but never both. In case of incorrect tax code application, this will definitely result in discrepancies either in the Sales - Purchases = Net or Net as per Transformation vs Net everywhere else and that’s unavoidable. And it wouldn’t look professional to have these discrepancies slip by. SO, I took the liberty of creating an Exceptions line items in sales and purchases sections that summarizes incorrect application (i.e. Export for Purchases or Import Customs for Sales) so the user can see that the transformation isn’t wrong and also be able to easily drill down and correct the user errors.
  2. In order to remain true to the actual VAT return, there are certain tax codes/custom fields that are not yet implemented (i.e. GCC) or are rare situations with insufficient documentation (i.e. domestic RCM). I still created those but inactivated them just to be future proof.
  3. There are two types of adjustments in the VAT return: (a) current period adjustments/apportionment which are displayed as a separate column (not yet supported), and (b) previous period corrections (item #15). I am not entirely sure how to incorporate those but it seems like adjustments of type (a) can have their own tax code/custom fields. The user can then calculate those manually and pass them once in Manager and they should appear in a single line for sales and another line in purchases :confused:. The alternative is to create a separate adjustment code for each line item, which doesn’t seem practical though.

Speaking of adjustments, I also took the liberty to inactivate passthrough codes and create non-inventory items to restrict their use. What would be great is if we can use these non-inventory items in Journal Entries to process the adjustments without issuing Invoices.

Also, just to avoid Zero lines everywhere, I created a VAT adjustment clearing account to house all the Zero lines from Passthrough codes. This account was grouped with VAT payable account under VAT liabilities. This is tidier and also serves as a register for all adjustment posted which is another plus.

3

Thanks @lubos

4
  1. I agree. This is something that can happen in other localizations too. I’m experimenting with new concept called Tax Reporting Categories which would solve this problem.
  2. What do you mean by not being implemented? Is this something that Bahrain government hasn’t implemented yet or something that Manager doesn’t support?
  3. Current period adjustments should be handled by separate tax code. For previous period corrections, it would be good if this can be automated. For example, Manager could give you the difference between what has been lodged and what the figures are now. But for this to work, Manager would need to capture what has been lodged. This hasn’t been implemented. I’d leave this field out of the VAT return for now.
5

That’s not a big issue now, the current transformation works well either way but I can’t wait to see these tax categories.

But I guess they will enable limiting certain tax codes to certain transaction types? Because that would be great.

Unified GCC Taxes. It’s not yet implemented but it’s there in the GCC MOU and it’s also implied by item 2 in the VAT return.

11 additional tax codes to be precise and it’s not a single line item, it’s an entire column. I personally don’t report current period corrections separately, I just apply the normal tax codes for it.

I only use this column for apportionment of input VAT over exempt supplies.

This is the filing guide just for reference.
VAT filing manual

Should I create the 11 additional tax codes or leave it for users to make manual adjustments?

7

Hey @lubos,

I just added all the tax codes and related custom field drop-down items for each of the cells in the VAT return’s adjustments column but I’m not happy with it.

I was thinking the whole time that’s too much work to apply all these codes compared to using a spreadsheet to split the adjustment and then create 1 adjustment in Manager using 1 tax code for everything.

All of that for just 1 rate. In 2022, we’re going to have an additional rate of 10% so Idk. I think we’re well passed the 80/20 territory and into the 99/1 territory.

I might have another idea but I wanted to hear your thoughts first Lubos.

8

I like what you did with sales exceptions and purchase exceptions. Didn’t think of that but it is a problem across most localizations.

image
image1224Ă—244 11.5 KB

However, this is too much. It then rolls into other totals.

I’m strongly considering to drop the idea of having dual-purpose tax codes for both sales and purchases and simply replace it with single-purpose tax codes. Yes - we end up with more tax codes but report transformations should be easier to author and understand as a result.

1 Like
10

@lubos after the upgrade to latest version (VAT Returns) not working, kindly advise how we can generate the report from Report Transformation…

11

Would this change not cause havoc with historic VAT figures and reports?

12

The columns are not fetching any data just appearing text, it removed all the data…

Kindly make it simple and easy rather than adding codes may not be useful,

13

That can easily be avoided by inactivating old tax codes and creating new ones. Previous transactions will remain untouched.

14

I think there’s been a switch from Custom Fields to Reporting Categories, so the transformation probably has to be redone. Right? @lubos

I agree, 23 tax codes are too much for just 1 tax rate. But it’s the only way to get the adjustments/apportionment apply to each single line item in their own separate column. I’m personally not so keen on that. I prefer to process the adjustment in a spreadsheet and then create 1 journal item in Manager using 1 tax code instead of 11.

15

That’s why it was requested to add a 4th column but it was opposed, it’s not to get it by adding hundreds of codes in several rows rather than 1 column and now the main report in unfunctional???

16

Report Transformations can now have up to 6 columns (label + 5 data columns)

1 Like
17

How did you get that conclusion? Adding tax categories to 1 cell is just summing up totals and I am pretty sure computers can handle that without a problem.

18

@Ealfardan kindly share a complete report based on the changes, so we can see exactly the tax liability to the authorities…

A screenshot will be best!

20

@lubos, how is reverse charged rates going to work with categories?

Now that we have separate input/output categories with multiple rates, it seems more fitting to have that as 5% purchases and -5% sales.

I say this because I can’t properly categorize reverse charged tax rates to categories.

21

@Ealfardan this has been implemented in the latest version (21.11.20).

Under Reporting Categories, there is new reporting category type that is for reverse charged tax amounts.

image

So if your tax code is reverse charged, you will be able to select reverse charged tax amount category.

image
image996Ă—332 7.09 KB

You can then use this category on report transformation which will give you reverse charged tax amounts.

I know it could be a bit more confusing as there are 3 different reporting categories but each serves its purpose:

  • Net amount
  • Tax amount
  • Tax amount (reverse charged)
1 Like
22

The localization is almost complete, pending the following:

  • RCM taxable amount reverse sign to be used in totals
  • Tax codes be assigned to specific transaction types (Sales invoices, Purchase Invoices, Credit Notes, Debit Notes, Journals, Receipts and Payments, etc)

Also, I have dropped the detailed adjustment codes because they were too much and settled for 2 adjustment codes for sales and 1 for purchases.

23

I wonder why we need sales exceptions.

image