Argentina E-Invoicing Web Service – SAP Package RG 2904 – SAP SD Implementation

Argentina E-Invoicing Web Service – SAP Package RG 2904 – SAP SD Implementation

Article

Argentina E-Invoicing Web Service – SAP Package RG2904 – SAP SD Implementation

Summary

SAP Note 1537823 has been released to implement latest E-Invoicing Solution for Argentina in ECC R/3 system. This document captures the basic process flow as a result of the implementation of this solution package RG 2904 & also provides in brief the basic SD Configuration required to implement the same.

Author: Swapnil Agrawal

Created On: 16^th September, 2014

Author Bio: Swapnil is a Consultant at Infosys & has over 4 years of professional work experience in SAP Sales and Distribution module. He is Engineering graduate from GBPUA&T University, Pantnagar, Uttarakhand & post graduate in General Management from NMIMS University, Mumbai. He would like to thank his team members Prashanth Raj, Sanu Pillai, Hemant Tewari, Sandeep Sahota, Neha Sinha , Farooq Syed & Bhargavi Vaidya for their contribution for this implementation.

Process Understanding

·         All the domestic & export SD invoices with tax has be to submitted to Argentina Government Portal called as AFIP – Portal de la Administración Federal de Ingresos (English Translation: Portal of the Federal Revenue Administration) for Approval & after tax approval, such invoices can be posted for accounting.

·         SAP Note 1537823 has been released to implement the above. Through this, a new transaction J1AMONITOR has been introduced for sending the invoice details in XML format to AFIP (Through PI Interface) & then, receiving back the approved/rejected invoices from AFIP.

Below is the flow chart to explain the process in more detail:

Below is a screenshot of the J1AMONITOR screen after an invoice has been approved with the logs for the invoice document:

Once, the invoice is approved, the reference field in header data tab of the invoice gets updated with a 13 digit number which is a combination of Branch(4 digits) + Print Character(1 Digit) + Official Document Number ODN(8 Digits) as shown below:

A 14-Digit CAE Number is generated in the AFIP Portal & sent back to SAP(only for the Approved Document) which is also displayed in J1AMONITOR as shown below:

The Invoices will then be released for accounting once they are approved by AFIP.

Main SAP Configurations Done:

1.      Document Numbering

SPRO: Cross-Application Components -> General Application Functions -> Cross-Application Document Numbering -> Argentina

●     Define Issuing Branches

0200, 0273 & 0274 are relevant for domestic scenarios(for the example used)

●     Define Document Classes

• Assign Document Class to Document Type

The ODN could be set as either B or C.

●     Maintain Print Characters

●     Generate Number Groups

●     Maintain Number Ranges(Transaction J1AB):

This is the last approved ODN number which should match with the one shown in J1AMONITOR.

●     Maintain Branch as Webservice Branch – 0273 & 0274 with 0200 as contingency branch(example)

The Automatic Release to Accounting incidator shows that the accounting document would be generated automatically as soon as it is approved by AFIP:

●    Branch Determination For Billing Documents

Based on the sales area, branch is determined as shown below:

·         Maintain RFC Destination

Contingency Mode:

●     In case of issues with AFIP server, SAP has given a provision to process invoices in contingency mode.

●     When a document is processed in contingency mode, it is not required to be sent to AFIP server.

●     CAI number(instead of CAE no.) is generated internally in SAP which is assigned to the invoice document which is displayed in the output of the invoice.

SAP Configuration for Contingency Mode:

●    Define branch as contingency branch(0200 branch is contingency branch):

●    CAI number is generated using the below table for ‘Define Print Authorization Codes’:

Business benefits

1.    After saving the invoice, the XML file is automatically sent to AFIP server & the response is received automatically in SAP. No manual activity involved for the key user.

2.    All the information related to the invoice available in J1AMONITOR which helps in better tracking of the invoices.

3.     Since, this is a legal process, companies in Argentina are required to mandatorily required to implement them

Fonte: https://blogs.sap.com/2014/09/16/argentina-e-invoicing-web-service-sap-package-rg-2904-sap-sd-implementation/

Formulas - AR

Purpose

