sábado, 21 de janeiro de 2017

The J1ACAE – J1AANIV process

This process is very similar to other countries electronic invoice. The difference is that the majority of the process here is manual. Some companies opt t maintain this process, even knowing about the existence of the web service process for Argentina localization.
It is used to send all information related to each commercial transaction document in the company to the government organization. For Argentina the responsible government organization is named AFIP.

Workflow

workflow

As you can see in the above picture, the workflow of this process is quite simple and very similar to other electronic invoice process in Latin America.

Differences while saving the invoice

The normal process is followed until the invoice where you will see that no accounting document is generated.

The J1ACAE transaction

After that the user will open J1ACAE transaction and create from there a text file with a package of invoices.
In addition to this creation, the transaction will update J_1ACAE table with one record for each invoice involved, with the status “I – Sent to AFIP”.
You will notice that due to this record the SAP system will not more allow you to edit the Invoice anymore, only if the CAE status is Approved or Rejected.

Sending to AFIP

Then the requester will manually send this text file to AFIP, to its website

The J1AANIV transaction

After sending the file, AFIP system will cross data of each company and define if the document is correct or if it is rejected he will receive another text file, this new file will be uploaded in SAP through J1AANIV.

It will update J_1ACAE transaction with the CAE number, the new CAE status and some more information.
In addition to that it will update the reference field of the Invoice with a specific number created by joining information from J_1ACAE.
Now with the rejection or approval inserted, the invoice will now be available for correction.

Fonte: https://learningsapsd.wordpress.com/category/process/localization/argentina/

Consignment in Brazil

Purpose

The idea of this document is to explain how the consignment process is performed from a Sales and Distribution point of view. This document can be used as a reference overview to better understand the flow of documents involved in this scenario.

Overview

The process that stars with sales order type KBB is used for sending the consigned goods to consignment. And the process that starts with sales order type KEB is used for the goods billing. In order to retrieve the consignment items that were not sold, the sales order type YBKA should be used. In order to withdraw the sold items to the consigned stocks the sales order type YKRB should be used.

Customizing in Brazil

The standard sales order types to be used on a consignment process are KBB (initial sale) and KEB (withdrawal). On table J_1BSDICA (sales document item category), the standard customizing for this process is:
 - to KBB | KBNB => Nota Fiscal rec. type "52", both ICMS and IPI are normal;
 - to KEB | KENB => Nota Fiscal rec. type "51", both ICMS and IPI are flagged as statistical.
 

The Consignment Document Flow

This is the complete Consignment Document Flow presentation based on document Types:
 
  1.   Order KBB, item cat.KBNB > Delivery LF > Billing FCR > 'Nota Fiscal Simples Remessa N1' - consignment fill up


  2.   Order KEB, item cat.KENB (refers to billing FCR) > Remessa LF > Billing FC > 'Nota Fiscal Fatura N1' - consignment issue


Related Content


Fonte: https://wiki.scn.sap.com/wiki/display/LOCLA/Consignment+in+Brazil

segunda-feira, 16 de janeiro de 2017

Cálculo do DIFAL para operações interestaduais de uso/consumo e ativos imobilizados

Olá pessoal,

Como muitos já devem saber, alguns Estados no Brasil (GO, BA, MG, RS and SE) adotaram uma nova fórmula de cálculo da Base de cálculo e fórmulas para o cálculo do DIFAL e ICMS ST relacionado a operações interestaduais de uso/consumo e ativos imobilizados. As demais regiões não alteraram este cálculo, portanto permanecem inalteradas.

No momento a SAP não disponibilizou nenhuma solução standard por não se tratar de um requerimento atendido por todas as regiões do Brasil. Dito isto, foi liberado uma BAdI na qual o cliente deve implementar sua própria solução para atender os cenários na qual efetua negócios.

Para o DIFAL temos as notas abaixo:

