Financial Management Blogs by SAP
Get financial management insights from blog posts by SAP experts. Find and share tips on how to increase efficiency, reduce risk, and optimize working capital.
cancel
Showing results for 
Search instead for 
Did you mean: 
AlinaVranceanu
Product and Topic Expert
Product and Topic Expert
5,750
In this blog post, I want to highlight one of the pain-points I have encountered in two of my projects, related to Brazilian tax regulation. Both customers are operating globally and Brazil it is one of their supported countries.

Since Brazilian finance and tax regulations are particularly complex, this blog post is aimed at helping you understand the Nota Fiscal for intercompany stock in transit movements between different Legal entities within Brazil. This blog post does not cover VAT functionality; it is only related to issuing Nota Fiscal for intercompany stock in transit between Company Codes within Brazil.

Stock-In-Transit and Cross-Company Code Actual Costing allow transparency of costs within a global supply chain, as well profitability analysis including intercompany profit.  To achieve this, the solution demands the implementation of stock in transit and Actual Costing in all countries within a group, including Brazil.

  • Currently, Brazil Country localization only supports, as standard SAP solution, the intracompany stock transfer.

  • For the intercompany stock in transit - exports we have a workaround see note 2453291 (Cross Company aka Intercompany Transfers for Brazil).

  • For the intercompany stock in transit within Brazil, I am proposing the following development, which was done and tested together with one of our customers. Please note the development it is not an SAP standard solution.


As mentioned, SAP note 2453291 (Cross Company aka Intercompany Transfers for Brazil) describes a workaround for regular intercompany, where you can configure a sale to a company code in another country(export), but for sales between different Legal entities within Brazil, there is no standard solution or workaround. The following describes an approach that you may find useful. I have used the approach on the projects I have been involved and the solution was accepted.

The only logistics movement types that are made legally compliant for Brazil, see note 123124 LSA BR:5th v. Customizing of Brazilian movement types by SAP´s Brazilian localisation are breaking the supply chain visibility, which will make impossible the intercompany profit calculation, see the blog Stock Transfer Brazil.

The major difference between the 2 scenarios:

  • for Intercompany with stock in transit outside Brazil, only one Nota Fiscal is needed, during intercompany billing

  • for Intercompany with stock in transit within Brazil, one Nota Fiscal is needed when the intercompany billing is created, and a second Nota Fiscal is needed for the GR (MIGO). Two Nota Fiscal are needed because the sending and the receiving company codes are, both, located in Brazil.


In this example, for Intercompany Stock in Transit between different Legal entities, I have used the following scenario:

Receiver’s transit stock: The value and quantity of the material shall be listed in the receiving plant while in transit. Thus, the goods issue of the material from the sending plant posts directly into the in-transit stock of the receiving plant. As soon as the truck arrives at the receiving plant the material value and quantity can be transferred to the receiver’s free stock.

The following movement types were used:

683 for Goods Issue (with outbound delivery reference) which automatically triggers Goods Receipt (107) posting in the receiving company code (blocked stock).

109 movement type does not correspond to a physical inventory movement. It only changes the stock status, from blocked into stock ready to be used. In our development, 109 will be replaced with a Z* movement type created having as reference 109. Following the 2 scenarios we will have:

  • Intercompany transfer with stock in transit outside Brazil, for which movement type 109 will be used

  • Intercompany transfer with stock in transit within Brazil, for which movement type ZZ9 will be used


The scenario goes as follows:

  1. ME21N Create Stock Transport Order.  A Stock Transport Order is created when the goods physically leave the Sending Plant to record the outgoing movement of stock.

  2. VL10B Delivery Creation

  3. VL02N Outgoing movement + Incoming (GR into blocked stock) 683+107

  4. MIGO           Release blocked stock 109 (intercompany stock in transit outside Brazil) and ZZ9 (intercompany stock in transit within Brazil) when the goods have arrived physically at the plant.


For the Intercompany transfer with stock in transit within Brazil, I will not go into the details of Nota Fiscal for the intercompany billing – MIRO, as it is covered by the workaround mentioned above (same as for Intercompany transfer with stock in transit outside Brazil) see note Note 2453291 Cross Company (aka Intercompany) Transfers for Brazil. I will go into the details of Nota Fiscal for the good receipt - MIGO, which is not covered by the standard and requires enhancement.