The purpose of this page is to clarify the customizing of Pricing Procedures Formulas 333 and 334 in Localization Argentina.

Overview

The following section will explain the step-by-step of Formulas in Argentina, which is the first part of the process of configuration, that is preceded by Basic Customizing of Pricing Procedure - ARand Different Taxes - AR. Use transaction VOFM for the customizing.

Formula 333

Before calling Formula 333, the customer is checked for the tax categories that are maintained for him along with the exemption rate and its validity. These details are stored in table KNAT. If a tax category has some exemptions, then the condition type for it will consider these details in this formula. Firstly, table T007C is checked to get the details of grouped tax codes. Go to SPRO > Financial Accounting (New) > Financial Accounting Basic Settings (New) > Tax On Sales / Purchases > Basic Settings > Argentina > Tax Categories > Maintain Tax Categories.

Account type considered is always 'D' (customer). Example of tax category is IVA which has condition types J1AU and the reference condition type is J1AX. This is a VAT condition and so the flag 'is VAT like' is set.

 

Secondly, read the entries in table J_1ATXMIN for minimum amount maintained for Argentina accounting key.

Details of table J_1ATXMIN:

In this table, you maintain the minimum amount for a particular account key. If the minimum amount threshold is not reached, then that amount is not posted to G/L. Customization for this is in SPRO > Financial Accounting > Financial Accounting Basic Settings > Tax On Sales / Purchases > Basic Settings > Argentina > Maintain Minimum Amounts Per Processing Key.

Example: J1F account has a minimum amount set to ARS 21,30. In the pricing procedure, we have the condition types and from there we pick the account key. If that account key is J1F, then if the calculated amount is less than ARS 22,30, then it is not posted to G/L. They are converted to ARS 0,00.

- Read the internal table with pricing procedure detail for the reference conditions found in T007C.

- Pass all the condition base values to another in ternal table.

- Modify limit for for credit memos: If in th e preceding document (i.e., billing document) condition with same posting key has a non-zero value, set the lower limit to zero. Again, if preceding document exists and taxes are not explicitly to be redetermined, take over value from preceding document.

- Table T007C is read to get the reference condition and tax group, so read the customer (KNAT) to get the rates for exemptions maintained. Then check the exemption period.

- Apply exemption to reference condition of entire document and compare to limit.

- Fetching all the distinct tax rates in order to find the rounding differences.

- Loop for each tax rate. Loop on all reference conditions of same document to determine sum. Sum up base value of the reference condition and get the tax rate considering exemption rate. Calculate taxes for each item and sum up the calculated tax amount .

- Take over base value from reference condition and calculate actual.

- Rounding difference has to be added after considering all items.

- Rounding works when the rate is same for same tax type. Difference in amount is adjusted with highest tax amount.

- Field “Reason for Zero VAT” available at item level in sales and billing documents.

- 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.

Finally, consider the functions and details shown below:

- Rounding: This is considered on the header level, once all the condition rates of all items are summed and if there is any adjustments to be done, and then it is done on the reference condition. Rounding works when rate and tax type are same. Difference is adjusted with the highest tax amount (considering all items).

- Exemptions: These are considered from the customer master as we know the exemption rates applicable for a particular customer. Accordingly the taxes are calculated.

- Minimum amount: It is again maintained in table against accounting key. If suppose for VAT, the minimum amount maintained is ARS 21,30. Then if after calculation in document, VAT is less than this particular minimum amount, the value is set to ARS 0,00. Thus for any condition, if the final amount is less than the minimum amount, the value is set to zero.

- In case of VAT Perception (J1AQ): Full VAT perception is calculated in condition J1AP, which is the previous condition. This formula applies partial exemptions if present the customer is ‘subjected to’ via the tax category associated with condition J1AP. It is checked whether the document total value after application of the exemption exceeds the lower limit defined by the field 'low er_limit'.

- In case of Gross income perception (J1X1, J1X2, and J1X3): The full gross income perceptions are calculated in conditions J1A1, J1A2 and J1A3. This formula applies partial exemptions if present the customer is subjected to via the tax category associated with conditions J1A1, J1A2, J1A3.

- In case of partial VAT exemption (J1AX): This case is very seldom. The full VAT is calculated in condition J1AX. This formula applies if the VAT condition J1AU applies.