2394557 – DIFAL: BAdI for Recalculation of Base Value in Incoming Process for Consumption Goods or Assets
2408576 – DIFAL: BAdI for Recalculation – TAXBRA Calculation Procedure
2408577 – DIFAL: BAdI for Recalculation – TAXBRJ Calculation Procedure
2410487 – DIFAL: BAdI for Recalculation – Fixes for TAXBRJ Calculation Procedure
2414116 – DIFAL: ICMS DIFAL Tax Rate Is Being Calculated Wrongly

Foram criados os seguintes objetos:

New enhancement spot –> ES_J1B_DIFAL_RECALCULATION
New BAdI –> BADI_J1B_DIFAL_RECALCULATION
New class –> CL_J_1B_DIFAL_RECALCULATION
New interface –> IF_EX_BADI_J1B_DIFAL_RECALC

A nota 2394557 entrega somente a estrutura da BAdI BADI_J1B_DIFAL_RECALCULATION que pode ser usada tanto para TAXBRA como TAXBRJ.

O método na qual os clientes devem fazer seus desenvolvimentos em projeto é o ‘RECALCULATE‘ que tem como parâmetros IS_DIFAL_RECALCULATION como entrada e CV_DIFAL_VALUE, CV_DESTINATION_BASE_VALUE e CV_DIFAL_RATE que podem ser alterados.

A nota 2408576 ajusta a classe CL_TAX_CALC_BR_MM método CALCULATE_ICMS_COMP para chamar, caso implementado, a BAdI da nota 2394557.
A nota 2408577 ajusta o código do módulo de função J_1BCALCULATE_TAXES para chamar, caso implementado, a BAdI da nota 2394557.

Para o ICMS ST temos as notas abaixo:

2407798 – Brazil: BAdI for Recalculation of ICMS ST Base and Amount in a Consumption Goods or Assets Process – High release
2410679 – Brazil: BAdI for Recalculation of ICMS ST Base and Amount in a Consumption Goods or Assets Process – Low release

2406621 – Extension Class for ICMS ST Customer Implementation – High release
2410687 – Extension Class for ICMS ST Customer Implementation – Low release

2407813 – Call ICMS ST BAdI in TAXBRJ Process – High release
2410981 – Call ICMS ST BAdI in TAXBRJ Process – Low release

2407805 – Call ICMS ST BAdI in TAXBRA Process – High release
2410968 – Call ICMS ST BAdI in TAXBRA Process – Low release

Foram criados os seguintes objetos:

New enhancement spot –> ES_J1B_EXTEND_TAXES
New BAdI –> BADI_J1B_EXTEND_TAXES
New interface –> IF_EX_BADI_J1B_EXTEND_TAXES
New interface method –> IF_EX_BADI_J1B_EXTEND_TAXES~ICMS_ST_RECALCULATE

Atualmente o código standard não permite nenhum recálculo no ICMS ST. A partir da implementação destas notas você poderá efetuar o recálculo na BAdI BADI_J1B_EXTEND_TAXES.

A nota 2407798 entrega somente a estrutura da BAdI BADI_J1B_EXTEND_TAXES que pode ser usada tanto para TAXBRA como TAXBRJ.

O método a ser utilizado para para os clientes criarem suas próprias regras de negócio é oICMS_ST_RECALCULATE que possue como parâmetros IS_ICMS_ST_RECALCULATION como entrada e CV_ICMS_ST_BASE e CV_ICMS_ST_AMOUNT que podem ser alterados.

Thank you

Leonardo Brunetto

Fonte: https://blogs.sap.com/2017/01/13/calculo-do-difal-para-operacoes-interestaduais-de-usoconsumo-e-ativos-imobilizados/

Devoluções de NF-e com Partilha de ICMS ( EC87/15 ) – v1.92 da NT2015/003

Oie Pessoal,

