[MERGE] Forward-port of branch 12.0 to 13.0
This commit is contained in:
Antoine Vandevenne (anv)
@@ -0,0 +1,20 @@
|
||||
=============
|
||||
Localizations
|
||||
=============
|
||||
|
||||
.. toctree::
|
||||
:titlesonly:
|
||||
|
||||
localizations/argentina
|
||||
localizations/australia
|
||||
localizations/chile
|
||||
localizations/colombia
|
||||
localizations/colombia_ES
|
||||
localizations/france
|
||||
localizations/germany
|
||||
localizations/indonesia
|
||||
localizations/italy_IT
|
||||
localizations/mexico
|
||||
localizations/netherlands
|
||||
localizations/spain
|
||||
localizations/switzerland
|
||||
+638
@@ -0,0 +1,638 @@
|
||||
=========
|
||||
Argentina
|
||||
=========
|
||||
|
||||
Webinars
|
||||
========
|
||||
|
||||
Below you can find videos with a general description of the localization, and how to configure it.
|
||||
|
||||
- `VIDEO WEBINAR OF A COMPLETE DEMO <https://youtu.be/c41-8cVaYAI>`_.
|
||||
|
||||
Introduction
|
||||
============
|
||||
|
||||
The Argentinean localization has been improved and extended in Odoo v13, in this version the next
|
||||
modules are available:
|
||||
|
||||
- **l10n_ar**: This module add accounting features for the Argentinian localization, which represent
|
||||
the minimal configuration needed for a company to operate in Argentina and under the AFIP
|
||||
(Administración Federal de Ingresos Públicos) regulations and guidelines.
|
||||
|
||||
- **l10n_ar_reports**: Add VAT Book report which is a legal requirement in Argentine and that holds
|
||||
the VAT detail info of sales or purchases recorded on the journal entries. This module includes as
|
||||
well the VAT summary report that is used to analyze the invoice
|
||||
|
||||
- **l10n_ar_edi**: This module includes all technical and functional requirements to generate
|
||||
Electronic Invoice via web service, based on the AFIP regulations.
|
||||
|
||||
|
||||
Configuration
|
||||
=============
|
||||
|
||||
Install the Argentinean localization modules
|
||||
--------------------------------------------
|
||||
|
||||
For this, go to *Apps* and search for Argentina. Then click *Install* for the first two modules.
|
||||
|
||||
.. image:: media/argentina01.png
|
||||
:align: center
|
||||
|
||||
Configure your company
|
||||
~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Once that the modules are installed, the first step is to set up your company data. Additional to
|
||||
the basic information, a key field to fill in the AFIP Responsibility Type, that represent the
|
||||
fiscal obligation and structure of the company:
|
||||
|
||||
.. image:: media/argentina02.png
|
||||
:align: center
|
||||
|
||||
|
||||
Chart of Account
|
||||
~~~~~~~~~~~~~~~~
|
||||
|
||||
In Accounting settings there are three available packages of Chart of accounts, which are related to
|
||||
the AFIP responsibility type of the Company, considering that if the base companies don't require as
|
||||
many accounts as the companies that gave more complex fiscal requirements:
|
||||
|
||||
- Monotributista (149 accounts).
|
||||
- IVA Exempto (159 accounts).
|
||||
- Responsables Inscriptos (166 Accounts).
|
||||
|
||||
.. image:: media/argentina03.png
|
||||
:align: center
|
||||
|
||||
Configure Master data
|
||||
---------------------
|
||||
|
||||
Electronic Invoice Credentials
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Environment
|
||||
***********
|
||||
|
||||
The AFIP infrastructure is replicated in two separate environments, Testing and Production.
|
||||
|
||||
Testing is provided so that the Companies can test their developments until they are ready to move
|
||||
into the Production environment. As these two environments are completely isolated from each other,
|
||||
the digital certificates of one instance are not valid in the other one.
|
||||
|
||||
Go to :menuselection:`Accounting --> Settings --> Argentinian Localization` to select the environment:
|
||||
|
||||
.. image:: media/argentina_edi_01.png
|
||||
:align: center
|
||||
|
||||
|
||||
AFIP Certificates
|
||||
*****************
|
||||
The electronic invoice and other afip services work with WebServices (WS) provided by the AFIP.
|
||||
|
||||
In order to enable communication with the AFIP, the first step is to request a Digital Certificate
|
||||
if you don’t have one already.
|
||||
|
||||
#. Generate certificate Sign Request (Odoo). When this option is selected a file with extension
|
||||
``.csr`` (certificate signing request) is generated to be used the AFIP portal to request the
|
||||
certificate.
|
||||
|
||||
.. image:: media/argentina_edi_02.png
|
||||
|
||||
#. Generate Certificate (AFIP). Access the AFIP portal and follow the instructions described in the
|
||||
next document in order to get a certificate. `Get AFIP Certificate
|
||||
<http://www.afip.gob.ar/ws/WSAA/wsaa_obtener_certificado_produccion.pdf>`_.
|
||||
|
||||
#. Upload Certificate and Private Key (Odoo). Once the certificate has been generated, it needs to
|
||||
be uploaded in Odoo, using the pencil next in the field “Certificado” and selecting the
|
||||
corresponding file.
|
||||
|
||||
.. image:: media/argentina_edi_03.png
|
||||
|
||||
.. tip::
|
||||
In case you need to configure the Homologation Certificate, please refer to the AFIP official
|
||||
documentation: `Homologation Certificate
|
||||
<http://www.afip.gob.ar/ws/documentacion/certificados.asp>`_.
|
||||
|
||||
Partner
|
||||
~~~~~~~
|
||||
|
||||
Identification Type and VAT
|
||||
***************************
|
||||
|
||||
As part of the Argentinean localization, the document types defined by the AFIP are now available on
|
||||
the Partner form, this information is essential for most transactions. There are six identification
|
||||
types available by default:
|
||||
|
||||
.. image:: media/argentina04.png
|
||||
:align: center
|
||||
|
||||
.. note::
|
||||
The complete list of Identification types defined by the AFIP is included in Odoo but only the
|
||||
common ones are active.
|
||||
|
||||
AFIP Responsibility Type
|
||||
************************
|
||||
|
||||
In Argentina the document type associated with customers and vendors transactions is defined based
|
||||
on the AFIP Responsibility type, this field should be defined in the partner form:
|
||||
|
||||
.. image:: media/argentina05.png
|
||||
:align: center
|
||||
|
||||
Taxes
|
||||
~~~~~
|
||||
|
||||
As part of the localization module, the taxes are created automatically with their related
|
||||
financial account and configuration.
|
||||
|
||||
.. image:: media/argentina06.png
|
||||
:align: center
|
||||
|
||||
Taxes Types
|
||||
***********
|
||||
|
||||
Argentina has several tax types, the most common ones are:
|
||||
|
||||
- VAT. Is the regular VAT and it can have several percentages.
|
||||
- Perception. Advance payment of a tax that is applied on Invoices.
|
||||
- Retention. Advance payment of a tax that is applied on payments
|
||||
- Otros.
|
||||
|
||||
Special Taxes
|
||||
*************
|
||||
|
||||
Some argentine taxes are not commonly used for all companies, these type of taxes are included as
|
||||
inactive by default, it's important that before creating a new tax you confirm if they are not
|
||||
already included in the Inactive taxes:
|
||||
|
||||
.. image:: media/argentina07.png
|
||||
:align: center
|
||||
|
||||
Document Types
|
||||
~~~~~~~~~~~~~~
|
||||
|
||||
In some Latin America countries, including Argentina, some accounting transactions like invoices and
|
||||
vendor bills are classified by document types defined by the government fiscal authorities (In
|
||||
Argentina case: AFIP).
|
||||
|
||||
The document type is an essential information that needs to be displayed in the printed reports and
|
||||
that needs to be easily identified, within the set of invoices as well of account moves.
|
||||
|
||||
Each document type can have a unique sequence per journal where it is assigned. As part of the
|
||||
localization, the Document Type include the country on which the document is applicable and the data
|
||||
is created automatically when the localization module is installed.
|
||||
|
||||
The information required for the document types is included by default so the user doesn't need to
|
||||
fill anything on this view:
|
||||
|
||||
.. image:: media/argentina08.png
|
||||
:align: center
|
||||
|
||||
.. note::
|
||||
There are several document types that are inactive by default but can be activated if needed.
|
||||
|
||||
Letters
|
||||
*******
|
||||
|
||||
For Argentina, the document types include a letter that helps that indicates the
|
||||
transaction/operation, example:
|
||||
|
||||
- When an invoice is related to a B2B transaction, a document type "A" must be used.
|
||||
- When an invoice is related to a B2C transaction, a document type "B" must be used.
|
||||
- When an invoice is related to exportation transaction, a document type "E" must be used.
|
||||
|
||||
The documents included in the localization have the proper letter associated, the user doesn't need
|
||||
to configure anything additional.
|
||||
|
||||
.. image:: media/argentina09.png
|
||||
:align: center
|
||||
|
||||
Use on Invoices
|
||||
***************
|
||||
|
||||
The document type on each transaction will be determined by:
|
||||
|
||||
- The Journal related to the Invoice, identifying if the journal use documents.
|
||||
- Condition applied based on the type of Issues and Receiver (ex. Type of fiscal regimen of
|
||||
the buyer and type of fiscal regimen of the vendor)
|
||||
|
||||
Journals
|
||||
--------
|
||||
|
||||
In the Argentinean localization the Journal can have a different approach depending on its usage and
|
||||
internal type, to configure you journals go to :menuselection:`Accounting --> Configuration -->
|
||||
Journals`:
|
||||
|
||||
For Sales and Purchase Journals it’s possible to enable the option *Use Documents*, this indicates
|
||||
the Journal enables a list of document types that can be related to the Invoices and vendor Bills,
|
||||
for more detail of the invoices, please refer to the section 2.3 Document Types.
|
||||
|
||||
If the Sales/Purchase journal are used without the option *Use Documents* it because they won’t be
|
||||
used to generate fiscal invoices, but mostly for account moves related to internal control process.
|
||||
|
||||
AFIP Information (also known as AFIP Point of Sale)
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
.. image:: media/argentina10.png
|
||||
:align: center
|
||||
|
||||
**AFIP POS System**: This field is only visible for the Sales journals and defined the type of AFIP
|
||||
POS that will be used to manage the transactions for which the journal is created. The AFIP POS
|
||||
defines as well:
|
||||
|
||||
#. The sequences of document types related to the Web service.
|
||||
#. The structure and data of the electronic invoice file.
|
||||
|
||||
Web Services
|
||||
************
|
||||
- ``wsfev1: Electronic Invoice.`` This is the most common service,
|
||||
is used to generated invoices for document types A, B, C, M with no detail per item.
|
||||
- ``wsbfev1: Electronic Fiscal Bond.`` For those who invoice capital goods and wish
|
||||
to access the benefit of the Electronic Tax Bonds granted by the Ministry of Economy. For more
|
||||
detail you can refer to the next link: `Fiscal Bond
|
||||
<https://www.argentina.gob.ar/acceder-un-bono-por-fabricar-bienes-de-capital>`_.
|
||||
- ``wsfexv1: Electronic Exportation Invoice.`` Used to generate invoices for international customers
|
||||
and transactions that involve exportation process, the document type related is type “E”.
|
||||
|
||||
.. image:: media/argentina_edi_04.png
|
||||
:align: center
|
||||
|
||||
**AFIP POS Number**: This is the number configured in the AFIP to identify the operations related to
|
||||
this AFIP POS.
|
||||
|
||||
**AFIP POS Address**: This field is related to commercial address registered for the POS, which is
|
||||
usually the same address than the Company. For example: has multiple stores (fiscal locations) then
|
||||
AFIP will require that you have one AFIP POS per location: this location will be printed in the
|
||||
invoice report.
|
||||
|
||||
**Unified Book**: When AFIP POS System is Preimpresa the document types (applicable to the journal)
|
||||
with the same letter will share the same sequence. For example:
|
||||
|
||||
- Invoice: FA-A 0001-00000002.
|
||||
- Credit Note: NC-A 0001-00000003.
|
||||
- Debit Note: ND-A 0001-00000004.
|
||||
|
||||
Sequences
|
||||
~~~~~~~~~
|
||||
In case that you want to synchronize the next number in the sequence in Odoo based on the next
|
||||
number in the AFIP POS, the next button that is visible under :doc:`developer mode
|
||||
<../../../../../applications/general/developer_mode>` can be used:
|
||||
|
||||
.. image:: media/argentina_edi_05.png
|
||||
:align: center
|
||||
|
||||
.. note::
|
||||
When creating the Purchase journals, it's possible to define if they can be related to document
|
||||
types or not. In case that the option to use documents is selected, there is no need to manually
|
||||
associate the document type sequences as the document number is provided by the vendor.
|
||||
|
||||
|
||||
Usage and testing
|
||||
=================
|
||||
|
||||
Invoice
|
||||
-------
|
||||
|
||||
After the partners and journals are created and configured, when the invoices are created the will
|
||||
have the next behaviour:
|
||||
|
||||
Document type assignation
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Once the partner is selected the document type will filled automatically, based on the AFIP document
|
||||
type:
|
||||
|
||||
**Invoice for a customer IVA Responsable Inscripto, prefix A**.
|
||||
|
||||
.. image:: media/argentina11.png
|
||||
:align: center
|
||||
|
||||
**Invoice for an end customer, prefix B**.
|
||||
|
||||
.. image:: media/argentina12.png
|
||||
:align: center
|
||||
|
||||
**Exportation Invoice, prefix E**.
|
||||
|
||||
.. image:: media/argentina13.png
|
||||
:align: center
|
||||
|
||||
As it is shown in the invoices, all of them use the same journal but the prefix and sequence is
|
||||
given by the document type.
|
||||
|
||||
The most common document type will be defined automatically for the different combinations of AFIP
|
||||
responsibility type but it can be updated manually by the user.
|
||||
|
||||
|
||||
Electronic Invoice elements
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
When using electronic invoice, if all the information is correct the Invoice is posted in the
|
||||
standard way, in case that something needs to be addressed (check the section common errors for more
|
||||
detail), an error message is raised indicating the issue/proposed solution and the invoice remains
|
||||
in draft until the related data is corrected.
|
||||
|
||||
Once the invoice is posted, the information related to the AFIP validation and status is displayed
|
||||
in the AFIP Tab, including:
|
||||
|
||||
- AFIP Autorisation: CAE number.
|
||||
- Expiration date: Deadline to deliver the invoice to the customers. Normally 10 days after the
|
||||
CAE is generated.
|
||||
- Result:
|
||||
|
||||
- Aceptado en AFIP.
|
||||
- Aceptado con Observaciones.
|
||||
|
||||
.. image:: media/argentina_edi_15.png
|
||||
:align: center
|
||||
|
||||
Invoice Taxes
|
||||
~~~~~~~~~~~~~
|
||||
|
||||
Based on the AFIP Responsibility type, the VAT tax can have a different behavior on the pdf
|
||||
report:
|
||||
|
||||
**A. Tax excluded:** In this case the taxed amount needs to be clearly identified in the report.
|
||||
This condition applies when the customer has the following AFIP Responsibility type:
|
||||
|
||||
- Responsable Inscripto.
|
||||
|
||||
.. image:: media/argentina14.png
|
||||
:align: center
|
||||
|
||||
**B. Tax amount included:** This means that the taxed amount is included as part of the product
|
||||
price, subtotal and totals. This condition applies when the customer has the following AFIP
|
||||
Responsibility types:
|
||||
|
||||
- IVA Sujeto Exento.
|
||||
- Consumidor Final.
|
||||
- Responsable Monotributo.
|
||||
- IVA liberado.
|
||||
|
||||
.. image:: media/argentina15.png
|
||||
:align: center
|
||||
|
||||
|
||||
Special Use Cases
|
||||
~~~~~~~~~~~~~~~~~
|
||||
|
||||
Invoices for Services
|
||||
*********************
|
||||
For electronic invoices that include Services, the AFIP requires to report the service starting
|
||||
and ending date, this information can be filled in the tab “Other Info”:
|
||||
|
||||
.. image:: media/argentina_edi_06.png
|
||||
:align: center
|
||||
|
||||
If the dates are not selected manually before the invoice is validated, the values will be
|
||||
filled automatically considering the beginning and day of the invoice month:
|
||||
|
||||
|
||||
.. image:: media/argentina_edi_07.png
|
||||
:align: center
|
||||
|
||||
Exportation Invoices
|
||||
********************
|
||||
The invoices related to Exportation transactions required a Journal that used the AFIP POS
|
||||
System “Expo Voucher - Web Service” so the proper document type be associated:
|
||||
|
||||
.. image:: media/argentina_edi_08.png
|
||||
:align: center
|
||||
|
||||
When the customer selected in the Invoice has set the AFIP responsibility type as “Cliente /
|
||||
Proveedor del Exterior” or “IVA Liberado – Ley Nº 19.640”, Odoo automatically assigned:
|
||||
|
||||
- Journal related to the exportation Web Service.
|
||||
- Exportation document type .
|
||||
- Fiscal position: Compras/Ventas al exterior.
|
||||
- Concepto AFIP: Products / Definitive export of goods.
|
||||
- Exempt Taxes.
|
||||
|
||||
.. image:: media/argentina_edi_09.png
|
||||
:align: center
|
||||
|
||||
.. note::
|
||||
The Exportation Documents required the Incoterm in :menuselection:`Other Info --> Accounting`:
|
||||
|
||||
.. image:: media/argentina_edi_13.png
|
||||
:align: center
|
||||
|
||||
|
||||
Fiscal Bond
|
||||
***********
|
||||
The Electronic Fiscal bond is used for those who invoice capital goods and wish to access
|
||||
the benefit of the Electronic Tax Bonds granted by the Ministry of Economy.
|
||||
|
||||
For these transactions it’s important to have into consideration the next requirements:
|
||||
|
||||
- Currency (according to parameter table) and invoice quotation.
|
||||
- Taxes.
|
||||
- Zone.
|
||||
- Detail each item.
|
||||
|
||||
- Code according to the Common Nomenclator of Mercosur (NCM).
|
||||
- Complete description.
|
||||
- Unit Net Price.
|
||||
- Quantity.
|
||||
- Unit of measurement.
|
||||
- Bonus.
|
||||
- VAT rate.
|
||||
|
||||
|
||||
Electronic Credit Invoice MiPyme (FCE)
|
||||
**************************************
|
||||
|
||||
**Invoices:** There are several document types classified as Mipyme also known as
|
||||
Electronic Credit Invoice (FCE in spanish), which is used to impulse the SME, its purpose is
|
||||
to develop a mechanism that improves the financing conditions of these companies and allows
|
||||
them to increase their productivity, through the early collection of credits and receivables
|
||||
issued to their clients and / or vendors.
|
||||
|
||||
For these transactions it’s important to have into consideration the next requirements:
|
||||
|
||||
- Specific document types (201, 202, 206, etc).
|
||||
- The emisor should be eligible by the AFIP to MiPyme transactions.
|
||||
- The amount should be bigger than 100,000 ARS.
|
||||
- A bank account type CBU must be related to the emisor, otherwise the invoice can’t
|
||||
be validated, having these errors messages for example:
|
||||
|
||||
.. image:: media/argentina_edi_10.png
|
||||
:align: center
|
||||
|
||||
**Credit& Debit Notes:** When creating a Credit/Debit note related to a FCE document, it is
|
||||
important take the next points into consideration:
|
||||
|
||||
- Use the Credit and Debit Note buttons, so the correct reference of the originator
|
||||
document passed to the note.
|
||||
|
||||
.. image:: media/argentina_edi_11.png
|
||||
:align: center
|
||||
|
||||
- The document letter should be the same than the originator document (either A or B).
|
||||
- The same currency as the source document must be used. When using a secondary currency
|
||||
there is an exchange difference if the currency rate is different between the emission day
|
||||
and the payment date, it’s possible to create a credit/debit note to decrease/increase the
|
||||
amount to pay in ARS.
|
||||
|
||||
In the workflow we can have two scenarios:
|
||||
|
||||
#. The FCE is rejected so the Credit Note should have the field “FCE, is Cancellation?” as True.
|
||||
#. The Credit Note, is created with the negative amount to annulate the FCE document,
|
||||
in this case the field “FCE, is Cancellation?” must be empty (false).
|
||||
|
||||
.. image:: media/argentina_edi_12.png
|
||||
:align: center
|
||||
|
||||
Invoice printed report
|
||||
~~~~~~~~~~~~~~~~~~~~~~
|
||||
The PDF report related to electronic invoices that have been validated by the AFIP includes
|
||||
a barcode at the bottom of the format which represent the CAE number, the Expiration Date is
|
||||
also displayed as it’s legal requirement:
|
||||
|
||||
.. image:: media/argentina_edi_14.png
|
||||
:align: center
|
||||
|
||||
|
||||
Troubleshooting and Auditing
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
For auditing and troubleshooting purposes you can get the detailed information of an
|
||||
invoice number that has been previously sent to the AFIP,
|
||||
|
||||
.. image:: media/argentina_edi_23.png
|
||||
:align: center
|
||||
|
||||
.. image:: media/argentina_edi_24.png
|
||||
:align: center
|
||||
|
||||
|
||||
You can also get the last number used in AFIP for a specific Document Type and POS Number
|
||||
as support for any possible issues on the sequence synchronization between Odoo and AFIP.
|
||||
|
||||
.. image:: media/argentina_edi_22.png
|
||||
:align: center
|
||||
|
||||
|
||||
Vendor Bills
|
||||
------------
|
||||
|
||||
Based on the purchase journal selected for the vendor bill, the document type is now a required field.
|
||||
This value is auto populated based on the AFIP Responsibility type of Issuer and Customer, but the
|
||||
value can be switched if necessary.
|
||||
|
||||
.. image:: media/argentina16.png
|
||||
:align: center
|
||||
|
||||
The document number needs to be registered manually and the format is validated automatically, in
|
||||
case that the format is invalid a user error will be displayed indicating the correct format that is
|
||||
expected.
|
||||
|
||||
.. image:: media/argentina17.png
|
||||
:align: center
|
||||
|
||||
The vendor bill number is structured in the same way that the invoices with the difference
|
||||
that the document sequence is input by the user: “Document Prefix - Letter - Document number".
|
||||
|
||||
|
||||
Validate Vendor Bill number in AFIP
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
As most companies have internal controls to verify that the vendor bill is related to an AFIP
|
||||
valid document, an automatic validation can be set in :menuselection:`Accounting --> Settings -->
|
||||
Argentinian Localization --> Validate document in the AFIP`, considering the following levels:
|
||||
|
||||
- **Not available:** The verification is not done (this is the default value).
|
||||
- **Available:** The verification is done, in case the number is not valid
|
||||
it only raises a warning but it allows you to post the vendor bill.
|
||||
- **Required:** The verification is done and it doesn't allow the user to
|
||||
post the vendor bill if the document number is not valid.
|
||||
|
||||
.. image:: media/argentina_edi_16.png
|
||||
:align: center
|
||||
|
||||
How to use it in Odoo
|
||||
*********************
|
||||
This tool incorporates in the vendor bill a new "Verify on AFIP" button located
|
||||
next to the AFIP Authorization code.
|
||||
|
||||
.. image:: media/argentina_edi_17.png
|
||||
:align: center
|
||||
|
||||
In case it’s not a valid AFIP authorization the value “Rejected” will be
|
||||
displayed and the details of the validation will be added to the chatter.
|
||||
|
||||
.. image:: media/argentina_edi_18.png
|
||||
:align: center
|
||||
|
||||
|
||||
Special Use cases
|
||||
~~~~~~~~~~~~~~~~~
|
||||
Untaxed Concepts
|
||||
****************
|
||||
There are some transactions that include items that are not part of the VAT base amount,
|
||||
this is commonly used in fuel and gasoline invoices.
|
||||
|
||||
The vendor bill will be registered using 1 item for each product that is part of the VAT
|
||||
base amount and an additional item to register the amount of the Exempt concept:
|
||||
|
||||
.. image:: media/argentina_edi_19.png
|
||||
:align: center
|
||||
|
||||
Perception Taxes
|
||||
****************
|
||||
The vendor bill will be registered using 1 item for each product that is part of the
|
||||
VAT base amount, the perception tax can be added in any of the product lines, as result
|
||||
we will have one tax group for the VAT and one for the perception, the perception default
|
||||
value is always 1.00.
|
||||
|
||||
.. image:: media/argentina_edi_20.png
|
||||
:align: center
|
||||
|
||||
You should use the pencil that is the next to the Perception amount to edit it
|
||||
and set the correct amount.
|
||||
|
||||
.. image:: media/argentina_edi_21.png
|
||||
:align: center
|
||||
|
||||
After this is done the invoice can be validated.
|
||||
|
||||
|
||||
Reports
|
||||
=======
|
||||
|
||||
As part of the localization the next Financial reports were added:
|
||||
|
||||
.. image:: media/argentina18.png
|
||||
:align: center
|
||||
|
||||
VAT Reports
|
||||
-----------
|
||||
|
||||
Libro de IVA Ventas
|
||||
~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
.. image:: media/argentina19.png
|
||||
:align: center
|
||||
|
||||
Libro de IVA Compras
|
||||
~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
.. image:: media/argentina20.png
|
||||
:align: center
|
||||
|
||||
Resumen de IVA
|
||||
~~~~~~~~~~~~~~
|
||||
|
||||
.. image:: media/argentina21.png
|
||||
:align: center
|
||||
|
||||
IIBB - Reports
|
||||
--------------
|
||||
|
||||
IIBB - Ventas por Jurisdicción
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
.. image:: media/argentina22.png
|
||||
:align: center
|
||||
|
||||
IIBB - Compras por Jurisdicción
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
.. image:: media/argentina23.png
|
||||
:align: center
|
||||
+76
@@ -0,0 +1,76 @@
|
||||
=========
|
||||
Australia
|
||||
=========
|
||||
|
||||
.. _australia/keypay:
|
||||
|
||||
KeyPay Australian Payroll
|
||||
=========================
|
||||
|
||||
The KeyPay Module synchronizes payslip accounting entries (e.g., expenses, social charges,
|
||||
liabilities, taxes) from KeyPay to Odoo automatically. Payroll administration is still done in
|
||||
KeyPay. We only record the journal entries in Odoo.
|
||||
|
||||
Configuration Steps
|
||||
-------------------
|
||||
|
||||
#. Create a company located in Australia.
|
||||
#. Check that the Australian localization module (Australia - Accounting) is installed.
|
||||
#. Configure the *KeyPay API*.
|
||||
|
||||
.. image:: media/australia-keypay-api.png
|
||||
:align: center
|
||||
:alt: Odoo Accounting settings includes a section for the Australian Loclization
|
||||
|
||||
#. More fields become visible after clicking on *Enable KeyPay Integration*.
|
||||
|
||||
.. image:: media/australia-keypay-integration.png
|
||||
:align: center
|
||||
:alt: Enabling KeyPay Integration in Odoo Accounting displays new fields in the settings
|
||||
|
||||
#. You can find the API Key in the *My Account* section of the KeyPay platform.
|
||||
|
||||
.. image:: media/australia-keypay-myaccount.png
|
||||
:align: center
|
||||
:alt: "Account Details" section on the KeyPay dashboard
|
||||
|
||||
#. The **Payroll URL** is pre-filled with ``https://keypay.yourpayroll.com.au``. *Please do not
|
||||
change it.*
|
||||
#. You can find the **Business ID** in the KeyPay URL. (i.e., ``189241``)
|
||||
|
||||
.. image:: media/australia-keypay-business-id.png
|
||||
:align: center
|
||||
:alt: The KeyPay "Business ID" number is in the URL
|
||||
|
||||
#. You can choose any Odoo journal to post the payslip entries.
|
||||
|
||||
How does the API work?
|
||||
----------------------
|
||||
|
||||
The API syncs the journal entries from KeyPay to Odoo and leaves them in draft mode. The reference
|
||||
includes the KeyPay payslip entry ID in brackets for the user to easily retrieve the same record in
|
||||
KeyPay and Odoo.
|
||||
|
||||
.. image:: media/australia-keypay-journal-entry.png
|
||||
:align: center
|
||||
:alt: Example of a KeyPay Journal Entry in Odoo Accounting (Australia)
|
||||
|
||||
.. note::
|
||||
The API sync is triggered by scheduled actions.
|
||||
|
||||
.. image:: media/australia-keypay-scheduled-actions.png
|
||||
:align: center
|
||||
:alt: Scheduled Actions settings for KeyPay Payroll in Odoo (debug mode)
|
||||
|
||||
KeyPay payslip entries also work based on double-entry bookkeeping. Debit must equal credit (like in
|
||||
Odoo).
|
||||
|
||||
The accounts used by KeyPay are defined in the section **Payroll settings**.
|
||||
|
||||
.. image:: media/australia-keypay-chart-of-accounts.png
|
||||
:align: center
|
||||
:alt: Chart of Accounts menu in KeyPay
|
||||
|
||||
For the API to work, you need to create the same accounts as the default accounts of your KeyPay
|
||||
business (**same name and same code**) in Odoo. You also need to choose the correct account types in
|
||||
Odoo to generate accurate financial reports.
|
||||
@@ -0,0 +1,719 @@
|
||||
=====
|
||||
Chile
|
||||
=====
|
||||
|
||||
Introduction
|
||||
============
|
||||
|
||||
The Chilean localization has been improved and extended in Odoo v13. In this version, the next
|
||||
modules are available:
|
||||
|
||||
- **l10n_cl:** Adds accounting features for the Chilean localization, which represent the minimal
|
||||
configuration required for a company to operate in Chile and under the SII
|
||||
(Servicio de Impuestos Internos) regulations and guidelines.
|
||||
|
||||
- **l10n_cl_edi:** Includes all technical and functional requirements to generate and receive
|
||||
Electronic Invoice via web service, based on the SII regulations.
|
||||
|
||||
- **l10n_cl_reports:** Adds the reports Propuesta F29 y Balance Tributario (8 columnas).
|
||||
|
||||
Configuration
|
||||
=============
|
||||
|
||||
Install the Chilean localization modules
|
||||
----------------------------------------
|
||||
|
||||
For this, go to *Apps* and search for Chile. Then click *Install* in the module **Chile
|
||||
E-invoicing**. This module has a dependency with **Chile - Accounting**. In case this last
|
||||
one is not installed, Odoo installs it automatically with E-invoicing.
|
||||
|
||||
.. image:: media/Chile01.png
|
||||
:align: center
|
||||
:alt: Chilean module to install on Odoo.
|
||||
|
||||
.. note::
|
||||
When you install a database from scratch selecting Chile as country, Odoo will automatically
|
||||
install the base module: Chile - Accounting.
|
||||
|
||||
|
||||
Company Settings
|
||||
----------------
|
||||
|
||||
Once the modules are installed, the first step is to set up your company data. Additional
|
||||
to the basic information, you need to add all the data and elements required for Electronic
|
||||
Invoice, the easiest way to configure it is in
|
||||
:menuselection:`Accounting --> Settings --> Chilean Localization`.
|
||||
|
||||
Fiscal Information
|
||||
~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Fill in the fiscal information for your company according to the SII register, follow the
|
||||
instructions on each section.
|
||||
|
||||
.. image:: media/Chile02.png
|
||||
:align: center
|
||||
:alt: Chilean company fiscal data.
|
||||
|
||||
Electronic Invoice Data
|
||||
~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
This is part of the main information required to generate electronic Invoice, select your
|
||||
environment and the legal information, as well as the email address to receive invoices
|
||||
from your vendors and the alias you use to send invoices to your customers.
|
||||
|
||||
.. image:: media/Chile03.png
|
||||
:align: center
|
||||
:alt: Chilean edi environment settings.
|
||||
|
||||
Configure DTE Incoming email server
|
||||
***********************************
|
||||
|
||||
In order to receive you the claim and acceptance emails from your customers, it is
|
||||
crucial to define the DTE incoming email server, considering this configuration:
|
||||
|
||||
.. image:: media/Chile03_2.png
|
||||
:align: center
|
||||
:alt: Incoming email server configuration for Chilean DTE.
|
||||
|
||||
.. tip::
|
||||
For your Go-live make sure you archive/remove from your inbox all the emails
|
||||
related to vendor bills that are not required to be processed in Odoo.
|
||||
|
||||
Certificate
|
||||
~~~~~~~~~~~
|
||||
|
||||
In order to generate the electronic invoice signature, a digital certificate with the extension ``.pfx``
|
||||
is required, proceed to this section and load your file and password.
|
||||
|
||||
.. image:: media/Chile03_3.png
|
||||
:align: center
|
||||
:alt: Digital certificate access.
|
||||
|
||||
.. image:: media/Chile04.png
|
||||
:align: center
|
||||
:alt: Digital certificate configuration.
|
||||
|
||||
A certificate can be shared between several users. If this is the case leave the user field empty,
|
||||
so all your billing users can use the same one. On the other hand, if you need to restrict the
|
||||
certificate for a particular user, just define the users in the certificate.
|
||||
|
||||
Financial Reports
|
||||
~~~~~~~~~~~~~~~~~
|
||||
|
||||
The report Propuesta F29 requires two values that need to be defined as part of the company
|
||||
configuration:
|
||||
|
||||
.. image:: media/Chile05.png
|
||||
:align: center
|
||||
:alt: Fiscal reports parameters.
|
||||
|
||||
Multicurrency
|
||||
~~~~~~~~~~~~~
|
||||
|
||||
The official currency rate in Chile is provided by the SBIF, you can find the SBIF
|
||||
synchronization service in the currency rate configuration and you can set a predefined interval
|
||||
for the rate updates.
|
||||
|
||||
.. image:: media/Chile05_2.png
|
||||
:align: center
|
||||
:scale: 25
|
||||
:alt: Currency reate service for Chile.
|
||||
|
||||
In order to configure your token, you need to enable developer mode and access to
|
||||
:menuselection:`Settings --> Technical --> System parameters` and search the parameter
|
||||
``sbif_api_key`` and in the field Value introduce your token provided by the SBIF:
|
||||
|
||||
.. image:: media/Chile05_3.png
|
||||
:align: center
|
||||
:alt: Token configuration for currency rate service.
|
||||
|
||||
Chart of accounts
|
||||
~~~~~~~~~~~~~~~~~
|
||||
|
||||
The chart of accounts is installed by default as part of the set of data included in
|
||||
the localization module. The accounts are mapped automatically in:
|
||||
|
||||
- Taxes.
|
||||
- Default Account Payable.
|
||||
- Default Account Receivable.
|
||||
- Transfer Accounts.
|
||||
- Conversion Rate.
|
||||
|
||||
|
||||
Master Data
|
||||
-----------
|
||||
|
||||
Partner
|
||||
~~~~~~~
|
||||
|
||||
Identification Type and VAT
|
||||
***************************
|
||||
|
||||
As part of the Chilean localization, the identification types defined by the SII
|
||||
are now available on the Partner form. This information is essential for most transactions.
|
||||
|
||||
.. image:: media/Chile06.png
|
||||
:align: center
|
||||
:scale: 25
|
||||
:alt: Chilean identification types for partners.
|
||||
|
||||
TaxpayerType
|
||||
************
|
||||
|
||||
In Chile, the document type associated with customers and vendors transactions is defined
|
||||
based on the Taxpayer Type. This field should be defined in the partner form, when creating
|
||||
a customer is important you make sure this value is set:
|
||||
|
||||
.. image:: media/Chile07.png
|
||||
:align: center
|
||||
:alt: Chilean taxpayer types for partners.
|
||||
|
||||
|
||||
Electronic Invoice Data
|
||||
***********************
|
||||
|
||||
As part of the information that is sent in the electronic Invoice, you need to define the
|
||||
email that is going to appear as the sender of the electronic invoice to your customer, and
|
||||
the Industry description.
|
||||
|
||||
.. image:: media/Chile07_2.png
|
||||
:align: center
|
||||
:alt: Chilean electronic invoice data for partners.
|
||||
|
||||
|
||||
Taxes
|
||||
~~~~~
|
||||
|
||||
As part of the localization module, the taxes are created automatically with their related
|
||||
financial account and configuration.
|
||||
|
||||
.. image:: media/Chile08.png
|
||||
:align: center
|
||||
:alt: Chilean taxes list.
|
||||
|
||||
Taxes Types
|
||||
***********
|
||||
|
||||
Chile has several tax types, the most common ones are:
|
||||
|
||||
- VAT. Is the regular VAT and it can have several rates.
|
||||
- ILA (Impuesto a la Ley de Alcholes). Taxes for alcoholic drinks. It has a different rate.
|
||||
|
||||
|
||||
Fiscal Positions
|
||||
~~~~~~~~~~~~~~~~
|
||||
|
||||
Based on the purchase transactions, the VAT can have different affections. This will be done
|
||||
in Odoo using the default purchase fiscal positions.
|
||||
|
||||
|
||||
Document Types
|
||||
~~~~~~~~~~~~~~
|
||||
|
||||
In some Latin American countries, including Chile, some accounting transactions like invoices and
|
||||
vendor bills are classified by document types defined by the government fiscal authorities (In
|
||||
Chile case: SII).
|
||||
|
||||
The document type is essential information that needs to be displayed in the printed reports and
|
||||
that needs to be easily identified within the set of invoices as well of account moves.
|
||||
|
||||
Each document type can have a unique sequence per journal where it is assigned. As part of the
|
||||
localization, the Document Type includes the country on which the document is applicable and the data
|
||||
is created automatically when the localization module is installed.
|
||||
|
||||
The information required for the document types is included by default so the user doesn't need to
|
||||
fill anything on this view:
|
||||
|
||||
.. image:: media/Chile09.png
|
||||
:align: center
|
||||
:alt: Chilean fiscal document types list.
|
||||
|
||||
.. note::
|
||||
There are several document types that are inactive by default but can be activated if needed.
|
||||
|
||||
|
||||
Use on Invoices
|
||||
***************
|
||||
|
||||
The document type on each transaction will be determined by:
|
||||
|
||||
- The Journal related to the Invoice, identifying if the journal uses documents.
|
||||
- Condition applied based on the type of Issues and Receiver (ex. Type of fiscal
|
||||
regimen of the buyer and type of fiscal regimen of the vendor).
|
||||
|
||||
|
||||
Journals
|
||||
--------
|
||||
|
||||
Usage
|
||||
~~~~~
|
||||
|
||||
Sales
|
||||
*****
|
||||
|
||||
Sales Journals in Odoo usually represent a business unit or location, example:
|
||||
|
||||
- Ventas Santiago.
|
||||
- Ventas Valparaiso.
|
||||
|
||||
For the retail stores is common to have one journal per POS:
|
||||
|
||||
- Cashier 1.
|
||||
- Cashier 2.
|
||||
|
||||
|
||||
Purchases
|
||||
*********
|
||||
|
||||
The transactions purchase can be managed with a single journal, but sometimes companies use
|
||||
more than one in order to handle some accounting transactions that are not related to vendor
|
||||
bills but can be easily registered using this model, for example:
|
||||
|
||||
- Tax Payments to government.
|
||||
- Employees payments.
|
||||
|
||||
|
||||
Configuration
|
||||
~~~~~~~~~~~~~
|
||||
|
||||
When creating sales journals the next information must be filled in:
|
||||
|
||||
**Point of sale type**: If the Sales journal will be used for electronic documents, the option
|
||||
Online must be selected. Otherwise, if the journal is used for invoices imported from a previous
|
||||
system or if you are using the SII portal “Facturación MiPyme“ you can use the option Manual.
|
||||
|
||||
**Use Documents**: This field is used to define if the journal will use Document Types. It is only
|
||||
applicable to Purchase and Sales journals that can be related to the
|
||||
different sets of document types available in Chile. By default, all the sales journals created will
|
||||
use documents.
|
||||
|
||||
.. image:: media/Chile10.png
|
||||
:align: center
|
||||
:alt: Document type configuration on Journal.
|
||||
|
||||
Sequences
|
||||
*********
|
||||
|
||||
When a Journal is created we have two options with document types sequences.
|
||||
|
||||
1. Create new sequences: In this case, Odoo will create new sequences for the most common document
|
||||
types.
|
||||
2. Use existent sequence: If the sequence should be shared between several journals, the user can
|
||||
add manually sequences previously created.
|
||||
|
||||
.. image:: media/Chile11.png
|
||||
:align: center
|
||||
:alt: Steps to add new sequences on journals.
|
||||
|
||||
.. important::
|
||||
For the Chilean localization it’s important to define the default Debt and Credit accounts
|
||||
as they are required for one of the debit notes use cases.
|
||||
|
||||
CAF
|
||||
***
|
||||
|
||||
For each sequence related to the documents type, a CAF (Folio Authorization Code) is required,
|
||||
the CAF is a file the SII provides to the Emisor with the folio/sequence authorized for the
|
||||
electronic invoice documents.
|
||||
|
||||
Your company can make several requests for folios and obtain several CAFs, each one associated
|
||||
with different ranges of folios. In this way, you could order folios per the different
|
||||
segmentations you have in your journals (example per office) thus avoiding distributing a range
|
||||
of folios. In this way, each branch would have its private key of the respective CAF.
|
||||
|
||||
Please refer to the SII documentation to check the detail on how to acquire the CAF:
|
||||
`SII Timbraje <https://palena.sii.cl/dte/mn_timbraje.html>`_.
|
||||
|
||||
|
||||
Configuration
|
||||
^^^^^^^^^^^^^
|
||||
|
||||
Once you have the CAF files you need to associate them with journal sequence in Odoo,
|
||||
after you create the sequence for the first time the will be in red, which indicates
|
||||
that no CAF has been configured for that particular sequence:
|
||||
|
||||
.. image:: media/Chile12.png
|
||||
:align: center
|
||||
:alt: Sequences per document type on journals.
|
||||
|
||||
In order to add a CAF, just follow these steps:
|
||||
|
||||
1. Open the sequence.
|
||||
2. Go the the Tab “CAF”.
|
||||
3. Upload the file.
|
||||
4. Save the CAF.
|
||||
5. Save the sequence.
|
||||
|
||||
.. image:: media/Chile13.gif
|
||||
:align: center
|
||||
:alt: Steps to add a new CAF on sequences.
|
||||
|
||||
|
||||
As a result, the sequence color changes to black and the column Next number and quantity
|
||||
available are updated:
|
||||
|
||||
.. image:: media/Chile13.png
|
||||
:align: center
|
||||
:alt: Sequences per document type on journals.
|
||||
|
||||
|
||||
Usage and Testing
|
||||
=================
|
||||
|
||||
Electronic Invoice Workflow
|
||||
---------------------------
|
||||
|
||||
In the Chilean localization the electronic Invoice workflow covers the Emission of
|
||||
Customer Invoices and the reception of Vendor Bills, in the next diagram we explain how
|
||||
the information transmitted to the SII and between the customers and Vendors.
|
||||
|
||||
.. image:: media/Chile14.png
|
||||
:align: center
|
||||
:alt: Diagram with Electronic invoice transactions.
|
||||
|
||||
|
||||
Customer invoice Emission
|
||||
-------------------------
|
||||
|
||||
After the partners and journals are created and configured, the invoices are created in
|
||||
the standard way, for Chile one of the differentiators is the document type which is selected
|
||||
automatically based on the Taxpayer.
|
||||
|
||||
You can manually change the document type if needed.
|
||||
|
||||
.. image:: media/Chile15.png
|
||||
:align: center
|
||||
:alt: Document type selection on invoices.
|
||||
|
||||
|
||||
Validation and DTE Status
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
When all the invoice information is filled, either manually or automatically when it’s created
|
||||
from a sales order, proceed to validate the invoice. After the invoice is posted:
|
||||
|
||||
- The DTE File (Electronic Tax Document) is created automatically and added in the chatter.
|
||||
- The DTE SII status is set as: Pending to be sent.
|
||||
|
||||
.. image:: media/Chile16.png
|
||||
:align: center
|
||||
:alt: DTE XML File displayed in chatter.
|
||||
|
||||
The DTE Status is updated automatically by Odoo with a scheduled action that runs every day
|
||||
at night, if you need to get the response from the SII immediately you can do it manually as well.
|
||||
The DTE status workflow is as follows:
|
||||
|
||||
.. image:: media/Chile17.png
|
||||
:align: center
|
||||
:alt: Transition of DTE statuses.
|
||||
|
||||
|
||||
1. In the first step the DTE is sent to the SII, you can manually send it using the button: Enviar
|
||||
Ahora, a SII Tack number is generated and assigned to the invoice, you can use this number to
|
||||
check the details the SII sent back by email. The DTE status is updated to Ask for Status.
|
||||
|
||||
|
||||
2. Once the SII response is received Odoo updates the DTE Status, in case you want to do it
|
||||
manually just click on the button: Verify on SII. The result can either be Accepted, Accepted
|
||||
With Objection or Rejected.
|
||||
|
||||
.. image:: media/Chile18.png
|
||||
:align: center
|
||||
:alt: Identification transaction for invoice and Status update.
|
||||
|
||||
|
||||
There are several internal status in the SII before you get Acceptance or Rejection, in
|
||||
case you click continuously the Button Verify in SII, you will receive in the chatter the
|
||||
detail of those intermediate statuses:
|
||||
|
||||
.. image:: media/Chile18_2.png
|
||||
:align: center
|
||||
:alt: Descprtion of each DTE status in the chatter.
|
||||
|
||||
3. The final response from the SII, can take on of these values:
|
||||
|
||||
|
||||
**Accepted:** Indicates the invoice information is correct, our document is now fiscally valid
|
||||
and it’s automatically sent to the customer.
|
||||
|
||||
**Accepted with objections:** Indicates the invoice information is correct but a minor issue
|
||||
was identified, nevertheless our document is now fiscally valid and it’s automatically
|
||||
sent to the customer.
|
||||
|
||||
.. image:: media/Chile19.png
|
||||
:align: center
|
||||
:alt: Email track once it is sent to the customer.
|
||||
|
||||
**Rejected:** Indicates the information in the invoice is incorrect and needs to be
|
||||
corrected, the detail of the issue is received in the emails you registered in the
|
||||
SII, if it is properly configured in Odoo, the details are also retrieved
|
||||
in the chatter once the email server is processed.
|
||||
|
||||
If the invoice is Rejected please follow this steps:
|
||||
|
||||
* Change the document to draft.
|
||||
* Make the required corrections based on the message received from the SII.
|
||||
* Post the invoice again.
|
||||
|
||||
.. image:: media/Chile20.png
|
||||
:align: center
|
||||
:alt: Message when an invoice is rejected.
|
||||
|
||||
|
||||
Crossed references
|
||||
~~~~~~~~~~~~~~~~~~
|
||||
|
||||
When the Invoice is created as a result of another fiscal document, the information related to the
|
||||
originator document must be registered in the Tab Cross Reference, which is commonly used for
|
||||
credit or debit notes, but in some cases can be used on Customer Invoices as well. In the case of the
|
||||
credit and debit notes, they are set automatically by Odoo:
|
||||
|
||||
.. image:: media/Chile21.png
|
||||
:align: center
|
||||
:alt: Invoice tab with origin document number and data.
|
||||
|
||||
Invoice PDF Report
|
||||
~~~~~~~~~~~~~~~~~~
|
||||
|
||||
After the invoice is Accepted and valdiated by the SII and the PDF is printed it includes the
|
||||
fiscal elements that indicates out document is fiscally valid:
|
||||
|
||||
.. image:: media/Chile22.png
|
||||
:align: center
|
||||
:alt: Barcode and fiscal elements in the invice report.
|
||||
|
||||
|
||||
Commercial Validation
|
||||
~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Once the invoice has been sent to the customer:
|
||||
|
||||
1. DTE partner status changes to “Sent”.
|
||||
2. The customer must send a reception confirmation email.
|
||||
3. Subsequently, if all the commercial terms and invoice data are correct, they will send the
|
||||
Acceptance confirmation, otherwise they send a Claim.
|
||||
4. The field DTE acceptation status is updated automatically.
|
||||
|
||||
.. image:: media/Chile23.png
|
||||
:align: center
|
||||
:alt: Message with the commercial acceptance from the customer.
|
||||
|
||||
|
||||
Processed for Claimed invoices
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Once the invoice has been Accepted by the SII **it can not be cancelled in Odoo**. In case you
|
||||
get a Claim for your customer the correct way to proceed is with a Credit Note to either cancel
|
||||
the Invoice or correct it. Please refer to the Credit Notes section for more details.
|
||||
|
||||
.. image:: media/Chile24.png
|
||||
:align: center
|
||||
:alt: Invoice Comercial status updated to Claimed.
|
||||
|
||||
Common Errors
|
||||
~~~~~~~~~~~~~
|
||||
|
||||
There are multiple reasons behind a rejection from the SII, but these are some of the common errors
|
||||
you might have and which is the related solution.
|
||||
|
||||
- Error: RECHAZO- DTE Sin Comuna Origen.
|
||||
|
||||
*Hint:* Make sure the Company Address is properly filled including the State and City.
|
||||
|
||||
- Error en Monto : - IVA debe declararse.
|
||||
|
||||
*Hint:* The invoice lines should include one VAT tax, make sure you add one on each invoice line.
|
||||
|
||||
- Error: Rut No Autorizado a Firmar.
|
||||
|
||||
*Hint:* The invoice lines should include one VAT tax, make sure you add one on each invoice line.
|
||||
|
||||
- Error: Fecha/Número Resolucion Invalido RECHAZO- CAF Vencido : (Firma_DTE[AAAA-MM-DD] -
|
||||
CAF[AAAA-MM-DD]) > 6 meses.
|
||||
|
||||
*Hint:* Try to add a new CAF in the journal sequence related to this document as the one you’re
|
||||
using is expired.
|
||||
|
||||
|
||||
|
||||
Credit Notes
|
||||
------------
|
||||
|
||||
When a cancellation or correction is needed over a validated invoice, a credit note must be
|
||||
generated. It is important to consider that a CAF file is required for the Credit Note sequence,
|
||||
which is identified as document 64 in the SII.
|
||||
|
||||
.. image:: media/Chile25.png
|
||||
:align: center
|
||||
:alt: Creation of CAF for Credit notes sequences.
|
||||
|
||||
|
||||
.. tip:: Refer to the journal section where we described the process to load the CAF on each
|
||||
sequence.
|
||||
|
||||
Use Cases
|
||||
~~~~~~~~~
|
||||
|
||||
Cancel Referenced document
|
||||
**************************
|
||||
|
||||
In case you need to cancel or invalid an Invoice, use the button Add Credit note and select Full
|
||||
Refund, in this case the SII reference Code is automatically set to: Anula Documento de referencia.
|
||||
|
||||
.. image:: media/Chile26.png
|
||||
:align: center
|
||||
:alt: Full invoice refund with SII reference code 1.
|
||||
|
||||
Corrects Referenced Document Text
|
||||
*********************************
|
||||
|
||||
If a correction in the invoice information is required, for example the Street Name, use the button
|
||||
Add Credit note,select Partial Refund and select the option “Solo corregir Texto”. In this case
|
||||
the SII reference Code is automatically set to: Corrige el monto del Documento de Referencia.
|
||||
|
||||
.. image:: media/Chile27.png
|
||||
:align: center
|
||||
:alt: Partial refund to correct text including the corrected value.
|
||||
|
||||
Odoo creates a Credit Note with the corrected text in an invoice and price 0.
|
||||
|
||||
.. image:: media/Chile28.png
|
||||
:align: center
|
||||
:alt: Credit note with the corrected value on the invoice lines.
|
||||
|
||||
.. important::
|
||||
It’s important to define the default credit account in the Sales journal as it
|
||||
is taken for this use case in specific.
|
||||
|
||||
Corrects Referenced Document Amount
|
||||
***********************************
|
||||
|
||||
When a correction on the amounts is required, use the button Add Credit note
|
||||
and select Partial Refund. In this case the SII reference Code is automatically
|
||||
set to: Corrige el monto del Documento de Referencia.
|
||||
|
||||
.. image:: media/Chile30.png
|
||||
:align: center
|
||||
:alt: Credit note for partial refund to correct amounts, using the SII reference code 3.
|
||||
|
||||
Debit Notes
|
||||
-----------
|
||||
|
||||
As part of the Chilean localization, besides creating credit notes from an existing document you
|
||||
can also create debit Notes. For this just use the button “Add Debit Note”. The two main use
|
||||
cases for debit notes are detailed below.
|
||||
|
||||
Use Cases
|
||||
~~~~~~~~~
|
||||
|
||||
Add debt on Invoices
|
||||
********************
|
||||
|
||||
The most common use case for debit notes is to increase the value of an existing invoice, you
|
||||
need to select option 3 in the field Reference code SII:
|
||||
|
||||
.. image:: media/Chile31.png
|
||||
:align: center
|
||||
:alt: Debit note for partial refund to crrect amounts, using the SII reference code 3.
|
||||
|
||||
|
||||
In this case Odoo automatically includes the source invoice in the cross reference section:
|
||||
|
||||
.. image:: media/Chile32.png
|
||||
:align: center
|
||||
:alt: Invoice data on crossed reference section for debit notes.
|
||||
|
||||
Cancel Credit Notes
|
||||
*******************
|
||||
|
||||
In Chile the debits notes are used to cancel a validated Credit Note, in this case just
|
||||
select the button Add debit note and select the first option in the wizard: *1: Anula
|
||||
Documentos de referencia.*
|
||||
|
||||
.. image:: media/Chile33.png
|
||||
:align: center
|
||||
:alt: Creating a debit note to cancel a credit note with the SII code reference 1.
|
||||
|
||||
|
||||
Vendor Bills
|
||||
------------
|
||||
|
||||
As part of the Chilean localization, you can configure your Incoming email server as the same you
|
||||
have register in the SII in order to:
|
||||
|
||||
- Automatically receive the vendor bills DTE and create the vendor bill based on this information.
|
||||
- Automatically Send the reception acknowledgement to your vendor.
|
||||
- Accept or Claim the document and send this status to your vendor.
|
||||
|
||||
|
||||
Reception
|
||||
~~~~~~~~~
|
||||
|
||||
As soon as the vendor email with the attached DTE is received:
|
||||
1. The vendor Bill mapping all the information included in the xml.
|
||||
2. An email is sent to the vendor with the Reception acknowledgement.
|
||||
3. The DTE status is set as: Acuse de Recibido Enviado
|
||||
|
||||
.. image:: media/Chile34.png
|
||||
:align: center
|
||||
:alt: Messages recorded in the chatter with the reception notification for the vendor.
|
||||
|
||||
Acceptation
|
||||
~~~~~~~~~~~
|
||||
|
||||
If all the commercial information is correct on your vendor bill, you can accept the document using
|
||||
the button: Aceptar Documento, once this is done the DTE Acceptation Status changes to: Accepted and
|
||||
an email of acceptance is sent to the vendor.
|
||||
|
||||
.. image:: media/Chile35.png
|
||||
:align: center
|
||||
:alt: Acceptance button in vendor bills to inform the vendor all the document is comercially accepted.
|
||||
|
||||
|
||||
Claim
|
||||
~~~~~
|
||||
|
||||
In case there is a commercial issue or the information is not correct on your vendor bill, you can
|
||||
Claim the document before validating it, using the button: Claim, once this is done the DTE
|
||||
Acceptation Status change to: Claim and an email of acceptance is sent to the vendor.
|
||||
|
||||
.. image:: media/Chile36.png
|
||||
:align: center
|
||||
:alt: Claim button in vendor bills to inform the vendor all the document is comercially rejected.
|
||||
|
||||
If you claim a vendor bill, the status changes from draft to cancel automatically. Considering this
|
||||
as best practice, all the Claim documents should be canceled as they won’t be valid for your
|
||||
accounting records.
|
||||
|
||||
|
||||
Financial Reports
|
||||
=================
|
||||
|
||||
Balance Tributario de 8 Columnas
|
||||
--------------------------------
|
||||
|
||||
This report presents the accounts in detail (with their respective balances), classifying them
|
||||
according to their origin and determining the level of profit or loss that the business had within
|
||||
the evaluated period of time, so that a real and complete knowledge of the status of a company.
|
||||
|
||||
You can find this report in :menuselection:`Accounting --> Accounting --> Reports`
|
||||
|
||||
.. image:: media/Chile37.png
|
||||
:align: center
|
||||
:alt: Columns and data displayed in the report Balance Tributario 8 Columnas.
|
||||
|
||||
Propuesta F29
|
||||
-------------
|
||||
|
||||
The form F29 is a new system that the SII enabled to taxpayers, and that replaces the Purchase and
|
||||
Sales Books. This report is integrated by Purchase Register (CR) and the Sales Register (RV).
|
||||
Its purpose is to support the transactions related to VAT, improving its control and declaration.
|
||||
|
||||
This record is supplied by the electronic tax documents (DTE’s) that have been received by the
|
||||
SII.
|
||||
|
||||
You can find this report in :menuselection:`Accounting --> Accounting --> Reports`
|
||||
|
||||
.. image:: media/Chile38.png
|
||||
:align: center
|
||||
:alt: Parameters to required to generate the Report Propuesta F29
|
||||
+268
@@ -0,0 +1,268 @@
|
||||
========
|
||||
Colombia
|
||||
========
|
||||
|
||||
Webinars
|
||||
========
|
||||
|
||||
Below you can find videos with a general description of the localization, and how to configure it.
|
||||
|
||||
- `VIDEO WEBINAR OF A COMPLETE DEMO <https://youtu.be/BOzucXRUZDE>`_.
|
||||
|
||||
Introduction
|
||||
============
|
||||
|
||||
Electronic invoicing for Colombia is available from Odoo 12 and
|
||||
requires the next modules:
|
||||
|
||||
#. **l10n_co**: All the basic data to manage the accounting module,
|
||||
contains the default setup for: chart of accounts, taxes,
|
||||
retentions, identification document types
|
||||
#. **l10n_co_edi**: This module includes all the extra fields that are
|
||||
required for the Integration with Carvajal T&S and generate the
|
||||
electronic invoice, based on the DIAN legal requirements.
|
||||
|
||||
|
||||
Workflow
|
||||
========
|
||||
|
||||
.. image:: media/colombia01.png
|
||||
:align: center
|
||||
|
||||
|
||||
Configuration
|
||||
=============
|
||||
|
||||
Install the Colombian localization modules
|
||||
------------------------------------------
|
||||
|
||||
For this, go in Apps and search for Colombia. Then click Install for
|
||||
the first two modules.
|
||||
|
||||
.. image:: media/colombia02.png
|
||||
:align: center
|
||||
|
||||
|
||||
Configure credentials for Carvajal T&S web service
|
||||
--------------------------------------------------
|
||||
|
||||
Once that the modules are installed, in order to be able to connect
|
||||
with Carvajal T&S Web Service, it's necessary to configure the user
|
||||
and credentials, this information will be provided by Carvajal T&S.
|
||||
|
||||
Go to :menuselection:`Accounting --> Configuration --> Settings` and
|
||||
look for the *Colombian Electronic Invoice* section.
|
||||
|
||||
.. image:: media/colombia03.png
|
||||
:align: center
|
||||
|
||||
Using the Testing mode it is possible to connect with a Carvajal T&S
|
||||
testing environment. This allows users to test the complete workflow
|
||||
and integration with the CEN Financiero portal, which is accessible
|
||||
here: https://cenfinancierolab.cen.biz
|
||||
|
||||
Once that Odoo and Carvajal T&S is fully configured and ready for
|
||||
production the testing environment can be disabled.
|
||||
|
||||
|
||||
Configure your report data
|
||||
--------------------------
|
||||
|
||||
As part of the configurable information that is sent in the XML, you
|
||||
can define the data for the fiscal section and the bank information in
|
||||
the PDF.
|
||||
|
||||
Go to :menuselection:`Accounting --> Configuration --> Settings` and
|
||||
look for the *Colombian Electronic Invoice* section.
|
||||
|
||||
.. image:: media/colombia04.png
|
||||
:align: center
|
||||
|
||||
|
||||
Configure data required in the XML
|
||||
----------------------------------
|
||||
|
||||
Partner
|
||||
~~~~~~~
|
||||
|
||||
Identification
|
||||
^^^^^^^^^^^^^^
|
||||
|
||||
As part of the Colombian Localization, the document types defined by
|
||||
the DIAN are now available on the Partner form. Colombian partners
|
||||
have to have their identification number and document type set:
|
||||
|
||||
.. image:: media/colombia05.png
|
||||
:align: center
|
||||
|
||||
.. tip:: When the document type is RUT the identification number needs
|
||||
to be configured in Odoo including the verification digit, Odoo
|
||||
will split this number when the data to the third party vendor is
|
||||
sent.
|
||||
|
||||
|
||||
Fiscal structure (RUT)
|
||||
^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
The partner's responsibility codes (section 53 in the RUT document)
|
||||
are included as part of the electronic invoice module given that is
|
||||
part of the information required by the DIAN .
|
||||
|
||||
These fields can be found in :menuselection:`Partner --> Sales &
|
||||
Purchase Tab --> Fiscal Information`
|
||||
|
||||
.. image:: media/colombia06.png
|
||||
:align: center
|
||||
|
||||
Additionally two booleans fields were added in order to specify the
|
||||
fiscal regimen of the partner.
|
||||
|
||||
|
||||
Taxes
|
||||
~~~~~
|
||||
|
||||
If your sales transactions include products with taxes, it's important
|
||||
to consider that an extra field *Value Type* needs to be configured
|
||||
per tax. This option is located in the Advanced Options tab.
|
||||
|
||||
.. image:: media/colombia07.png
|
||||
:align: center
|
||||
|
||||
Retention tax types (ICA, IVA, Fuente) are also included in the
|
||||
options to configure your taxes. This configuration is used in order
|
||||
to correctly display taxes in the invoice PDF.
|
||||
|
||||
.. image:: media/colombia08.png
|
||||
:align: center
|
||||
|
||||
|
||||
Journals
|
||||
~~~~~~~~
|
||||
|
||||
Once the DIAN has assigned the official sequence and prefix for the
|
||||
electronic invoice resolution, the Sales journals related to your
|
||||
invoice documents need to be updated in Odoo. The sequence can be
|
||||
accessed using the :doc:`Developer mode <../../../../../applications/general/developer_mode>`: :menuselection:`Accounting -->
|
||||
Settings --> Configuration Setting --> Journals`.
|
||||
|
||||
.. image:: media/colombia09.png
|
||||
:align: center
|
||||
|
||||
Once that the sequence is opened, the Prefix and Next Number fields
|
||||
should be configured and synchronized with the CEN Financiero.
|
||||
|
||||
.. image:: media/colombia10.png
|
||||
:align: center
|
||||
|
||||
|
||||
Users
|
||||
~~~~~
|
||||
|
||||
The default template that is used by Odoo on the invoice PDF includes
|
||||
the job position of the salesperson, so these fields should be
|
||||
configured:
|
||||
|
||||
.. image:: media/colombia11.png
|
||||
:align: center
|
||||
|
||||
|
||||
Usage and testing
|
||||
=================
|
||||
|
||||
Invoice
|
||||
-------
|
||||
|
||||
When all your master data and credentials has been configured, it's
|
||||
possible to start testing the electronic invoice workflow.
|
||||
|
||||
|
||||
Invoice creation
|
||||
~~~~~~~~~~~~~~~~
|
||||
|
||||
The functional workflow that takes place before an invoice validation
|
||||
doesn't change. The main changes that are introduced with the
|
||||
electronic invoice are the next fields:
|
||||
|
||||
.. image:: media/colombia12.png
|
||||
:align: center
|
||||
|
||||
There are three types of documents:
|
||||
|
||||
- **Factura Electronica**: This is the regular type of document and
|
||||
its applicable for Invoices, Credit Notes and Debit Notes.
|
||||
- **Factura de Importación**: This should be selected for importation
|
||||
transactions.
|
||||
- **Factura de contingencia**: This is an exceptional type that is
|
||||
used as a manual backup in case that the company is not able to use
|
||||
the ERP and it's necessary to generate the invoice manually, when
|
||||
this invoice is added to the ERP, this invoice type should be
|
||||
selected.
|
||||
|
||||
|
||||
Invoice validation
|
||||
~~~~~~~~~~~~~~~~~~
|
||||
|
||||
After the invoice is validated an XML file is created and sent
|
||||
automatically to Carvajal, this file is displayed in the chatter.
|
||||
|
||||
.. image:: media/colombia13.png
|
||||
:align: center
|
||||
|
||||
An extra field is now displayed in "Other Info" tab with the name of
|
||||
the XML file. Additionally there is a second extra field that is
|
||||
displayed with the Electronic Invoice status, with the initial value
|
||||
"In progress":
|
||||
|
||||
.. image:: media/colombia14.png
|
||||
:align: center
|
||||
|
||||
|
||||
Reception of legal XML and PDF
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
The electronic invoice vendor receives the XML file and proceeds to
|
||||
validate the structure and the information in it, if everything is
|
||||
correct the invoice status changes to "Validated" after using the
|
||||
"Check Carvajal Status" button in the Action dropdown. They then
|
||||
proceed to generate a Legal XML which includes a digital signature and
|
||||
a unique code (CUFE), a PDF invoice that includes a QR code and the
|
||||
CUFE is also generated.
|
||||
|
||||
After this:
|
||||
|
||||
- A ZIP containing the legal XML and the PDF is downloaded and
|
||||
displayed in the invoice chatter:
|
||||
|
||||
.. image:: media/colombia15.png
|
||||
|
||||
.. image:: media/colombia16.png
|
||||
|
||||
- The Electronic Invoice status changes to "Accepted"
|
||||
|
||||
|
||||
Common errors
|
||||
~~~~~~~~~~~~~
|
||||
|
||||
During the XML validation the most common errors are usually related
|
||||
to missing master data. In such cases, error messages are shown in the
|
||||
chatter after updating the electronic invoice status.
|
||||
|
||||
.. image:: media/colombia17.png
|
||||
:align: center
|
||||
|
||||
After the master data is corrected, it's possible to reprocess the XML
|
||||
with the new data and send the updated version, using the following
|
||||
button:
|
||||
|
||||
.. image:: media/colombia18.png
|
||||
:align: center
|
||||
|
||||
.. image:: media/colombia19.png
|
||||
:align: center
|
||||
|
||||
|
||||
Additional use cases
|
||||
--------------------
|
||||
|
||||
The process for credit and debit notes is exactly the same as the
|
||||
invoice, the functional workflow remains the same as well.
|
||||
+595
@@ -0,0 +1,595 @@
|
||||
=============
|
||||
Colombia (ES)
|
||||
=============
|
||||
|
||||
Introducción
|
||||
============
|
||||
|
||||
La Facturación Electrónica para Colombia está disponible en Odoo 12 y
|
||||
requiere los siguientes Módulos:
|
||||
|
||||
#. **l10n_co**: Contiene los datos básicos para manejar el módulo de
|
||||
contabilidad, incluyendo la configuración por defecto de los siguientes
|
||||
puntos:
|
||||
|
||||
- Plan Contable
|
||||
- Impuestos
|
||||
- Retenciones
|
||||
- Tipos de Documentos de Identificación
|
||||
|
||||
#. **l10n_co_edi**: Este módulo incluye todos los campos adicionales que son
|
||||
requeridos para la Integración entre Carvajal T&S y la generación de la
|
||||
Factura Electrónica, basado en los requisitos legales de la DIAN.
|
||||
|
||||
|
||||
Flujo General
|
||||
=============
|
||||
|
||||
.. image:: media/colombia01.png
|
||||
:align: center
|
||||
|
||||
|
||||
Configuración
|
||||
=============
|
||||
|
||||
Instalación de los módulos de Localización Colombiana
|
||||
-----------------------------------------------------
|
||||
|
||||
Para esto ve a las aplicaciones y busca “Colombia”, luego da click en
|
||||
Instalar a los primeros dos módulos:
|
||||
|
||||
.. image:: media/colombia02.png
|
||||
:align: center
|
||||
|
||||
|
||||
Configuración de las credenciales del Servicio Web de Carvajal T&S
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
| Una vez que los módulos están instalados, para poderte conectar con el
|
||||
Servicio Web de Carvajal T&S, es necesario configurar el Usuario y las
|
||||
Credenciales. Esta información será provista por Carvajal T&S.
|
||||
| Ve a :menuselection:`Facturación --> Configuración --> Configuración` y busca la sección
|
||||
**Facturación Electrónica Colombiana**
|
||||
|
||||
.. image:: media/colombia_ES02.png
|
||||
:align: center
|
||||
|
||||
La funcionalidad de pruebas le permite conectarse e interactuar con el
|
||||
ambiente piloto de Carvajal T&S, esto permite a los usuarios probar el
|
||||
flujo completo y la integración con el Portal Financiero CEN, al cual
|
||||
se accede a través de la siguiente liga: `Cenfinanciero <https://cenfinancierolab.cen.biz>`_.
|
||||
|
||||
Una vez que el ambiente de producción está listo en Odoo y en Carvajal
|
||||
T&S el ambiente de pruebas debe ser deshabilitado para poder enviar la
|
||||
información al ambiente de producción de Carvajal, para el cual es
|
||||
utilizada la siguiente URL: `Cenfinanciero <https://cenfinancierolab.cen.biz>`_.
|
||||
|
||||
|
||||
Configuración de Información para PDF
|
||||
-------------------------------------
|
||||
|
||||
| Como parte de la información configurable que es enviada en el XML,
|
||||
puedes definir los datos de la sección fiscal del PDF, así como de la
|
||||
información Bancaria.
|
||||
| Ve a :menuselection:`Contabilidad --> Configuración --> Ajustes` y busca la sección
|
||||
**Facturación Electrónica Colombiana**.
|
||||
|
||||
.. image:: media/colombia_ES03.png
|
||||
:align: center
|
||||
|
||||
|
||||
Configuración de los Datos Principales Requeridos en el XML
|
||||
-----------------------------------------------------------
|
||||
|
||||
Contacto (Tercero)
|
||||
~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Identificación
|
||||
**************
|
||||
|
||||
Como parte de la Localización Colombiana, los tipos de documentos
|
||||
definidos por la DIAN ahora están disponibles en el formulario de
|
||||
Contactos, por lo cual ya es posible asignarles su número de
|
||||
identificación asociado al tipo de documento correspondiente.
|
||||
|
||||
.. image:: media/colombia_ES04.png
|
||||
:align: center
|
||||
|
||||
Nota: Cuando el tipo de documento es RUT la identificación necesita ser
|
||||
ingresada en Odoo incluyendo el Dígito de Verificación. Odoo separará
|
||||
este número cuando la información sea enviada a los proveedores
|
||||
terceros.
|
||||
|
||||
|
||||
Estructura Fiscal (RUT)
|
||||
***********************
|
||||
|
||||
Los Códigos de tipo de Obligación aplicables a los terceros (sección 53
|
||||
en el documento de RUT), son incluidos como parte del módulo de
|
||||
Facturación Electrónica, dado que es información requerida por la DIAN.
|
||||
|
||||
Estos campos se encuentran en :menuselection:`Contactos --> Pestaña de Ventas y Compras
|
||||
--> Información Fiscal`
|
||||
|
||||
.. image:: media/colombia_ES05.png
|
||||
:align: center
|
||||
|
||||
Adicionalmente dos últimos campos fueron agregados para especificar el
|
||||
régimen fiscal del contacto. Cabe aclarar que para envío de Factura
|
||||
electrónica de Carvajal, únicamente se hace distinción de entre Grandes
|
||||
Contribuyentes y Régimen simplificado, por lo se muestran solo estas dos
|
||||
opciones.
|
||||
|
||||
Impuestos
|
||||
~~~~~~~~~
|
||||
|
||||
Si tus transacciones de ventas incluyen productos con impuestos, es
|
||||
importante considerar que un campo adicional llamado *Tipo de Valor*
|
||||
necesita ser configurado en la siguiente ruta: :menuselection:`Contabilidad
|
||||
--> Configuración --> Impuestos: --> Opciones Avanzadas --> Tipo de Valor`
|
||||
|
||||
.. image:: media/colombia_ES06.png
|
||||
:align: center
|
||||
|
||||
Los impuestos para Retenciones (ICA, IVA y Fuente) también están
|
||||
incluidos en las opciones para configurar tus impuestos, esta
|
||||
configuración es considerada para desplegar correctamente los impuestos
|
||||
en la representación gráfica de la Factura. (PDF)
|
||||
|
||||
.. image:: media/colombia_ES07.png
|
||||
:align: center
|
||||
|
||||
|
||||
Diarios
|
||||
~~~~~~~
|
||||
|
||||
Una vez que la DIAN ha asignado la secuencia y prefijo oficiales para la
|
||||
resolución de la Facturación Electrónica, los Diarios de Ventas
|
||||
relacionados con tus documentos de facturación necesitan ser
|
||||
actualizados en Odoo.
|
||||
|
||||
La secuencia es configurada usando el modo de desarrollador en la
|
||||
siguiente ruta: :menuselection:`Contabilidad --> Configuración --> Diarios
|
||||
--> Liga de Secuencia`
|
||||
|
||||
.. image:: media/colombia_ES08.png
|
||||
:align: center
|
||||
|
||||
Una vez que la secuencia es abierta, los campos de Prefijo y Siguiente
|
||||
Número deben ser configurados y sincronizados con el CEN Financiero.
|
||||
|
||||
.. image:: media/colombia_ES09.png
|
||||
:align: center
|
||||
|
||||
|
||||
Usuarios
|
||||
~~~~~~~~
|
||||
|
||||
La plantilla por defecto que es usada por Odoo en la representación
|
||||
gráfica incluye el nombre del Vendedor, así que estos campos deben ser
|
||||
considerados:
|
||||
|
||||
.. image:: media/colombia_ES10.png
|
||||
:align: center
|
||||
|
||||
|
||||
Uso y Pruebas
|
||||
=============
|
||||
|
||||
Facturas
|
||||
--------
|
||||
|
||||
Una vez que toda la información principal y las credenciales han sido
|
||||
configuradas, es posible empezar a probar el flujo de la Facturación
|
||||
Electrónica siguiendo las instrucciones que se detallan a continuación:
|
||||
|
||||
|
||||
Invoice Creation
|
||||
~~~~~~~~~~~~~~~~
|
||||
|
||||
El flujo de trabajo funcional que lleva lugar antes de la validación de
|
||||
una factura continua siendo igual con Facturación Electrónica,
|
||||
independientemente de si es creada desde una Orden de Venta o si es
|
||||
creado manualmente.
|
||||
|
||||
Los cambios principales que son introducidos con la Facturación
|
||||
Electrónica son los siguientes:
|
||||
|
||||
Hay tres tipos de documentos
|
||||
|
||||
- **Factura electrónica**. Este es el documento normal y aplica
|
||||
para Facturas, Notas de Crédito y Notas de Débito.
|
||||
|
||||
- **Factura de Importación**. Debe ser seleccionada para
|
||||
transacciones de importación.
|
||||
|
||||
- **Factura de Contingencia**. Esta es un caso excepcional y es
|
||||
utilizada como un respaldo manual en caso que la compañía no
|
||||
pueda usar el ERP y hay necesidad de crear la factura
|
||||
manualmente. Al ingresar esta factura en el ERP, se debe
|
||||
seleccionar este tipo.
|
||||
|
||||
.. image:: media/colombia_ES11.png
|
||||
|
||||
|
||||
Invoice Validation
|
||||
~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Después que la factura fue validada, un archivo XML es creado y enviado
|
||||
automáticamente al proveedor de la factura electrónica. Este archivo es
|
||||
desplegado en el historial.
|
||||
|
||||
.. image:: media/colombia_ES12.png
|
||||
:align: center
|
||||
|
||||
Un campo adicional es ahora desplegado en la pestaña de “Otra
|
||||
Información” con el nombre del archivo XML. Adicionalmente hay un
|
||||
segundo campo adicional que es desplegado con el estatus de la Factura
|
||||
Electrónica, con el valor inicial **En Proceso**.
|
||||
|
||||
.. image:: media/colombia_ES13.png
|
||||
:align: center
|
||||
|
||||
|
||||
Recepción del XML y PDF Legal
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
| El proveedor de la Factura Electrónica recibe el archivo XML y procede
|
||||
a validar la información y la estructura contenida. Si todo es
|
||||
correcto, el estatus de la Factura cambia a “Validado”. Como parte de
|
||||
este proceso se generar el XML Legal, el cual incluye una firma
|
||||
digital y un código único (CUFE) y generan el PDF de la Factura (el
|
||||
cual incluye un código QR) y el CUFE.
|
||||
|
||||
| Odoo envía una petición de actualización automáticamente para
|
||||
verificar que el XML fue creado. Si este es el caso, las siguientes
|
||||
acciones son hechas automáticamente:
|
||||
|
||||
- El XML Legal y el PDF son incluidos en un archivo ZIP y desplegados
|
||||
en el historial de la Factura.
|
||||
|
||||
.. image:: media/colombia_ES14.png
|
||||
|
||||
- El estatus de la Factura Electrónica es cambiado a “Aceptado”.
|
||||
|
||||
.. image:: media/colombia_ES15.png
|
||||
|
||||
.. tip::
|
||||
En caso que el PDF y el XML sean requeridos inmediatamente, es
|
||||
posible mandar manualmente la petición del estatus usando el siguiente
|
||||
botón:
|
||||
|
||||
.. image:: media/colombia_ES16.png
|
||||
:align: center
|
||||
|
||||
|
||||
Errores Frecuentes
|
||||
~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Durante la validación del XML los errores más comunes usualmente están
|
||||
relacionados con información principal faltante. En estos casos, los
|
||||
detalles del error son recuperados en la petición de actualización y
|
||||
desplegados en el historial.
|
||||
|
||||
.. image:: media/colombia_ES17.png
|
||||
:align: center
|
||||
|
||||
Si la información principal es corregida, es posible re procesar el XML
|
||||
con la nueva información y mandar la versión actualizada usando el
|
||||
siguiente botón:
|
||||
|
||||
.. image:: media/colombia_ES18.png
|
||||
:align: center
|
||||
|
||||
.. image:: media/colombia_ES19.png
|
||||
:align: center
|
||||
|
||||
|
||||
Casos de Uso adicionales
|
||||
------------------------
|
||||
|
||||
El proceso para las Notas de Crédito y Débito (Proveedores) es
|
||||
exactamente el mismo que en las Facturas. Su flujo de trabajo funcional
|
||||
se mantiene igual.
|
||||
|
||||
Consideraciones del Anexo 1.7
|
||||
=============================
|
||||
|
||||
Contexto
|
||||
--------
|
||||
|
||||
Contexto Normativo
|
||||
~~~~~~~~~~~~~~~~~~
|
||||
|
||||
| Soporte Normativo:
|
||||
| Resolución DIAN Número 000042 ( 5 de Mayo de 2020) Por la cual se desarrollan:
|
||||
|
||||
- Los sistemas de facturación,
|
||||
- Los proveedores tecnológicos,
|
||||
- El registro de la factura electrónica de venta como título valor,
|
||||
- Se expide el anexo técnico de factura electrónica de venta y
|
||||
- Se dictan otras disposiciones en materia de sistemas de facturación.
|
||||
|
||||
Anexo 1.7: Principales Cambios
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
- Cambios en la definición de Consumidor Final.
|
||||
- Informar bienes cubiertos para los 3 dias sin IVA.
|
||||
- Actualización de descripción de Impuestos.
|
||||
- Se agrega concepto para IVA Excluido.
|
||||
- Informar la fecha efectiva de entrega de los bienes.
|
||||
- Adecuaciones en la representación Gráfica (PDF).
|
||||
|
||||
Calendario
|
||||
~~~~~~~~~~
|
||||
|
||||
Se tiene varias fechas límites para la salida a producción bajo las condiciones del Anexo 1.7 las
|
||||
cuales dependen de los siguientes factores:
|
||||
|
||||
#. Calendario de implementación de acuerdo con la actividad económica principal en el RUT:
|
||||
|
||||
.. image:: media/colombia-es-calendario-rut.png
|
||||
:align: center
|
||||
|
||||
#. Calendario de implementación, para otros sujetos obligados:
|
||||
|
||||
.. image:: media/colombia-es-calendario-otros-obligados.png
|
||||
:align: center
|
||||
|
||||
#. Calendario de implementación permanente:
|
||||
|
||||
.. image:: media/colombia-es-calendario-permanente.png
|
||||
:align: center
|
||||
|
||||
Requerimientos en Odoo
|
||||
----------------------
|
||||
|
||||
Con la finalidad de facilitar el proceso de preparación de las bases de Odoo estándar V12 y v13,
|
||||
únicamente será necesario que los administradores actualicen algunos módulos y creen los datos
|
||||
maestros relacionados a los nuevos procesos.
|
||||
|
||||
Actualización de listado de Apps
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Utilizando el modo desarrollador, acceder al módulo de Aplicaciones y seleccionar el menú
|
||||
*Actualizar Lista*.
|
||||
|
||||
.. image:: media/colombia-es-actualizar-lista.png
|
||||
:align: center
|
||||
|
||||
Actualización de Módulos
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Una vez actualizado Buscar *Colombia*, los siguientes módulos serán desplegados, se requieren
|
||||
actualizar dos módulos.
|
||||
|
||||
#. Colombia - Contabilidad - l10n_co
|
||||
#. Electronic invoicing for Colombia with Carvajal UBL 2.1 - l10n_co_edi_ubl_2_1
|
||||
|
||||
.. image:: media/colombia-es-modulos.png
|
||||
:align: center
|
||||
|
||||
En cada módulo o ícono hay que desplegar el menú opciones utilizando los 3 puntos de la esquina
|
||||
superior derecha y seleccionamos *Actualizar*.
|
||||
|
||||
Primero lo hacemos con en el módulo l10n_co:
|
||||
|
||||
.. image:: media/colombia-es-actualizar-contabilidad.png
|
||||
:align: center
|
||||
|
||||
Posteriormente lo hacemos con el módulo l10n_co_edi_ubl_2_1:
|
||||
|
||||
.. image:: media/colombia-es-actualizar-electronic-invoicing.png
|
||||
:align: center
|
||||
|
||||
Creación de Datos Maestros
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Las bases de datos existentes a Junio 2020 tanto en V12 como V13, deberán crear algunos datos
|
||||
maestros necesarios para operar correctamente con los cambios del Anexo 1.7.
|
||||
|
||||
Consumidor Final
|
||||
****************
|
||||
|
||||
La figura del consumidor final será utilizada para aquellas ventas sobre las cuales no es posible
|
||||
identificar toda la información fiscal y demográfica del cliente por lo que la factura se genera a
|
||||
nombre de este registro genérico.
|
||||
|
||||
Es importante coordinar y definir los casos de uso en los que dependiendo de su empresa se tendrá
|
||||
permitido utilizar este registro genérico.
|
||||
|
||||
Dentro de Odoo se tendrá que crear un contacto con las siguientes características, es importante que
|
||||
se defina de esta manera debido a que son los parámetros definidos por la DIAN.
|
||||
|
||||
- **Tipo de contacto:** Individuo
|
||||
- **Nombre:** Consumidor Final
|
||||
- **Tipo de documento:** Cedula de Ciudadania
|
||||
- **Numero de Identificacion:** 222222222222
|
||||
|
||||
.. image:: media/colombia-es-consumidor-final-nuevo-contacto.png
|
||||
:align: center
|
||||
|
||||
Dentro de la pestaña Ventas y Compras, en la sección Información Fiscal, del campo Obligaciones y
|
||||
Responsabilidades colocaremos el valor: **R-99-PN**.
|
||||
|
||||
.. image:: media/colombia-es-consumidor-final-r-99-pn.png
|
||||
:align: center
|
||||
|
||||
IVA Excluido - Bienes Cubiertos
|
||||
*******************************
|
||||
|
||||
Para reportar las transacciones realizadas mediante Bienes Cubiertos para los tres días sin IVA,
|
||||
será necesario crear un nuevo Impuesto al cual se le debe de asociar un grupo de impuestos
|
||||
específico que será utilizado por Odoo para agregar la sección requerida en el XML de factura
|
||||
electrónica.
|
||||
|
||||
Para el crear el impuesto accederemos a Contabilidad dentro del menú :menuselection:`Configuración
|
||||
--> Impuestos`:
|
||||
|
||||
.. image:: media/colombia-es-menu-impuestos.png
|
||||
:align: center
|
||||
|
||||
Procedemos a crear un nuevo Impuesto con importe 0% considerando los siguientes parámetros:
|
||||
|
||||
.. image:: media/colombia-es-nuevo-impuesto.png
|
||||
:align: center
|
||||
|
||||
El nombre del Impuesto puede ser definido a preferencia del usuario, sin embargo el campo clave es
|
||||
**Grupo de Impuestos** dentro de Opciones avanzadas, el cual debe ser: *bienes cubiertos* y el campo
|
||||
**Tipo de Valor**: *IVA*.
|
||||
|
||||
.. image:: media/colombia-es-nuevo-impuesto-opciones-avanzadas.png
|
||||
:align: center
|
||||
|
||||
Actualización de descripción de Departamentos
|
||||
*********************************************
|
||||
|
||||
Es necesario actualizar la descripción de algunos departamentos, para lo cual accederemos a módulo
|
||||
de Contactos y dentro del menú de :menuselection:`Configuración --> Provincias`.
|
||||
|
||||
.. image:: media/colombia-es-menu-provincias.png
|
||||
:align: center
|
||||
|
||||
Posteriormente, podemos agregar por País para identificar claramente las provincias (Departamentos)
|
||||
de Colombia:
|
||||
|
||||
.. image:: media/colombia-es-provincias-agrupar.png
|
||||
:align: center
|
||||
|
||||
Una vez agrupados buscar los siguientes departamentos para actualizarlos con el valor indicado en la
|
||||
columna **Nombre actualizado**:
|
||||
|
||||
+------------------------------+---------------------+--------------------------+
|
||||
| Nombre de provincia | Código de Provincia | Nombre actualizado |
|
||||
+==============================+=====================+==========================+
|
||||
| D.C. | DC | Bogotá |
|
||||
+------------------------------+---------------------+--------------------------+
|
||||
| Quindio | QUI | Quindío |
|
||||
+------------------------------+---------------------+--------------------------+
|
||||
| Archipiélago de San Andrés, | SAP | San Andrés y Providencia |
|
||||
| Providencia y Santa Catalina | | |
|
||||
+------------------------------+---------------------+--------------------------+
|
||||
|
||||
Ejemplo:
|
||||
|
||||
.. image:: media/colombia-es-provincias-ejemplo.png
|
||||
:align: center
|
||||
|
||||
Verificación de Código postal
|
||||
*****************************
|
||||
|
||||
Dentro del Anexo 1.7 se comienza a validar que el código postal de las direcciones para contactos
|
||||
colombianos corresponda a las tablas oficiales definidas por la DIAN, por lo que se debe verificar
|
||||
que este campo está debidamente diligenciado de acuerdo a los definidos en la sigueinte fuente:
|
||||
`Codigos_Postales_Nacionales.csv
|
||||
<http://visor.codigopostal.gov.co/472/visor/Codigos_Postales_Nacionales.csv>`_
|
||||
|
||||
Consideraciones Operativas
|
||||
--------------------------
|
||||
|
||||
Consumidor Final
|
||||
~~~~~~~~~~~~~~~~
|
||||
|
||||
Una vez que resgistro de Consumidor final ha sido creado este deberá ser utilizado a demanda,
|
||||
generalmente será utilizado en las transacciones de facturación del punto de punto de venta.
|
||||
|
||||
- El proceso de validación de la Factura será realizado de forma convencional en Odoo y la factura
|
||||
será generada de la misma manera. Al detectar que el número de identificación corresponde a
|
||||
consumidor Final, el XML que se envía a Carvajal será generado con las consideraciones y secciones
|
||||
correspondientes.
|
||||
- Contablemente todos los registros de Consumidor final quedarán asociados al identificador generico:
|
||||
|
||||
.. image:: media/colombia-es-consumidor-final-asociado.png
|
||||
:align: center
|
||||
|
||||
IVA Excluido - Bienes Cubiertos
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
El 21 mayo del 2020 fue publicado el El Decreto 682 el cual establece Excepción especial en el
|
||||
Impuesto sobre las ventas. El principal objetivo de este decreto es reactivar la economía en
|
||||
Colombia por las bajas ventas generadas a causa del COVID.
|
||||
|
||||
Fechas
|
||||
******
|
||||
|
||||
Días de excención del impuesto sobre las ventas – IVA para bienes cubiertos (3 días SIN IVA).
|
||||
|
||||
- **Primer día**: 19 de junio de 2020
|
||||
- **Segundo día**: 3 de Julio de 2020
|
||||
- **Tercer día**: 19 de Julio de 2020
|
||||
|
||||
Condiciones
|
||||
***********
|
||||
|
||||
Debido a que estas transacciones serán generadas de forma excepcional y que se tiene una combinación
|
||||
de varios factores y condiciones, los productores debera ser actualizados de forma manual en Odoo
|
||||
asignados temporalmente el impuesto de venta *IVA exento - Bienes cubierto* en cada empresa según
|
||||
corresponda.
|
||||
|
||||
A continuación se mencionan algunas de las principales condiciones, sin embargo, cabe mencionar que
|
||||
las empresas deben de verificar todos los detalles en el `Decreto 682
|
||||
<https://dapre.presidencia.gov.co/normativa/normativa/DECRETO%20682%20DEL%2021%20DE%20MAYO%20DE%202020.pdf>`_.
|
||||
|
||||
- Tipo de productos y precio Máximo:
|
||||
|
||||
+-----------------------------+---------------------------------------+
|
||||
| Tipo de Productos | Precio Máximo |
|
||||
+=============================+=======================================+
|
||||
| Electrodomesticos | 40 UVT: $1,4 millones. |
|
||||
+-----------------------------+---------------------------------------+
|
||||
| Vestuario y complementos | | 3 UVT: $106.000 |
|
||||
| | | En el caso de los complementos es: |
|
||||
| | | 10 UVT- $356.000 |
|
||||
+-----------------------------+---------------------------------------+
|
||||
| Elementos deportivos | 10 UVT- $356.000 |
|
||||
+-----------------------------+---------------------------------------+
|
||||
| Juguetes y Utiles Escolares | 5 UVT - $178.035 |
|
||||
+-----------------------------+---------------------------------------+
|
||||
| Utiles Escolares | 5 UVT - $178.035 |
|
||||
+-----------------------------+---------------------------------------+
|
||||
| Bienes o servicios para | 80 UVT - $2.848.560 |
|
||||
| el sector agropecuario | |
|
||||
+-----------------------------+---------------------------------------+
|
||||
|
||||
- Métodos de Pago:
|
||||
|
||||
- El pago debe realizarse por medios electrónico por ejemplo tarjetas de crédito/débito o bien mecanismos de pago online.
|
||||
|
||||
- Limite de unidades:
|
||||
|
||||
- Cada cliente puede adquirir únicamente 3 unidades como máximo de cada producto.
|
||||
|
||||
Medidas en Odoo
|
||||
***************
|
||||
|
||||
- **Preparación de datos**
|
||||
|
||||
- Crear el Impuesto para Bienes cubiertos de acuerdo a lo indicado en este punto: Datos maestros.
|
||||
- Identificar los productos y transacciones a los cuales les aplicará la Exclusión de IVA de
|
||||
acuerdo a las condiciones establecidas en el decreto 682. En caso de ser un porcentaje
|
||||
significativo de productos, se recomienda actualizar el impuesto de forma temporal en Odoo.
|
||||
- Exportar un listado con los productos que serán afectados incluyendo el campo IVA Venta el cual
|
||||
será sustituido temporalmente por el IVA de Bienes Cubiertos.
|
||||
- Al finalizar las operaciones del día anterior a las fechas establecidas de día sin IVA, se debe
|
||||
hacer la actualización temporal a IVA de Bienes Cubiertos.
|
||||
|
||||
.. image:: media/columbia-es-producto-iva-bienes-cubiertos.png
|
||||
:align: center
|
||||
|
||||
- **Durante el día SIN IVA**
|
||||
|
||||
- Por defecto los productos previamente considerados con IVA de Bienes cubiertos serán generados
|
||||
con este parámetro tanto en Órdenes de venta como facturas creadas durante ese mismo día.
|
||||
|
||||
.. image:: media/columbia-es-factura-iva-bienes-cubiertos.png
|
||||
:align: center
|
||||
|
||||
- Las órdenes de venta generadas con este impuesto deberán ser facturas el mismo día.
|
||||
- En caso de que alguna de las condiciones no sea cumplida (ejemplo el pago es realizado en
|
||||
efectivo) el impuesto deberá ser actualizado manualmente al momento de facturar.
|
||||
|
||||
- **Posterior al día SIN IVA**
|
||||
|
||||
- Los productos que fueron actualizados deberá ser reconfigurados a su IVA original.
|
||||
- En caso de que se detecte alguna Orden de venta facturar en la cual se incluya IVA de Bienes
|
||||
Cubiertos, se deberá realizar actualización manual correspondiente al IVA convencional.
|
||||
BIN
Binary file not shown.
BIN
Binary file not shown.
+184
@@ -0,0 +1,184 @@
|
||||
======
|
||||
France
|
||||
======
|
||||
|
||||
FEC
|
||||
===
|
||||
|
||||
If you have installed the French Accounting, you will be able to download the FEC.
|
||||
For this, go in :menuselection:`Accounting --> Reporting --> France --> FEC`.
|
||||
|
||||
.. tip::
|
||||
If you do not see the submenu **FEC**, go in **Apps** and search for the module
|
||||
called **France-FEC** and verify if it is well installed.
|
||||
|
||||
French Accounting Reports
|
||||
=========================
|
||||
|
||||
If you have installed the French Accounting, you will have access to some accounting reports specific to France:
|
||||
|
||||
- Bilan comptable
|
||||
- Compte de résultats
|
||||
- Plan de Taxes France
|
||||
|
||||
Get the VAT anti-fraud certification with Odoo
|
||||
==============================================
|
||||
|
||||
As of January 1st 2018, a new anti-fraud legislation comes into effect
|
||||
in France and DOM-TOM. This new legislation stipulates certain criteria
|
||||
concerning the inalterability, security, storage and archiving of sales data.
|
||||
These legal requirements are implemented in Odoo, version 9 onward,
|
||||
through a module and a certificate of conformity to download.
|
||||
|
||||
Is my company required to use an anti-fraud software?
|
||||
-----------------------------------------------------
|
||||
|
||||
Your company is required to use an anti-fraud cash register software like
|
||||
Odoo (CGI art. 286, I. 3° bis) if:
|
||||
|
||||
* You are taxable (not VAT exempt) in France or any DOM-TOM,
|
||||
* Some of your customers are private individuals (B2C).
|
||||
|
||||
This rule applies to any company size. Auto-entrepreneurs are exempted from
|
||||
VAT and therefore are not affected.
|
||||
|
||||
Get certified with Odoo
|
||||
-----------------------
|
||||
|
||||
Getting compliant with Odoo is very easy.
|
||||
|
||||
Your company is requested by the tax administration to deliver a certificate
|
||||
of conformity testifying that your software complies with the anti-fraud
|
||||
legislation. This certificate is granted by Odoo SA to Odoo Enterprise users
|
||||
`here <https://www.odoo.com/my/contract/french-certification/>`_.
|
||||
If you use Odoo Community, you should
|
||||
`upgrade to Odoo Enterprise <https://www.odoo.com/documentation/13.0/setup/enterprise.html>`_
|
||||
or contact your Odoo service provider.
|
||||
|
||||
In case of non-conformity, your company risks a fine of €7,500.
|
||||
|
||||
To get the certification just follow the following steps:
|
||||
|
||||
* Install the anti-fraud module fitting your Odoo environment from the
|
||||
*Apps* menu:
|
||||
|
||||
* if you use Odoo Point of Sale: *l10n_fr_pos_cert*: France - VAT Anti-Fraud Certification for Point of Sale (CGI 286 I-3 bis)
|
||||
* in any other case: *l10n_fr_certification*: France - VAT Anti-Fraud Certification (CGI 286 I-3 bis)
|
||||
|
||||
* Make sure a country is set on your company, otherwise your entries won’t be
|
||||
encrypted for the inalterability check. To edit your company’s data,
|
||||
go to :menuselection:`Settings --> Users & Companies --> Companies`.
|
||||
Select a country from the list; Do not create a new country.
|
||||
* Download the mandatory certificate of conformity delivered by Odoo SA `here <https://www.odoo.com/my/contract/french-certification/>`__.
|
||||
|
||||
.. note::
|
||||
* To install the module in any system created before
|
||||
December 18th 2017, you should update the modules list.
|
||||
To do so, activate the :doc:`Developer mode <../../../../../applications/general/developer_mode>`.
|
||||
Then go to the *Apps* menu and press *Update Modules List* in the top-menu.
|
||||
* In case you run Odoo on-premise, you need to update your installation
|
||||
and restart your server beforehand.
|
||||
* If you have installed the initial version of the anti-fraud module
|
||||
(prior to December 18th 2017), you need to update it.
|
||||
The module's name was *France - Accounting - Certified CGI 286 I-3 bis*.
|
||||
After an update of the modules list, search for
|
||||
the updated module in *Apps*, select it and click *Upgrade*.
|
||||
Finally, make sure the following module *l10n_fr_sale_closing*
|
||||
is installed.
|
||||
|
||||
Anti-fraud features
|
||||
-------------------
|
||||
|
||||
The anti-fraud module introduces the following features:
|
||||
|
||||
* **Inalterability**: deactivation of all the ways to cancel or modify
|
||||
key data of POS orders, invoices and journal entries;
|
||||
* **Security**: chaining algorithm to verify the inalterability;
|
||||
* **Storage**: automatic sales closings with computation of both period
|
||||
and cumulative totals (daily, monthly, annually).
|
||||
|
||||
Inalterability
|
||||
~~~~~~~~~~~~~~
|
||||
|
||||
All the possible ways to cancel and modify key data of paid POS orders,
|
||||
confirmed invoices and journal entries are deactivated,
|
||||
if the company is located in France or in any DOM-TOM.
|
||||
|
||||
.. note:: If you run a multi-companies environment, only the documents of
|
||||
such companies are impacted.
|
||||
|
||||
Security
|
||||
~~~~~~~~
|
||||
|
||||
To ensure the inalterability, every order or journal entry is encrypted
|
||||
upon validation.
|
||||
This number (or hash) is calculated from the key data of the document as
|
||||
well as from the hash of the precedent documents.
|
||||
|
||||
The module introduces an interface to test the data inalterability.
|
||||
If any information is modified on a document after its validation,
|
||||
the test will fail. The algorithm recomputes all the hashes and compares them
|
||||
against the initial ones. In case of failure, the system points out the first
|
||||
corrupted document recorded in the system.
|
||||
|
||||
Users with *Manager* access rights can launch the inalterability check.
|
||||
For POS orders, go to
|
||||
:menuselection:`Point of Sales --> Reporting --> French Statements`.
|
||||
For invoices or journal entries,
|
||||
go to :menuselection:`Invoicing/Accounting --> Reporting --> French Statements`.
|
||||
|
||||
Storage
|
||||
~~~~~~~
|
||||
|
||||
The system also processes automatic sales closings on a daily, monthly
|
||||
and annual basis.
|
||||
Such closings distinctly compute the sales total of the period as well as
|
||||
the cumulative grand totals from the very first sales entry recorded
|
||||
in the system.
|
||||
|
||||
Closings can be found in the *French Statements* menu of Point of Sale,
|
||||
Invoicing and Accounting apps.
|
||||
|
||||
.. note::
|
||||
* Closings compute the totals for journal entries of sales journals (Journal Type = Sales).
|
||||
|
||||
* For multi-companies environments, such closings are performed by company.
|
||||
|
||||
* POS orders are posted as journal entries at the closing of the POS session.
|
||||
Closing a POS session can be done anytime.
|
||||
To prompt users to do it on a daily basis, the module prevents from resuming
|
||||
a session opened more than 24 hours ago.
|
||||
Such a session must be closed before selling again.
|
||||
|
||||
* A period’s total is computed from all the journal entries posted after the
|
||||
previous closing of the same type, regardless of their posting date.
|
||||
If you record a new sales transaction for a period already closed,
|
||||
it will be counted in the very next closing.
|
||||
|
||||
.. tip:: For test & audit purposes such closings can be manually generated in the
|
||||
:doc:`Developer mode <../../../../../applications/general/developer_mode>`. Then go to
|
||||
:menuselection:`Settings --> Technical --> Automation --> Scheduled Actions`.
|
||||
|
||||
|
||||
Responsibilities
|
||||
----------------
|
||||
|
||||
Do not uninstall the module! If you do so, the hashes will be reset and none
|
||||
of your past data will be longer guaranteed as being inalterable.
|
||||
|
||||
Users remain responsible for their Odoo instance and must use it with
|
||||
due diligence. It is not permitted to modify the source code which guarantees
|
||||
the inalterability of data.
|
||||
|
||||
Odoo absolves itself of all and any responsibility in case of changes
|
||||
in the module’s functions caused by 3rd party applications not certified by Odoo.
|
||||
|
||||
|
||||
More Information
|
||||
----------------
|
||||
|
||||
You will find more information about this legislation in the official documents:
|
||||
|
||||
* `Frequently Asked Questions <https://www.economie.gouv.fr/files/files/directions_services/dgfip/controle_fiscal/actualites_reponses/logiciels_de_caisse.pdf>`_
|
||||
* `Official Statement <http://bofip.impots.gouv.fr/bofip/10691-PGP.html?identifiant=BOI-TVA-DECLA-30-10-30-20160803>`_
|
||||
* `Item 88 of Finance Law 2016 <https://www.legifrance.gouv.fr/affichTexteArticle.do?idArticle=JORFARTI000031732968&categorieLien=id&cidTexte=JORFTEXT000031732865>`_
|
||||
+201
@@ -0,0 +1,201 @@
|
||||
=======
|
||||
Germany
|
||||
=======
|
||||
|
||||
German Chart of Accounts
|
||||
========================
|
||||
|
||||
The chart of accounts SKR03 and SKR04 are both supported in Odoo. You can choose the
|
||||
one you want by going in :menuselection:`Accounting --> Configuration` then choose the
|
||||
package you want in the Fiscal Localization section.
|
||||
|
||||
Be careful, you can only change the accounting package as long as you have not created any accounting entry.
|
||||
|
||||
.. tip::
|
||||
|
||||
When you create a new SaaS database, the SKR03 is installed by default.
|
||||
|
||||
German Accounting Reports
|
||||
=========================
|
||||
|
||||
Here is the list of German-specific reports available on Odoo Enterprise:
|
||||
|
||||
- Balance Sheet
|
||||
- Profit & Loss
|
||||
- Tax Report (Umsatzsteuervoranmeldung)
|
||||
- Partner VAT Intra
|
||||
|
||||
Export from Odoo to Datev
|
||||
=========================
|
||||
|
||||
It is possible to export your accounting entries from Odoo to Datev. To be able to use this
|
||||
feature, the german accounting localization needs to be installed on your Odoo Enterprise database.
|
||||
Then you can go in :menuselection:`Accounting --> Reporting --> General Ledger` then click on the
|
||||
**Export Datev (csv)** button.
|
||||
|
||||
.. _germany/gobd:
|
||||
|
||||
German Tax Accounting Standards: Odoo's guide to GoBD Compliance
|
||||
================================================================
|
||||
|
||||
**GoBD** stands for `Grundsätze zur ordnungsmäßigen Führung und Aufbewahrung von Büchern,
|
||||
Aufzeichnungen und Unterlagen in elektronischer Form sowie zum Datenzugriff
|
||||
<https://www.bundesfinanzministerium.de/Content/DE/Downloads/BMF_Schreiben/Weitere_Steuerthemen/Abgabenordnung/2019-11-28-GoBD.pdf>`_.
|
||||
In short, it is a **guideline for the proper management and storage of books, records, and documents
|
||||
in electronic form, as well as for data access**, that is relevant for the German tax authority, tax
|
||||
declaration, and balance sheet.
|
||||
|
||||
These principles have been written and published by the Federal Ministry of Finance (BMF) in
|
||||
November 2014. Since January 2015, **they have become the norm** and replace previously accepted
|
||||
practices linked to computer-based accounting. Several changes have been made by the BMF in 2019 and
|
||||
January 2020 to specify some of the content and due to the development of digital solutions (cloud
|
||||
hosting, paperless companies, etc.).
|
||||
|
||||
.. important::
|
||||
Odoo gives you **the means to be compliant with GoBD**.
|
||||
|
||||
What do you need to know about GoBD when relying on accounting software?
|
||||
------------------------------------------------------------------------
|
||||
|
||||
.. note::
|
||||
If you can, the best way to understand GoBD is to Read the `Official GoBD text
|
||||
<https://www.bundesfinanzministerium.de/Content/DE/Downloads/BMF_Schreiben/Weitere_Steuerthemen/Abgabenordnung/2019-11-28-GoBD.pdf>`_.
|
||||
It is a bit long but quite readable for non-experts. But in short, here is what to expect:
|
||||
|
||||
The **GoBD is binding for companies that have to present accounts, which includes SMEs, freelancers,
|
||||
and entrepreneurs, to the financial authorities**. As such, **the taxpayer himself is the sole
|
||||
responsible** for the complete and exhaustive keeping of fiscal-relevant data (above-mentioned
|
||||
financial and related data).
|
||||
|
||||
Apart from software requirements, the user is required to ensure Internal control systems (*in
|
||||
accordance with sec. 146 of the Fiscal Code*):
|
||||
|
||||
- Access rights control;
|
||||
- Segregation of Duties, Functional separating;
|
||||
- Entry controls (error notifications, plausibility checks);
|
||||
- Reconciliation checks at data entry;
|
||||
- Processing controls;
|
||||
- Measures to prevent intentional or unintentional manipulation of software, data, or documents.
|
||||
|
||||
The user must distribute tasks within its organization to the relevant positions (*control*) and
|
||||
verify that the tasks are properly and completely performed (*supervision*). The result of these
|
||||
controls must be recorded (*documentation*), and should errors be found during these controls,
|
||||
appropriate measures to correct the situation should be put into place (*prevention*).
|
||||
|
||||
What about data security?
|
||||
-------------------------
|
||||
|
||||
**The taxpayer must secure the system against any data loss due to deletion, removal, or theft of
|
||||
any data**. If the entries are not sufficiently secured, the bookkeeping will be regarded as not in
|
||||
accordance with the GoBD guidelines.
|
||||
|
||||
Once bookings have been finally posted, they can no longer be changed or deleted via the
|
||||
application.
|
||||
|
||||
- If Odoo is used in the cloud, regular backups are part of the SaaS service. In addition, regular
|
||||
backups can be downloaded and backed up on external systems.
|
||||
|
||||
.. seealso::
|
||||
`Odoo Cloud Hosting - Service Level Agreement <https://www.odooo.com/cloud-sla>`_
|
||||
|
||||
- If the server is operated locally, it is the responsibility of the user to create the necessary
|
||||
backup infrastructure.
|
||||
|
||||
.. important::
|
||||
In some cases, data has to be kept for ten years or more, so always have backups saved. It is
|
||||
even more important if you decide to change software provider.
|
||||
|
||||
Responsibility of the software editor
|
||||
-------------------------------------
|
||||
|
||||
Considering GoBD only applies between the taxpayer and the financial authority, **the software
|
||||
editor can by no means be held responsible for the accurate and compliant documentation of financial
|
||||
transactional data of their users**. It can merely provide the necessary tools for the user to
|
||||
respect the software related guidelines described in the GoBD.
|
||||
|
||||
How can Odoo help you achieve Compliance?
|
||||
-----------------------------------------
|
||||
|
||||
The key words, when it comes to GoBD, are: **traceable, verifiable, true, clear, and continuous**.
|
||||
In short, you need to have audit-proof archiving in place and Odoo provides you with the means to
|
||||
achieve all of these objectives:
|
||||
|
||||
#. | **Traceability and verifiability**
|
||||
| Each record in Odoo is stamped with the creator of the document, the creation date, the
|
||||
modification date, and who modified it. In addition, relevant fields are tracked thus it can be
|
||||
seen which value was changed by whom in the chatter of the relevant object.
|
||||
#. | **Completeness**
|
||||
| All financial data must be recorded in the system, and there can be no gaps. Odoo ensures that
|
||||
there is no gap in the numbering of the financial transactions. It is the responsibility of the
|
||||
user to encode all financial data in the system. As most financial data in Odoo is generated
|
||||
automatically, it remains the responsibility of the user to encode all vendor bills and
|
||||
miscellaneous operations completely.
|
||||
#. | **Accuracy**
|
||||
| Odoo ensures with the correct configuration that the correct accounts are used. In addition,
|
||||
the control mechanisms between purchase orders and sales orders and their respective invoices
|
||||
reflect the business reality. It is the responsibility of the user to scan and attach the
|
||||
paper-based vendor bill to the respective record in Odoo. *Odoo Document helps you automate
|
||||
this task*.
|
||||
#. | **Timely booking and record-keeping**
|
||||
| As most financial data in Odoo is generated by the transactional objects (for example, the
|
||||
invoice is booked at confirmation), Odoo ensures out-of-the-box timely record-keeping. It is
|
||||
the responsibility of the user to encode all incoming vendor bills in a timely manner, as well
|
||||
as the miscellaneous operations.
|
||||
#. | **Order**
|
||||
| Financial data stored in Odoo is per definition ordered and can be reordered according to most
|
||||
fields present in the model. A specific ordering is not enforced by the GoBD, but the system
|
||||
must ensure that a given financial transaction can be quickly found by a third-party expert.
|
||||
Odoo ensures this out-of-the-box.
|
||||
#. | **Inalterability**
|
||||
| With the German Odoo localization, Odoo is in standard configured in such a way that the
|
||||
inalterability clause can be adhered to without any further customization.
|
||||
|
||||
Do you need a GoBD-Export?
|
||||
--------------------------
|
||||
|
||||
In the case of fiscal control, the fiscal authority can request three levels of access to the
|
||||
accounting system (Z1, Z2, Z3). These levels vary from direct access to the interface to the
|
||||
handover of the financial data on a storage device.
|
||||
|
||||
In case of a handover of the financial data on a storage device, the format is **not** enforced by
|
||||
the GoBD. It can be, for example, in XLS, CSV, XML, Lotus 123, SAP-format, AS/400-format, or else.
|
||||
Odoo supports the CSV and XLS-export of financial data out-of-the-box. The GoBD **recommends** the
|
||||
export in a specific XML-based GoBD-format (see "Ergänzende Informationen zur
|
||||
Datenntträgerüberlassung" §3) but it is not binding.
|
||||
|
||||
What is the role and meaning of the compliance certification?
|
||||
-------------------------------------------------------------
|
||||
|
||||
The GoBD clearly states that due to the nature of a state of the art accounting software, their
|
||||
configuration possibilities, changing nature, and various forms of use, **no legally binding
|
||||
certification can be given**, nor can the software be made liable towards a public authority.
|
||||
Third-party certificates can indeed have **an informative value** for customers to make software
|
||||
buying decisions but are by no means legally binding or of any other legal value (A. 12, § 181).
|
||||
|
||||
A GoBD certificate states nothing more than that if you use the software according to its
|
||||
guidelines, the software will not refrain you from respecting the GoBD. These certifications are
|
||||
very expensive in terms of time and cost, and their value is very relative. Thus we focus our
|
||||
efforts on ensuring GoBD compliance rather than pay for a marketing tool which does not, however,
|
||||
offer our customer any legal certainty.
|
||||
|
||||
.. important::
|
||||
The BMF actually states the following in the `Official GoBD text
|
||||
<https://www.bundesfinanzministerium.de/Content/DE/Downloads/BMF_Schreiben/Weitere_Steuerthemen/Abgabenordnung/2019-11-28-GoBD.pdf>`_:
|
||||
|
||||
- 180. Positive attestations on the correctness of the bookkeeping - and thus on the correctness
|
||||
of IT-based bookkeeping systems - are not issued either in the context of a tax field audit or
|
||||
in the context of binding information.
|
||||
- 181. "Certificates" or "attestations" from third parties can serve as a decision criterion for
|
||||
the company when selecting a software product, but develop from the in margin no. 179 is not
|
||||
binding on the tax authorities.
|
||||
|
||||
.. note::
|
||||
The previous content was `automatically translated from German with Google Translate
|
||||
<https://translate.google.com/?sl=de&tl=en&text=180.%0APositivtestate%20zur%20Ordnungsm%C3%A4%C3%9Figkeit%20der%20Buchf%C3%BChrung%20-%20und%20damit%20zur%20Ordnungsm%C3%A4%C3%9Figkeit%20DV-gest%C3%BCtzter%20Buchf%C3%BChrungssysteme%20-%20werden%20weder%20im%20Rahmen%20einer%20steuerlichen%20Au%C3%9Fenpr%C3%BCfung%20noch%20im%20Rahmen%20einer%20verbindlichen%20Auskunft%20erteilt.%0A%0A181.%0A%E2%80%9EZertifikate%E2%80%9C%20oder%20%E2%80%9ETestate%E2%80%9C%20Dritter%20k%C3%B6nnen%20bei%20der%20Auswahl%20eines%20Softwareproduktes%20dem%20Unternehmen%20als%20Entscheidungskriterium%20dienen%2C%20entfalten%20jedoch%20aus%20den%20in%20Rz.%20179%20genannten%20Gr%C3%BCnden%20gegen%C3%BCber%20der%20Finanzbeh%C3%B6rde%20keine%20Bindungswirkung.%20&op=translate>`_.
|
||||
|
||||
|
||||
What happens if you are not compliant?
|
||||
--------------------------------------
|
||||
|
||||
In the event of an infringement, you can expect a fine but also a court order demanding the
|
||||
implementation of specific measures.
|
||||
+128
@@ -0,0 +1,128 @@
|
||||
=========
|
||||
Indonesia
|
||||
=========
|
||||
|
||||
.. _localization_indonesia/e-faktur:
|
||||
|
||||
E-Faktur Module
|
||||
===============
|
||||
|
||||
The **E-Faktur Module** is installed by default with the Indonesian localization module. It allows
|
||||
one to generate a CSV file for one tax invoice or for a batch of tax invoices to upload to the
|
||||
**Tax Office e-Faktur** application.
|
||||
|
||||
.. _localization_indonesia/npwp_nik:
|
||||
|
||||
NPWP/NIK settings
|
||||
-----------------
|
||||
|
||||
- | **Your Company**
|
||||
| This information is used in the FAPR line in the effect file format. You need to set a VAT
|
||||
number on the related partner of your Odoo company. If you don't, it won't be possible to create
|
||||
an e-Faktur from an invoice.
|
||||
- | **Your Clients**
|
||||
| You need to set the checkbox *ID PKP* to generate e-fakturs for a customer. You can use the VAT
|
||||
field on the customer's contact to set the NPWP needed to generate the e-Faktur file. If your
|
||||
customer does not have an NPWP, just enter the NIK in the same VAT field.
|
||||
|
||||
.. image:: media/indonesia-partner-nik.png
|
||||
:align: center
|
||||
|
||||
.. _localization_indonesia/e-faktur_usage:
|
||||
|
||||
Usage
|
||||
-----
|
||||
|
||||
.. _localization_indonesia/tax_invoice_sn:
|
||||
|
||||
Generate Tax Invoice Serial Number
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
#. Go to :menuselection:`Accounting --> Customers --> e-Faktur`. In order to be able to export
|
||||
customer invoices as e-Faktur for the Indonesian government, you need to put here the ranges of
|
||||
numbers you were assigned by the government. When you validate an invoice, a number will be
|
||||
assigned based on these ranges. Afterwards, you can filter the invoices still to export in the
|
||||
invoices list and click on *Action*, then on *Download e-Faktur*.
|
||||
#. After receiving new serial numbers from the Indonesian Revenue Department, you can create a set
|
||||
of tax invoice serial numbers group through this list view. You only have to specify the Min and
|
||||
Max of each serial numbers' group and Odoo will format the number automatically to a 13-digits
|
||||
number, as requested by the Indonesia Tax Revenue Department.
|
||||
#. There is a counter to inform you how many unused numbers are left in that group.
|
||||
|
||||
.. image:: media/indonesia-sn-count.png
|
||||
:align: center
|
||||
|
||||
.. _localization_indonesia/csv:
|
||||
|
||||
Generate e-faktur csv for a single invoice or a batch invoices
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
#. Create an invoice from :menuselection:`Accounting --> Customers --> Invoices`. If the invoice
|
||||
customer's country is Indonesia and the customer is set as *ID PKP*, Odoo will allow you to
|
||||
create an e-Faktur.
|
||||
#. Set a Kode Transaksi for the e-Faktur. There are constraints related to the Kode transaksi and
|
||||
the type of VAT applied to invoice lines.
|
||||
|
||||
.. image:: media/indonesia-kode-transaksi.png
|
||||
:align: center
|
||||
|
||||
#. Odoo will automatically pick the next available serial number from the e-Faktur number table (see
|
||||
the :ref:`section above <localization_indonesia/tax_invoice_sn>`) and generate the e-faktur
|
||||
number as a concatenation of Kode Transaksi and serial number. You can see this from the invoice
|
||||
form view under the page *Extra Info* in the box *Electronic Tax*.
|
||||
|
||||
.. image:: media/indonesia-e-faktur-sn.png
|
||||
:align: center
|
||||
|
||||
#. Once the invoice is posted, you can generate and download the e-Faktur from the *Action* menu
|
||||
item *Download e-faktur*. The checkbox *CSV created* will be set.
|
||||
|
||||
.. image:: media/indonesia-csv-created.png
|
||||
:align: center
|
||||
|
||||
#. You can select multiple invoices in list view and generate a batch e-Faktur .csv.
|
||||
|
||||
.. _localization_indonesia/kode_transaksi_fp:
|
||||
|
||||
Kode Transaksi FP (Transaction Code)
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
The following codes are available when generating an e-Faktur.
|
||||
- 01 Kepada Pihak yang Bukan Pemungut PPN (Customer Biasa)
|
||||
- 02 Kepada Pemungut Bendaharawan (Dinas Kepemerintahan)
|
||||
- 03 Kepada Pemungut Selain Bendaharawan (BUMN)
|
||||
- 04 DPP Nilai Lain (PPN 1%)
|
||||
- 06 Penyerahan Lainnya (Turis Asing)
|
||||
- 07 Penyerahan yang PPN-nya Tidak Dipungut (Kawasan Ekonomi Khusus/ Batam)
|
||||
- 08 Penyerahan yang PPN-nya Dibebaskan (Impor Barang Tertentu)
|
||||
- 09 Penyerahan Aktiva (Pasal 16D UU PPN)
|
||||
|
||||
.. _localization_indonesia/replace_invoice:
|
||||
|
||||
Correct an invoice that has been posted and downloaded: Replace Invoice feature
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
#. Cancel the original wrong invoice in Odoo. For instance, we will change the Kode Transakski from 01
|
||||
to 03 for the INV/2020/0001.
|
||||
#. Create a new invoice and set the canceled invoice in the *Replace Invoice* field. In this field,
|
||||
we can only select invoices in *Cancel* state from the same customer.
|
||||
#. As you validate, Odoo will automatically use the same e-Faktur serial number as the canceled and
|
||||
replaced invoice replacing the third digit of the original serial number with *1* (as requested
|
||||
to upload a replacement invoice in the e-Faktur app).
|
||||
|
||||
.. image:: media/indonesia-replace-invoice.png
|
||||
:align: center
|
||||
|
||||
|
||||
.. _localization_indonesia/reset_e-faktur:
|
||||
|
||||
Correct an invoice that has been posted but not downloaded yet: Reset e-Faktur
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
#. Reset the invoice to draft and cancel it.
|
||||
#. Click on the button *Reset e-Faktur* on the invoice form view.
|
||||
#. The serial number will be unassigned, and we will be able to reset the invoice to draft, edit it
|
||||
and re-assign a new serial number.
|
||||
|
||||
.. image:: media/indonesia-e-faktur-reset.png
|
||||
:align: center
|
||||
+126
@@ -0,0 +1,126 @@
|
||||
==========
|
||||
Italy (IT)
|
||||
==========
|
||||
|
||||
Questa guida spiegherà come utilizzare la fattura elettronica in Odoo e
|
||||
come configurare correttamente i dati aziendali, i contatti e la
|
||||
contabilità. Per testare la fattura elettronica i dati devono essere
|
||||
reali e non inventati, altrimenti il sistema dell’agenzia delle entrate
|
||||
non riconoscerà l’interscambio di informazioni.
|
||||
|
||||
|
||||
Configurare le informazioni sulla tua Azienda
|
||||
=============================================
|
||||
|
||||
Il passo successivo è la configurazione delle informazioni necessarie al
|
||||
funzionamento della fatturazione elettronica. Si può accedere alla
|
||||
schermata dall’applicazione Impostazioni: selezionare “Utenti e aziende”
|
||||
e scegliere Aziende. Accedere quindi alle informazioni sulla Azienda per
|
||||
cui si desidera configurare la fatturazione elettronica.
|
||||
|
||||
I dati necessari al funzionamento dello strumento di fatturazione
|
||||
elettronica sono i seguenti:
|
||||
|
||||
- Server PEC. Le informazioni sul server utilizzato dal tuo indirizzo
|
||||
di posta elettronica certificata sono fornite dal tuo fornitore o dal
|
||||
Ministero. Lo stesso server deve essere configurato come server che
|
||||
gestisce tutta la corrispondenza mail in Odoo, per saperne di più si
|
||||
puo’ consultare la relativa :doc:`guida <../../../../productivity/discuss/advanced/email_servers>`.
|
||||
|
||||
- Indirizzo PEC dell’ Azienda, tale indirizzo deve essere lo stesso
|
||||
registrato presso l’Agenzia delle Entrate per l’utilizzo dei servizi
|
||||
di fatturazione elettronica.
|
||||
|
||||
- Indirizzo PEC dell’Agenzia delle Entrate. La mail sarà fornito al
|
||||
momento della registrazione della tua PEC presso l’Agenzia delle
|
||||
Entrate, ricorda che l’Agenzia delle Entrate potrebbe cambiare questo
|
||||
indirizzo in seguito, previa comunicazione.
|
||||
|
||||
- Partita IVA e Codice Fiscale. Per far si che la Fatturazione
|
||||
Elettronica funzioni correttamente, questi cambi devono essere
|
||||
compilati correttamente.
|
||||
|
||||
- Regime Fiscale. Il regime fiscale a cui è sottoposta l’Azienda deve
|
||||
essere selezionato scegliendo dalla lista precompilata fornita da
|
||||
Odoo. Chiedi al commercialista qual’è il corretto regime fiscale!
|
||||
|
||||
- Numero di Iscrizione nel registro delle Imprese.
|
||||
|
||||
.. image:: media/italy_IT01.png
|
||||
:align: center
|
||||
|
||||
|
||||
Configurare le impostazioni per la Fatturazione Elettronica
|
||||
-----------------------------------------------------------
|
||||
|
||||
- Numero di iscrizione nel registro Imprese tenuto presso la Camera di
|
||||
Commercio.
|
||||
|
||||
- Rappresentate Fiscale. Questa opzione è dedicata ad aziende con sede
|
||||
al di fuori del territorio nazionale ma conducenti attività
|
||||
commerciali in Italia rilevanti ai fini dell’IVA. È possibile
|
||||
indicare in questo campo se l’Azienda si avvale di un Rappresentate
|
||||
Fiscale in Italia.
|
||||
|
||||
.. image:: media/italy_IT02.png
|
||||
:align: center
|
||||
|
||||
|
||||
Configurare il profilo dei clienti
|
||||
----------------------------------
|
||||
|
||||
Per un corretto utilizzo dell’applicazione, il profilo di clienti e
|
||||
fornitori, nell’applicazione contatti, deve essere configurato con le
|
||||
necessarie informazioni legali.
|
||||
|
||||
Selezionando il nome del cliente e accedendo quindi ai suoi dati, si
|
||||
trovano i seguenti campi che devono essere compilati: Indirizzo PEC,
|
||||
Codice Fiscale e Indice PA *che deve contere i 6-7 caratteri
|
||||
contenuti nell’indice PA e necessari per la comunicazione tramite
|
||||
fattura elettronica*.
|
||||
|
||||
.. image:: media/italy_IT03.png
|
||||
:align: center
|
||||
|
||||
|
||||
Il processo di fatturazione
|
||||
===========================
|
||||
|
||||
Si può procedere ad emettere una fattura seguendo le indicazioni
|
||||
dell’applicazione. Il momento che determina il formale invio della
|
||||
fattura è il momento in cui viene selezionata l’opzione “Valida”. La
|
||||
fattura viene quindi inviata: lo stato della sua consegna verrà
|
||||
notificato all’utente tramite pop-up sulla parte iniziale della
|
||||
schermata della fattura.
|
||||
|
||||
.. image:: media/italy_IT04.png
|
||||
:align: center
|
||||
|
||||
.. image:: media/italy_IT05.png
|
||||
:align: center
|
||||
|
||||
I messaggi che possono apparire sono i seguenti:
|
||||
|
||||
#. Fattura invitata. In attesa di accettazione
|
||||
|
||||
#. Invio fallito. Puoi modificare la fattura ed inviarla di nuovo
|
||||
|
||||
#. La fattura è stata correttamente inviata ed accettata dal
|
||||
destinatario.
|
||||
|
||||
I vari stadi di spedizione e recezione della fattura sono visibili anche
|
||||
dall’elenco delle Fatture nella forma di icone, accanto alla colonna
|
||||
“Stato” dall’applicazione contabilità.
|
||||
|
||||
*Icona Rossa*: Invio fallito
|
||||
|
||||
*Icona Gialla*: Fattura invitata. In attesa di accettazione
|
||||
|
||||
*Icona Verde*: Fattura inviata e accettata dal destinatario
|
||||
|
||||
Per inviare la fattura tramite PEC e generare il file XML, basterà
|
||||
cliccare su invia. Il documento verrà poi mostrato tra gli allegati.
|
||||
|
||||
.. image:: media/italy_IT06.png
|
||||
:align: center
|
||||
|
||||
BIN
Binary file not shown.
|
After Width: | Height: | Size: 25 KiB |
BIN
Binary file not shown.
|
After Width: | Height: | Size: 38 KiB |
BIN
Binary file not shown.
|
After Width: | Height: | Size: 60 KiB |
BIN
Binary file not shown.
|
After Width: | Height: | Size: 40 KiB |
BIN
Binary file not shown.
|
After Width: | Height: | Size: 15 KiB |
BIN
Binary file not shown.
|
After Width: | Height: | Size: 26 KiB |
BIN
Binary file not shown.
|
After Width: | Height: | Size: 23 KiB |
BIN
Binary file not shown.
|
After Width: | Height: | Size: 55 KiB |
BIN
Binary file not shown.
|
After Width: | Height: | Size: 9.1 KiB |
BIN
Binary file not shown.
|
After Width: | Height: | Size: 52 KiB |
BIN
Binary file not shown.
|
After Width: | Height: | Size: 60 KiB |
BIN
Binary file not shown.
|
After Width: | Height: | Size: 16 KiB |
BIN
Binary file not shown.
|
After Width: | Height: | Size: 94 KiB |
BIN
Binary file not shown.
|
After Width: | Height: | Size: 49 KiB |
BIN
Binary file not shown.
|
After Width: | Height: | Size: 45 KiB |
BIN
Binary file not shown.
|
After Width: | Height: | Size: 46 KiB |
BIN
Binary file not shown.
|
After Width: | Height: | Size: 35 KiB |
BIN
Binary file not shown.
|
After Width: | Height: | Size: 2.7 MiB |
BIN
Binary file not shown.
|
After Width: | Height: | Size: 27 KiB |
BIN
Binary file not shown.
|
After Width: | Height: | Size: 86 KiB |
BIN
Binary file not shown.
|
After Width: | Height: | Size: 46 KiB |
BIN
Binary file not shown.
|
After Width: | Height: | Size: 105 KiB |
BIN
Binary file not shown.
|
After Width: | Height: | Size: 12 KiB |
BIN
Binary file not shown.
|
After Width: | Height: | Size: 131 KiB |
BIN
Binary file not shown.
|
After Width: | Height: | Size: 178 KiB |
BIN
Binary file not shown.
|
After Width: | Height: | Size: 140 KiB |
BIN
Binary file not shown.
|
After Width: | Height: | Size: 62 KiB |
BIN
Binary file not shown.
|
After Width: | Height: | Size: 64 KiB |
BIN
Binary file not shown.
|
After Width: | Height: | Size: 69 KiB |
BIN
Binary file not shown.
|
After Width: | Height: | Size: 111 KiB |
BIN
Binary file not shown.
|
After Width: | Height: | Size: 38 KiB |
BIN
Binary file not shown.
|
After Width: | Height: | Size: 97 KiB |
BIN
Binary file not shown.
|
After Width: | Height: | Size: 26 KiB |
BIN
Binary file not shown.
|
After Width: | Height: | Size: 43 KiB |
BIN
Binary file not shown.
|
After Width: | Height: | Size: 65 KiB |
BIN
Binary file not shown.
|
After Width: | Height: | Size: 29 KiB |
BIN
Binary file not shown.
|
After Width: | Height: | Size: 22 KiB |
BIN
Binary file not shown.
|
After Width: | Height: | Size: 57 KiB |
BIN
Binary file not shown.
|
After Width: | Height: | Size: 17 KiB |
BIN
Binary file not shown.
|
After Width: | Height: | Size: 157 KiB |
BIN
Binary file not shown.
|
After Width: | Height: | Size: 83 KiB |
BIN
Binary file not shown.
|
After Width: | Height: | Size: 55 KiB |
BIN
Binary file not shown.
|
After Width: | Height: | Size: 21 KiB |
BIN
Binary file not shown.
|
After Width: | Height: | Size: 4.8 KiB |
BIN
Binary file not shown.
|
After Width: | Height: | Size: 9.8 KiB |
BIN
Binary file not shown.
|
After Width: | Height: | Size: 38 KiB |
BIN
Binary file not shown.
|
After Width: | Height: | Size: 35 KiB |
BIN
Binary file not shown.
|
After Width: | Height: | Size: 16 KiB |
BIN
Binary file not shown.
|
After Width: | Height: | Size: 43 KiB |
BIN
Binary file not shown.
|
After Width: | Height: | Size: 48 KiB |
BIN
Binary file not shown.
|
After Width: | Height: | Size: 50 KiB |
BIN
Binary file not shown.
|
After Width: | Height: | Size: 35 KiB |
BIN
Binary file not shown.
|
After Width: | Height: | Size: 47 KiB |
BIN
Binary file not shown.
|
After Width: | Height: | Size: 19 KiB |
BIN
Binary file not shown.
|
After Width: | Height: | Size: 23 KiB |
BIN
Binary file not shown.
|
After Width: | Height: | Size: 20 KiB |
BIN
Binary file not shown.
|
After Width: | Height: | Size: 23 KiB |
BIN
Binary file not shown.
|
After Width: | Height: | Size: 68 KiB |
BIN
Binary file not shown.
|
After Width: | Height: | Size: 54 KiB |
BIN
Binary file not shown.
|
After Width: | Height: | Size: 30 KiB |
BIN
Binary file not shown.
|
After Width: | Height: | Size: 38 KiB |
BIN
Binary file not shown.
|
After Width: | Height: | Size: 56 KiB |
BIN
Binary file not shown.
|
After Width: | Height: | Size: 90 KiB |
BIN
Binary file not shown.
|
After Width: | Height: | Size: 47 KiB |
BIN
Binary file not shown.
|
After Width: | Height: | Size: 49 KiB |
BIN
Binary file not shown.
|
After Width: | Height: | Size: 14 KiB |
BIN
Binary file not shown.
|
After Width: | Height: | Size: 12 KiB |
BIN
Binary file not shown.
|
After Width: | Height: | Size: 60 KiB |
BIN
Binary file not shown.
|
After Width: | Height: | Size: 42 KiB |
BIN
Binary file not shown.
|
After Width: | Height: | Size: 42 KiB |
BIN
Binary file not shown.
|
After Width: | Height: | Size: 80 KiB |
BIN
Binary file not shown.
|
After Width: | Height: | Size: 52 KiB |
BIN
Binary file not shown.
|
After Width: | Height: | Size: 60 KiB |
BIN
Binary file not shown.
|
After Width: | Height: | Size: 115 KiB |
BIN
Binary file not shown.
|
After Width: | Height: | Size: 64 KiB |
BIN
Binary file not shown.
|
After Width: | Height: | Size: 94 KiB |
BIN
Binary file not shown.
|
After Width: | Height: | Size: 29 KiB |
BIN
Binary file not shown.
|
After Width: | Height: | Size: 85 KiB |
BIN
Binary file not shown.
|
After Width: | Height: | Size: 54 KiB |
BIN
Binary file not shown.
|
After Width: | Height: | Size: 109 KiB |
BIN
Binary file not shown.
|
After Width: | Height: | Size: 116 KiB |
BIN
Binary file not shown.
|
After Width: | Height: | Size: 109 KiB |
BIN
Binary file not shown.
|
After Width: | Height: | Size: 26 KiB |
BIN
Binary file not shown.
|
After Width: | Height: | Size: 83 KiB |
BIN
Binary file not shown.
|
After Width: | Height: | Size: 94 KiB |
BIN
Binary file not shown.
|
After Width: | Height: | Size: 97 KiB |
BIN
Binary file not shown.
|
After Width: | Height: | Size: 85 KiB |
BIN
Binary file not shown.
|
After Width: | Height: | Size: 85 KiB |
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user