Formula 334:

The Formula 334 is used for calculating GI perception in SD. The SAP Note 1342470 contains the details of the customizing.

Considerations on Argentina's Pricing Procedures:

Formulas 333 and 331 validate that the perceptions (VAT perception / IG perceptions) is calculated at header level, is equal or bigger than ARS 21,30. Then it should be charged and also if the customer has exemptions. Routines 81 and 82, assures that the date to be consider to calculate taxes is the billing date for all documents and for referenced Credit or Debit Memos, it should be the date of the original document.

Related Content

Related Documents

Related Notes/KBA

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

Steps for Pricing Configuration & Maintaining Condition Type(s) in CRM

Goal of this blog is to document and understand basic configuration involved in

• Pricing Procedure Determination.
• Maintain Condition Types, Access Sequences and Condition records(with connection to Product in this example).

Scenario : Create a Sales Order with Base Price and Discount.

1. Go to Access Sequence (CRM SPRO->CRM->Basic Functions->Pricing->Create Access Sequences)

Create an Access Sequence ‘9000’

Use Condition table SAP004 which contains Sales organization, Distribution channel, Product as shown below.

2. Create a Condition Type(CRM SPRO->CRM->Basic Functions->Pricing->Define Settings for Pricing->Create Condition Type)

9000 – Discount  (Copy of 0KA0)

3.  Create a Pricing Procedure(CRM SPRO->CRM->Basic Functions->Pricing->Define Settings for Pricing->Create Pricing Procedure)

Pricing Procedure (9CRM01)

Maintain the Condition Type 9000(Special Discount) created in step 2.