Tenho visto várias perguntas a respeito da rejeição 699 para cenários de devolução de venda a consumidor final não-contribuinte do ICMS ( cenários de ICMS partilha ).

Motivo do erro

A rejeição está ocorrendo porque em 04/01 a SEFAZ publicou a versão 1.92 da NT 2015/003alterando a regra de validação NA11-10 (rejeição  699) para que fosse considerado o ano da NF referenciada nas operações de devolução ou com CFOP de retorno de mercadorias. Anteriormente era considerada a data de emissão da NF-e para o cálculo da partilha.

A lógica standard desenvolvida pela SAP atendia a regra anterior ( data de emissão ) sendo que a leitura desta informação ocorria na classe CL_J_1BTPARTILHA_DA  no método READ_LAST_VALID_RATE.



Conforme código na imagem acima a leitura sempre é feita utilizando o SY-DATUM ( data atual do sistema).

Prazo definido pelo governo para implantação:
  • Ambiente de Homologação:16-jan-2017;
  • Ambiente de Produção: 30-jan-2017.

Olhando estas datas vocês podem se perguntar, mas porque estou tendo rejeição se a data de produção é somente dia 30 de janeiro?  Neste caso é necessário destacar que a SEFAZ-SPadiantou-se (até o momento só recebi reclamações desta SEFAZ ) e já implementou a mudança em produção na primeira semana do ano, causando a rejeição 699 para as devoluções.

Previsão de Entrega SAP: 

A SAP já está trabalhando numa solução para este cenário com expectativa de liberação de SAP Notes em 27/01 para se adequar a alteração. Assim que tivermos a solução final irei atualizar o post com as respectivas SAP Notes a ser implementadas.

Informação técnica do processo:

Hoje o método READ_LAST_VALID_RATE é chamado em diversos pontos do processo de venda/faturamento
  • Classe CL_TAX_CALC_BR, método CALCULATE_ICMS_PARTILHA ( cálculo da pricing TAXBRA, tanto na primeira como na segunda rodada )
  • Função J_1BCALCULATE_TAXES (através da classe cl_j_1b_icms_partilha no cálculo da pricing TAXBRJ )
  • Programa LJ1BGF01, form NF_CREATE_OBJECTS ( include que incia a criação da NF-e )
  • Módulo de Função J_1BNF_FILL_ADDITIONAL_FIELDS ( para releases 605+ )
  • Módulo de Função J_1B_NF_DOC_UPDATE_FROM_OBJECT ( para todos releases )
  • Módulo de Função J_1B_NF_DOC_INSERT_FROM_OBJECT ( para todos releases )

att,
Renan Correa

Fonte: https://blogs.sap.com/2017/01/12/devolucoes-de-nf-e-com-partilha-de-icms-ec8715/

Time zones in the NF-e solution