Prerequisites:



  1. New movement type (BWART) needs to be defined, using transaction OMJJ. I have created ZZ9 for debit and ZZ0 for credit, copying from movement type 109.

  2. New PO type – ZNBB, having as reference standard NB PO type

  3. New Tax code – Z0 (without account to post) - this tax code is only used to generate Nota Fiscal for MIGO, make sure you`re regular VAT tax code it is also defined (MIRO).

  4. The customizing for Nota Fiscal needs to be in place as well, in the view J_1BIM02V the new movement types ZZ9 and ZZ0 must have the Nota Fiscal relevance field set as ‘X’- Nota Fiscal relevant.


All these are needed to be able to differentiate the 2 scenarios, stock in transit outside Brazil and stock in transit within Brazil.

For stock in transit within Brazil, the following flow will result:

The moment you post the good receipt with MIGO transaction is necessary to register the Inbound eNota Fiscal and calculate taxes without account post. This condition keeps the same price applied for effective PO and Tax Code.

The prerequisite to take this value is price condition (depending on the price condition you are using) and the new movement type ZZ9.

In MIGO transaction, use event `Goods Receipt` and Movement `ZZ9`. The enhancement should be triggered when all data is completed in MIGO and the user access the Nota Fiscal.


To support this system gap, you must create a logic to read the information using PO data and move the tax information to eNota Fiscal. The eNota Fiscal must use the information based in PO and Tax Code, including tax law.


To support the new scenario, it is mandatory to ignore the message bellow.

Also, one new ABAP Class needs to be developed. In our example, we have defined class ZCL_MM_BR_SITAXES to support the taxes information from PO.

DEFINE TAX LAW


The system must define tax law using the same Enhancement used to define tax value.

Method GET_TAXES_TABLE (ZCL_MM_BR_SITAXES)

After system define the tax value in the internal table GT_KOMV_TX

You need to read the tax law to ICMS and IPI directly using the condition type.

ICMS IP Tax law


The development must loop the table reading the field KSCHL with the value below:

BLIC                       ICMS Tax Law

BLIP                       IPI Tax Law

The table F_TAX_LAWS in the program SAPLJ1BF will receive the value if the value in the field KNUMA_BO is not initial

f_tax_laws-icmslaw = BLIC-KNUMA_BO.

f_tax_laws-ipilaw = BLIP-KNUMA_BO.

To support the scenario to PIS and COFINS we need to confirm the dynamic exception to read the correct data.

To this rule, the tax rate will be the base to map the access sequence.

COFINS TAX LAW


Select in the internal table GT_KOMV_TX the value KOLNR if KSCHL is equal at BCO1

If the RESULT_1 is ok

Read GT_KOMV_TX value in the field

KSCHL is equal at value BLCO and KOLNR is equal at RESULT_1-KOLNR

The table F_TAX_LAWS in the program SAPLJ1BF will receive the value if the value in the field KNUMA_BO is not initial

f_tax_laws-coflaw = BLIP-KNUMA_BO.

PIS TAX LAW


Select in the internal table GT_KOMV_TX the value KOLNR if KSCHL is equal at BPI1

If the RESULT_2 is ok

Read GT_KOMV_TX the value in the field

KSCHL is equal at value BLPI and KOLNR = RESULT_2-KOLNR

The table F_TAX_LAWS in the program SAPLJ1BF will receive the value if the value in the field KNUMA_BO is not initial

f_tax_laws-pislaw = BLIP-KNUMA_BO.

Correction 1


The filed KPOSN during the GET_TAXES_TABLE is the PO item, but after an update, the Internal table ET_TXLAWS the field KPOSN must be updated using the current value in the (SAPLJ1BF) LV_KOPSN

This is necessary to link the tax law in the eNota Fiscal item.

Current scenario: (the table after reading the PO data)Correction2

In the code below, we need to fix the value return:

Current <ls_tax_laws-XXXX> = <ls_tax_laws-XXXX>

Correct <ls_tax_laws-XXXX> = <ls_txlaws-XXXX>Result after correction

After the new customizing and development, it is in place, in case of scenario Intercompany with stock in transit within Brazil, two Nota Fiscal`s will be issued:

  • One during intercompany billing – MIRO for the sending company code

  • One during GR – MIGO for the receiving company code.



Invoice - MIRO



Good receipt - MIGONotes:



  • The same solution will work also in ECC if stock in transit and Actual Costing scenario are in place.

  • In case you have developments for Brazil VAT or Nota Fiscal, you also need to take those into consideration, as the new Class is created to support the tax information.

  • New Enhancement the skip the External Base validation might also be needed.


Alina Cristina Vranceanu
Product Expert
SAP S/4HANA Regional Implementation Group