4. Create a Customer Pricing procedure. (CRM SPRO->CRM->Basic Functions->Pricing->Pricing in Business Transaction->Define Customer Pricing Procedure

Maintain “1” as Business Partner Pricing Procedure

5. Assign Customer Pricing Procedure(=1) to Business Partner

SAP GUI Screen for reference for the same business partner

6. Enhance Condition Group PRODUCTCRM for CRM Product Master, to create a condition record for new Condition Type(9000) in connection with the Product. (CRM SPRO->Master Data->Conditions and Condition Technique->Condition Technique:Basics->Create Maintenance Group

Choose ‘PRODUCTCRM’

Maintain the Condition table SAP004 to allow maintenance of Condition records for the Product.

7. Maintain Condition Records on the Product

Product Price

Discount of 1% for Condition Type 9000 and Condition table SAP004 (Maintained in Step 6)

8. Activate the pricing trace in SU01.

9. Final checks before creating sales order.

A. Check Reference Currency maintained for Sales Org

B. Check Currency Maintained for Business Partner

C. Assign Document Pricing Procedure

D.  Create Pricing Procedure Determination (CRM SPRO->CRM->Basic Functions->Pricing->Define Settings for Pricing->Create Pricing Procedure

Pricing Procedure(9CRM01) will be determined based on the Combination of Sales Organization(0 50000109)/Document Pricing Procedure(Step 9.C) /Customer Pricing Procedure(5).

10. Now Create a Sales Order

Price = 10 USD; 9000 Special Offer -0.10 discount; Total = 9.90 USD

Pricing Procedure(9CRM01) Determined

SAP Gui Screen shot for Order

Note : This blog is intended for CRM Developers to quickly set up pricing procedure determination procedure in SAP CRM system and play in the system. Basic understanding of Condition type/Access Sequences/Condition Table required to follow these steps.

Fonte: https://blogs.sap.com/2014/12/11/pricing-configuration-determination-maintain-condition-type-in-crm/

ERP SD Revenue Recognition

• Created by Kelly Ynoue, last modified by Christian Rosa on Dec 11, 2013

Go to start of metadata

Purpose

The purpose of this page is to provide an overview about ERP SD Revenue Recognition functionality.

Overview

In the following sections you will find information about the available documentation, customizing, description of core business processes and handling of revenue recognition data.

Description

Many companies require that revenues are posted according to a time period. This means that the revenues must be realized in the posting period in which the service was carried out, and not in the posting period in which the billing document was set up.

The revenue recognition function in the SAP ERP system helps you to fulfill these requirements and separates the revenue recognition process from the billing process. The ERP system offers a flexible solution to companies using various methods of revenue recognition.

Revenue Recognition assessment

If customers want to use the revenue recognition functionality in their productive environment, the implementation must be subject to a pre go-live assessment to avoid a negative impact on the financial statement. This assessment is completely free of charge. In other words, the customer will have to ask explicit permission from SAP in order to use this functionality (detailed information is provided in SAP-notes 768561 and 779366).

Documentation

The latest version of the Revenue Recognition Best Practices document is attached to SAP-note 1172799.

• Necessary Customizing settings
• Supported processes and scenarios
• Limitations and restrictions placed on the solutions offered
• Recommendations for monitoring the revenue recognition process
• A guide for implementation

In addition to the 'Best Practice' document, an eLearning course for the SAP ERP SD Revenue Recognition function is available with the following title:

• SCM653: Sales and Distribution Revenue Recognition
• SCM654: Advanced Revenue Recognition

These eLearning courses can be found under www.sap.com/education.

Available methods

• Revenue recognition at the point of billing (standard method)
• Time-related revenue recognition (the revenues are realized between specific set dates)
• Service-related revenue recognition (the revenues are realized on the basis of a specific event, e.g. the goods issue for a delivery)
• Credit/Debit memo request with reference to preceding document
• Service based revenue recognition, billing related (only for IS-M solution)

Customizing

For the setup of revenue recognition processes you have to customize:

• FI accounts and their settings
• SD item categories and their settings
• Revenue recognition category on item category level
• Account determination

The following accounts are needed for the representation of the revenue recognition process:

• Revenue account (recognized revenues)
• Receivables account (customer account)
• Revenues to be deferred (deferred revenue account or D/R account)
• Unbilled receivables (unbilled receivables account or U/R account)

Revenue recognition category on item category level

Transaction: OVEP

Set Revenue Recognition category for Item Categories:

Possible entries for the field “Rev. recognition” are:

Account determination

Transaction: VKOA

Assign G/L accounts for revenues and deferred revenues:

 

• G/L account no. (SAKN1): revenue account
• Provision acc. (SAKN2): D/R account

Transaction: OVUR

Account for unbilled receivables (U/R account) has to be maintained depending on the reconciliation account and the associated chart of accounts:

• NonBldRec.: U /R account

Description of Core Businesss Processes

Process 1: Standard Revenue Recognition at time of billing

Process 2: Time based with VF44 as first

Process 3: Time based with invoice as first

Process 4: Service based with VF44 as first

Process 8: Time based & billing related (‘D’)

Process 9 – time based / service based with VF44 as first

 

Process 10 – time based / service based with VF44 as first

 

For a detailed explanation of all available processes, please refer to Revenue Recognition Best Practices document attached to SAP-note 1172799. 

Handling of revenue recognition data

Revenue realization processes

• Revenue recognition run (transaction VF44). With transaction VF44 the revenues are posted and financial accounting documents are created.
• The posted revenues can be cancelled by using transaction VF46, e.g. if revenues have been realized in error.
• In certain cases - for example, when you change condition values - revenue lines of the related sales document have to be updated. Transaction VF42 can be used to update revenue recognition data.
• Transaction VF45 shows deferred revenues, unbilled receivables, billed and realized amounts on the level of a sales document item.
• The report of VF47 shows inconsistencies between the revenue recognition tables VBREVK, VBREVE and VBREVR and the appropriate sales documents. Only development support may run it in update mode.

Related Documents

SAP Library path:

 SAP ERP Central Component -> Logistics -> Sales and Distribution (SD) -> Billing (SD-BIL) -> Revenue Recognition

http://help.sap.com/saphelp_46c/helpdata/en/46/74a073b4e411d199bc0000e8a5bd28/content.htm

http://help.sap.com/saphelp_470/helpdata/en/2d/bdd69ad9b411d199d80000e8a5bd28/content.htm

Related SAP Notes

SAP Note 1172799: New version of Best Practices for revenue recognition

Fonte: https://wiki.scn.sap.com/wiki/display/SD/ERP+SD+Revenue+Recognition