There are two scenarios related to the time zone and NF-e solution.
Scenario 1 - In a process that the NF-e is created via MM or SD side, the time zone comes from the settings of the Plant.
Scenario 2 - If the process of the creation of NF-e document is performed manually, via NF-e Writer for example, you will have to check the time zone settings of the user logged in the ERP that is creating manually it, because the time zone will come from the user's settings.
Based in both scenarios above, you will need to check in which scenario this problem is happening in your enviroment. It is important to identify it, because the customizing to be checked is different.
Also, remember to check the time zone settings of the user that you are using to connect ERP and GRC systems. If you do not know which is the user, you can check it in the transaction SE16N, opening the table J_1BNFE_CUST3. There will see the name of the connection to GRC in the column RFC Destination. After this, go to transaction SM59, click in ABAP Connections and you will see the user. Then, check the time zone settings of this user.
Review the customizing of time zones and DST Rules in your ERP and GRC (if you use this message system) in the path SPRO > SAP Customizing Implementation Guide > SAP NetWeaver > General Settings > Time Zones > Maintain Time Zones.
About the field DHEMI, the NF-e 3.10 requires to inform the time in which the nota fiscal was created using the UTC format (previously used as GMT). Check if the SAP Notes 2050660 and 2048658 are applied in your system. With the SAP Note 2050660, the field DHEMI will be always converted to standard time +0000 UTC. For example, in case you are creating a nota fiscal for a branch in Sao Paulo today, 28/DEC/2014 14:30 -03:00 UTC (Brazilian time), the field DHEMI will be 20141228173000. Notice that you will have one of the scenarios below.
Scenario A - You use GRC as your messaging system: GRC will check which region issued the nota fiscal and then adjust the field DHEMI according to its time zone. In the case of the example above, as Sao Paulo is the issuer and the time zone there is -03:00 UTC, GRC will change the field DHEMI and send to SEFAZ as 2014-12-28T14:30:00-03:00. Keep in mind that the field DHEMI in the table /XNFE/OUTNFEHD will be stored in UTC +0000, so in this case it will be stored as 20140815173000. Also, check if the SAP Note 2052421 is applied in your system in order to avoid validation issues on the last day of the month.
Scenario B - You do not use GRC as your messaging system: You will have to check if the provider of your messaging adjust the date and time before sending to SEFAZ, otherwise you can receive a rejection to send a nota fiscal in the future, for example. Check it with the responsible of your messaging system.

Fonte: https://wiki.scn.sap.com/wiki/display/LOCLA/Time+zones+in+the+NF-e+solution

NF-e Gaps Report

Purpose

The purpose of this page is present the NF-e Gap report J_1BNFECHECKNUMBERRANGES. How to run, use and configurations.

Overview

