Transfering goods between EU countries

Miklos_HollenderMiklos_Hollender Member Posts: 1,598
Background: in the past a company usually just did business in one country, and if they wanted to do business in another they founded a subsidiary. This is not the case anymore.

In the EU a company can without a subsidiary easily have VAT Registration No. in multiple countries, rent or own warehouse in multiple countries and store goods in them and sell them. This means that generally they must hand in VAT, VIES (German: ZDM), Intrastat etc. reports in multiple countries. This is something that is not covered fully by Navision (VAT is doable but Intrastat is meant for 1 country only in Navision, unless you turn all of your warehouses into a company which would be a really bad idea, but we managed to customize this one), but the big problem is this:

We now received a very very clear opinion from the auditor that if you transfer goods from one country to another you must ALMOST treat it like a sales: report VAT, report VIES (Ger. ZDM), report Intrastat, even have G/L postings! (Auditors and tax controllers in Germany don't care about the VAT Entries table they are always like "show me the G/L!") And make an intra-company Pro Forma Invoice to document it all. So this sounds _almost_ like posting sales and purchase but inside your company.

From this on I have two options. (Setting up multiple companies is not an option.) Either I customize the living hell out of Transfer Orders, which I would rather avoid, or I really handle it like a sale and purchase: set up a dummy customer, dummy vendor, post sales invoice, post purchase invoice.

If I do this, I have one huge problem. I cannot really do it in such a way that the inventory value stays unchanged and that is a problem, isn't it? I mean ideally if I want to replace a Transfer Order with a Sales Invoice and a Purchase Invoice, I should make sure the sales price and purchase price = the adjustment inventory value, so the Cost Amount (Actual) of the sales invoice right, so there is profit no loss whatsoever?

I don't think that is doable, even with customization. Because the Adjust Costs could change your Cost Amount (Actual) even later, right?

But even setting that aside, just in general how would you do it, would you make a function that reserves some stock on an unposted sales invoice and then calculates from its Cost Amount (Actual) a sales price that equals to having 0 margin on it? So you end up on your sales invoice Sales Amount (Actual) = Cost Amount (Actual) ? Then use the same prices on the purchase invoice? This just does not _feel_ right. When you do such projects long enough you feel it in your bones - this is problably not the "natural" solution for the issue. A requirement that would force an invoice to always have 0 margin and price = cost is not "natural". Nobody does this. The EU regulators did not want to make these rules SO blatantly incompatible with our ERP systems right?

I mean how would you approach the whole situation? The auditor cannot tell you how to handle it in your ERP, and most ERP guys including myself (10 years of experience) have never faced such a situation (company owning stock in multiple EU countries), even though in the EU it is legal and acceptable!

Can one of you do a favor and ask people who consulting in SAP - maybe there should be a whole "granule" like "zero margin internal invoice" or something that we are not having in Navision?

Or does this have a simple solution? Should I just not give a damn about not chaning inventory value?

Comments

  • FDickschatFDickschat Member Posts: 380
    I did such a thing for a customer with his customers being in several EU countries (DE, AT, FR, BE, NL, LU, FR,...) and warehouses in DE, FR, UK and BE.

    In an ideal world we would customize the Transfer order with Posting Groups, VAT,... but as you said that is simply too much work and we avoided that.

    What I did for this customer is a very simple solution. We dd not integrate it into the posting functions but added a month end procedure for this:
    We created a report "Transfer Document" which filters item ledger entries in a very special way. Our locations have a VAT Country Code and a VAT Reg. No. So when filtering on ILEs we filter transfers and create a report grouped by "From Location VAT country code" and "To Locaton VAT Country Code" As a value we print the cost amount (actual). You also need from a From VAT Reg. No. and a To VAT Reg. No. (in this case form the locations).

    Finance takes this report once a month and posts is in G/L. The auditors found this procedure very acceptable.

    What about Sales:
    Is there at your customer a 1:1 relation between a customer (or better a ship-to address) and a warehouse? If you ship from different countries to the same ship-to address you would need to amend the VAT Bus.PostGrp in sales documents. We also did a small modification for this.
    Frank Dickschat
    FD Consulting
  • jglathejglathe Member Posts: 639
    Hi,

    but you only post the VAT part of the transfer, or how is it done? I mean, NAV already posts the value transfer in the G/L, however without VAT... but this should be doable:

    - add the VAT posting groups, Country code, VAT ID to the "Transfer Route" table (or to the Location table)
    - add it to the "Post Value Entry to G/L" table
    - add the fields in the posting logic where needed

    Or am I missing something big?

    with best regards

    Jens
  • Miklos_HollenderMiklos_Hollender Member Posts: 1,598
    @Fdickshat thanks this looks like a good simple direction - I actually made a report like that in the past but it was only used for controlling.

    But the point is, these transfers should also show up in the VAT and the ZDM. So then these G/L Postings should also make VAT Entries. With VAT Reg. No. and all for the ZDM (VIES in English). Basically at least one per VAT Reg. No. The VAT Statement (Abrechnung) is fairly easy because it is possible, although rarely done, to add not only VAT Entries but also G/L Entries to this report. But the ZDM is harder as ZDM strictly works from VAT Entries only. I know it is possible to make VAT Entries through a G/L Journal - you have to set "Copy VAT Setup to Jnl Lines" in the batch and it works. But do the entries have VAT Reg. No. ?

    I mean, the way I see it would be to set up dummy customers / vendors and use those accounts in the General Journal, because only then will they have a VAT Reg. No. This is what you meant?
  • Miklos_HollenderMiklos_Hollender Member Posts: 1,598
    @jglathe NAV just books the inventory value part in the G/L not all the other things in Transfer Orders.

    I mean a Transfer Order is practically a nicer GUI for an Item Journal. Inventory value, not much else. An invoice is practically a nicer GUI for an Item Journal and a Sales Journal i.e. doing a General Journal posting with a customer account on one side and some Sales Revenue G/L Account on another side as a balancing accounting. Amount would be the with VAT amount, and NAV would automatically deduct it and post the net amount to the Sales Revenue Account. (You know, the exact reverse of how people normally book stuff like heating costs in a Purchase Journal. They don't use a full Purchase Invoice. Just a vendor account and a cost account as a balancing account, and with VAT amounts in the Amount and VAT is deducted automatically.)

    So I figure it could work... the tax office is always very keen on matching VAT, ZDM and Intrastat. I figure if my Intrastat value (for the transfers) = sum of Cost Amount (Actual), then booking it in one line in the G/L and VAT Entries could work indeed, as they would match... perhaps.

    But this I figure only works if I have two G/L Journal postings: one with a dummy customer and one with a dummy vendor.

    For example if I transfered goods from Austria to Germany, then the sales to the Warehouse DE dummy customer sorts out my Intrastat and VAT and ZDM in Austria, and the purchase from the Warehouse AT dummy vendor sorts out the same thing in Germany.

    I think it must be always double?
  • Miklos_HollenderMiklos_Hollender Member Posts: 1,598
    FDickschat wrote:
    What about Sales:
    Is there at your customer a 1:1 relation between a customer (or better a ship-to address) and a warehouse? If you ship from different countries to the same ship-to address you would need to amend the VAT Bus.PostGrp in sales documents. We also did a small modification for this.

    Just discussing this with the auditors today. They are very adamant we must always use the VAT Registration No. of the country we ship from even if we also have one in the target country. So when shipping to a customer in Germany we may only use our German VAT Registration No. if we ship from a warehouse in Germany. If we ship from elsewhere we must use that of the source country. That means that in that case the customer must do the VAT job and they dislike it. So it sounds like we must try to always ship from local warehouses to make customers happy.

    If we always ship from local warehouses it is not too hard - I have created a VAT Bus. Pos. Group translation matrix for that. So if I have a customer in Belgium, and we are located in Austria, the customer is set up with VAT Bus. Pos. Group "AT BE". But if the Location is our Belgian Location then it gets changed to "BE INLAND". This is set up in a matrix: Location BE changes AT BE to BE INLAND. And of course we set up VAT Statements, filter ZDM etc. accordingly. Practically set up one VAT Statement per country.

    Did you mean something like that?

    We also had to change Intrastat but it was not too hard - we must always save the Country Code of the Location in the Item Ledger and filter Intrastat accordingly. And had to merge in the local functionality for creating Intrastat "diskettes" and ZDM reports inmany countries... :(

    But still it was the easier part, making them all match - Intrastat, ZDM, VAT, G/L is the hard part.
  • jglathejglathe Member Posts: 639
    Hi Miklos,
    @jglathe NAV just books the inventory value part in the G/L not all the other things in Transfer Orders.
    just to make sure I've test-posted a transfer order between two locations with G/L integration on. And it is as I said: The transfer is posting the flow of goods at actual cost also in the G/L. For a transfer order the overall value change should be zero, but the accounts the value is posted on might be different.
    As this is the case, you can "easily" extend the posting by location with the VAT data you would need to post the G/L side with VAT codes and amounts. The Gen. Journal Line will calculate the VAT amount also for a net amount given, the only unusual thing is that you would execute table triggers in the posting routine then (I recommend against it). But you could easily duplicate the functionality.
    This would satisfy the requirements that your auditors have. I would suspect that some logistcs AddOns have this functionality already.

    with best regards

    Jens
  • FDickschatFDickschat Member Posts: 380
    Did you mean something like that?
    Yes
    That means that in that case the customer must do the VAT job and they dislike it. So it sounds like we must try to always ship from local warehouses to make customers happy.
    To solve this problem my customer first "transfers" the goods from his own warehouse VAT no. to his own VAT no. in customers country. Then he writes an invoice from the second VAT no. including local VAT to his customer. This is an accepted procedure by the auditors as well as the tax authorities.
    Example: Warehouse is in DE, customer is in UK.
    1. Transfer Document from DE VAT ID to GB VAT ID, Actual cost amount, reverse charge VAT, Intrastat reporting as outbound in DE and Inbound in GB
    2. Local Invoice from GB VAT ID to UK customer incl. UK VAT. Customer does not need a VAT ID and does not need to report Intrastat.

    It is an accepted procedure to create the transfer document only once per month per combination of VAT IDs involved (basically a report listing Item ledger entries).
    Frank Dickschat
    FD Consulting
Sign In or Register to comment.