Working with Nota Fiscal Eletrônica (Brazilian Electronic Invoice), sometimes gaps in the official number range may happen due several reasons, like update termination, network problems, etc. In order to help customers to report those gaps to SEFAZ (Brazil's tax authority), SAP has released this report that should be run once in a month, that will read all the customization regarding the number range objects, and perform a sequential read in all notas fiscais tables in order to identify gaps. If any gap exists, the report will also send automatically to GRC, triggering the skip process and get the SEFAZ acknowledge.

The NF-e Gap Report

Basically the report requires only a couple of the parameters to run:
 

This report allows you to make execution as much as you can without actually trigger the skipping to GRC. You just have to use the 'Test Run' flag. When you validates the information, you can run 'for real'. You can also decide if you want to use Asynchronous or Synchronous execution. The difference is, report will run until all the notas fiscais numbers found as gaps be sent to GRC. If you decide to use 'Asynchronous' method, report will run in few seconds and the control will pass to the SAP engine control the execution.

The Main Customizing View

It is very important to make the correct customization before run the report for the first time in the view J_1BNFENUMCHECKV. The customization should be done via Company Code. Check how the customization looks like:
 
 

Here you insert the business place, the object of the number range related in the process, the number and finally in the field 'To Number', you insert the last number verified.
    •    Why this last field is so important?
This field is important if you already reported any time a gap to SEFAZ in old numbers. Lets took our example:

Bus. Place
Subobj.val
No
To number
0001BR9901016963

The number 6963 was the last number checked by the report. This means, in the next execution of the report, it will not read from the number zero to check gaps, but will start from number 6963. So, this means if it is the first time you are executing the report and you never report a gap to SEFAZ before for this combination, is natural to have the number '0' in this field. However, let's say in your internal control, it is the first time you are executing the report, but you already report to SEFAZ gaps until number 17038. Hence, you should insert the value 17038 in the field 'To Number'. With that, the report will start from this number to.

After execution

After the execution, you will see this:
 


Those are the notas fiscais number that the system identify as gaps, and it will report to SEFAZ. At this point, the skipping process was trigger at GRC/PI and in a few seconds we will get the SEFAZ approve for it.

Following up

You can follow up the results inside table J_1BNFENUMGAP. This table keeps the register of the access key create for this gap, the version, all the information about form, brunch, company code and the most important one, if the skip request was authorized by SEFAZ. See field 'Status'.
 

You can also access the information of this table inside J1BNFE, menu Goto > Gap Monitor.
 

Related Content

Related Documents

Related SAP Notes/KBAs

 Here is the list of main SAP notes and KBAs related with the report:
 Fonte: https://wiki.scn.sap.com/wiki/display/LOCLA/NF-e+Gaps+Report

Different Taxes - AR

urpose

The purpose of this page is to clarify the different taxes in Argentina during the customizing of Pricing Procedure.

Overview

The following section will explain the taxes in Argentina, which is the first part of the process of configuration, that is preceded by Basic Customizing of Pricing Procedure - AR and followed byFormulas - AR.

Different Taxes in Argentina

- VAT
This is a federal tax. The current rates are 10%, 21% or 27%, depending on the customer and/or product classification.

- VAT Perception
This is a federal tax. The current rates are 3%, 10,5% or 13,5% depending on the customer and/or product classification. The VAT perception should apply only if the result is equal or higher than ARS 21,30.
- Gross Income (GI) Perceptions
These are provincial/state taxes. There are 24 provinces (regions) in Argentina. Each province has its own rates and regulations. Like VAT Perception, some GI perceptions can also have a minimum threshold.
- Others
There are also other taxes, such as Internal Taxes and VAT Surcharge. These are percentage taxes that can be applicable and also subject to exemptions. They are how ever only applicable for some scenarios. All these taxes depend on base price. Each tax has two condition types, one is statistical and other is the posted for adjustments. Thus, all are grouped conditions. Formula associated to pricing procedure:
333 – VAT and VAT perceptions (rounding, exemption, minimum amount)
334 – GI perceptions on SD
335 – GI perceptions on FI

Tax categories

The customer specific exemptions are maintained on the Tab 'Control Data' via the 'Tax Categories' button available for Argentinean customers.
The entries are stored in the table KNAT, which is accessed in pricing from the requirement routines 81, 82 and 83 to check for exemptions when reading tax conditions. In the details of pricing procedure section, we explain how the link between the tax condition types and tax categories. Customization for tax categories, go to SPRO > Financial Accounting > Financial Accounting Global Settings > Tax On Sals / Purchases > Basic Settings > Argentina > Tax Categories > Maintain Tax Categories.
These tax categories are based on following parameters:
- Account type: customer/vendor/material etc.
- Display Info: When a document is posted with this indicator set, the current information for the tax category concerned from the business partner's master record is compared to the information from the company code. The current status is displayed in the value help for the tax indicator. In addition, the range of tax indicators displayed is limited accordingly. Therefore we recommend that you set this indicator.
If the indicator is not set, it is still possible to maintain tax category in formation in the master record. However, this data is not used to display the possible values for the tax indicator when you post a document.
- Exempt. Possible: Considers that this category can be used to maintain exemptions for a particular condition. If the flag is not set, you will not be permitted to maintain exemption rates and date range on customer master.
- Is VAT like: This flag identifies VAT like tax conditions, for example VAT Perceptions. The VAT exemptions (see Reason for 0 VAT) apply only on VAT like taxes. Other conditions, like Gross Income Perceptions should not have this flag.
- Condition types: Here you maintain the condition types that you have created using transaction V/06 and you will be using in the pricing procedure (example RVAAAR).
Cond. Type F. Acc.: this field does not need to be maintained.
Condition Type: contains the base condition.
Ref. Cond. Type: contains the adjustment condition.
Concept of condition type and reference condition WRT Localization Argentina:
For AR pricing procedure, all taxes and amounts are calculated based on grouped conditions. Which means that one condition calculates the base amount and the other makes an adjustment to the derived amount. Let us consider the above screenshot where condition type is J1A1 and Ref Condition is J1X1. Here there condition types collectively determine the tax amount for GI perception. J1A1 will calculate based on condition tables and is type statistical. J1X1 is calculated on the amount determined via J1A1 (taken as base amount) and then formula is applied on it. Once the amounts are finalized, they are posted to G/L.

New fields

At invoice level, there are few fields which are needed to calculate Tax, as listed below:
Fiscal Type/Tax type
Reason 0 VAT
Region
Activity Code for Gross Income Tax
Distribution Type for Employment Tax
Tax Relevant Classification for VAT Perception

Fiscal Type

The Fiscal Type (Tipo Fiscal) is a basic characterization of a legal entity in tax aspects. It influences tax rates (VAT, VAT perception) as well as the Printing Character in invoices. Therefore, the parameter must be part of customer master, must be stored on sales document level, must be available in pricing/tax calculation, and an assignment of the 'printing character' to the fiscal type must be provided for billing functionalities. Customization of this is maintained at below path SPRO > Financial Accounting > Accounts Receivable and Accounts Payable > Customer Accounts > Master Data > Preparations For Creating Customer Master Data > Accounts Receivable Master Data For Argentina > Define Fiscal Type / Assign Fiscal Type.

Reason 0 VAT 

This is a kind of exemption handling. Legal requirement is that if a special exemption exists, a VAT amount of ARS 0,00 is valid. However, in this case, the exemption reason has to be provided in the documents (and their printouts), as well as in legal reporting on these documents. Field 'Reason for Zero VAT' available at item level in sales and billing documents. There, it is a one-digit field, the long-text of which is maintained in customizing, and retrieved for invoice printout. At the same time, it is available in pricing. Pricing has to be set up in a way that a non-initial value of this field would bring the VAT amount down to zero. Customization to maintain reason values is SPRO > Financial Accounting > Financial Accounting Global Settings > Tax On Sales / Purchases > Calculation > Change Foreign Currency Translation > Tax Codes For Tax-Exempt Sales > Define Reasons. At 'Define Reasons', you need to maintain only one digit code.
At 'Assign Reasons to Tax codes', you need to assign a tax exemption reason to a particular tax code for tax exempt purpose. Go to SPRO > Financial Accounting > Financial Accounting Global Settings > Tax On Sales / Purchases > Calculation > Change Foreign Currency Translation > Tax Codes For Tax-Exempt Sales > Assign Reasons to Tax Codes.

Activity code for gross income perception taxes

The legal requirement is that gross-income taxes are based not only on the region (province) involved in a transaction, but also on the “activity type”. The definition of the possible activity types is not necessarily uniform throughout the country. This is a 2-char field at sales and billing item level, and makes it available in pricing for tax calculation purposes. Filling of this field is done by a user-exit, resembling the customer's situation. Legal reporting for provinces is not delivered as a standard from SAP; however, custom solutions can easily retrieve the correct values from the billing documents. These are maintained as independent values in customization.

Distribution type for gross income perception taxes

There can be several ways how the gross-income perception taxes are distributed. However, in almost all cases, “multilateral agreement” type applies, which will cause no direct influence on any values, but needs to be present for legal reporting. This does not have influence on the pricing. The values of distribution types are dependent on company codes. For activity code and distribution type, customization is maintained at SPRO > Financial Accounting > Accounts Receivable And Accounts Payable > Customer Accounts > Master Data > Preparations For Creating Customer Master Data > Accounts Receivable Master Data In Argentina > Define Activity Codes For Gross Income Tax / Define Distribution Type For Gross Income Tax.

Tax relevant classification for VAT perception

In most countries, withholding taxes apply to salaries and services. This is also the case in Argentina, but the specialty here is that withholding taxes are not restricted to these areas. They can also apply to a wide range of materials in relatively complex way. In order to allow a most flexible assignment modelling of withholding taxes for Argentina in SD, the field tax relevant classification had been introduced to the sales and billing item, as well as to pricing. Its definition is completely free, and customers in Argentina have made wide use of this flexibility when setting up their specific taxation cases. Customization to maintain tax classification is SPRO > Financial Accounting > Financial Accounting Global Accounting > Tax On Sales / Purchases > Basic Settings > Argentina > Maintain Tax Classification.
During the sales order processing, taxes need to be calculated. Argentina has special requirements in this area, because there can be several tax types applicable in one document. In addition, customers may also subject to exemptions (fully or partially), for a certain period of time, for one or several types of taxes. Location of these fields on sales order item level are present on the 'Country' tab. Location of these fields on billing item level are in 'Item Detail' tab, in the field Reason 0 VAT and below in Argentinean Reporting area.

In order to continue the customizing of Argentina's Princing Procedure, follow the topic Formulas - AR. 

 Related Content

Related Documents

Related Notes/KBA


Fonte: https://wiki.scn.sap.com/wiki/display/LOCLA/Different+Taxes+-+AR

IVA withholding in Argentina

Purpose

The aim of this page is to clarify the understanding of IVA (Impuesto al Valor Agregado) withholding tax in Argentina.

Overview

The company is the withholding agent determined by AFIP, the tax authority in Argentina. When you make the payment to the vendor, you have to calculate withhold IVA tax to vendor and inform that you are paying less due to IVA tax to be practiced. During this process, the system indicates the Certificate of WHT (withholding tax), where it informs: basis of calculation, tax rate and amount withheld. Check below the instructions of the customizing.

Instructions of the customizing

01. Enable the Extended WHT, applicable for Argentina.
Go to transaction SPRO > SAP Reference IMG > FA (Financial Accounting) New > FA Basic Settings New > WHT > Extended WHT > Company Code >> Activate Extended WHT.
02. Create a WHT Type.
You define the WHT Type for posting at the time of paying. You have to enter the WHT information when entering the document for this WHT Type.
Go to transaction SPRO > SAP Reference IMG > FA New > FA Basic Settings New > WHT > Extended WHT > Calculation > WHT Type >> Define WHT Type for Payment Posting.
03. Create a WHT code and Formula Calculation.
Go to transaction SPRO > SAP Reference IMG > FA New > FA Basic Setting New > WHT > Extended WHT > Calculation > WHT code
>> Define WHT Code
>> Define Formulas for Calculating WHT
In the example of the image below, the WHT Code corresponds to 80% of IVA.
04. Assign WHT Type and Code to every vendor masterdata.
05. Assign accounts for WHT.
Go to transaction SPRO > SAP Reference IMG > FA > FA Global Settings > WHT > Extended WHT > Postings >> Accounts for WHT
06. Create and/or check if the branch can generates the certificates numbering of WHT.
Go to transaction SPRO > SAP Reference IMG > CA (Cross Application) Components > General Application Functions > CA Document Numbering > Argentina >> Define Issuing Branch
07. Assign numbering concept to the country.
Go to transaction SPRO > SAP Reference IMG > FA > FA Global Settings > WHT > Extended WHT > Posting > Certificate Numbering for WTH >> Assign Numbering Concept to Company Code Country
08. Assign the form corresponding to the rate of WHT for Income Tax and IVA.
Go to transaction SPRO > SAP Reference IMG > FA > FA Global Settings > WHT > Extended WHT > Report >> Assign Forms for WHT Certificates
The current form in use is the “F_RFWTCT10_10” for both Income Tax and IVA withholding. Right then, you are ready to create an invoice and an outgoing payment for such vendor. At time of payment to such vendor, you will observe that the WHT calculation takes place.
For control purposes, check the sheet WHT at payment time before recording the transaction. Finally, the WHT Certificate will be printed through program RFWTCT10.
 
 

Related Content

Related Documents

Related SAP Notes/KBAs


Fonte: https://wiki.scn.sap.com/wiki/display/LOCLA/IVA+withholding+in+Argentina