ITAS eInvoicing
Contents
Invoicing in ITAS....
eInvoicing Process....
Uruguay....
Onshore / Offshore/ Contingency....
CFE Types....
Daily Report....
ASP Page....
Logging....
IGI....
EFAC Codes....
Client Data....
J03.exe.config....
Outgoing Electronic Invoices....
Incoming Electronic Invoices....
Outgoing Electronic Invoices....
Incoming Electronic Invoices....
Resending CFDIs....
Outgoing Electronic Invoices...
ITASeInvoice.COM....
Invoicing in ITAS
In ITAS Invoices are raised when you
Buy something (TRADE – Purchase contract - phys01 record)
Sell something (TRADE – Sales contract – phys01 record)
When costs associated with the contract (e.g. Freight , loading , warehouse costs ) are invoiced These can be either payable ( you have to pay for the cost ) or receivable ( you are charging the counterparty ) TRADE – Costs – phys03
When commissions are invoices, again these can be payable or receivable.
TRADE – Commissions – phys02
Typically an ITAS invoice program will generate an invoice based on the contract details (phys01 / phys02 / phys03)
The invoice will consist of
- a paper document / rtf file generated by docdes
- Accounting dhl21/dhlxx ( credit P&L / WIP and VAT accounts and debit the client )
- Invoice markings ( phys06 – trade , phys12 – costs , phys13 – commissions )
- Update phys01
There are other types of invoices (e.g. prepayments, manual invoices)
There are different invoicing programs in ITAS which deal with different types of business or different ITAS setups.
eInvoicing has been implemented in the following programs:
J03 ( AGSINV / SINV ) – ( purchase / sales / costs / commission invoices )
J01 ( INVFEED ) – sales invoices
J50 (INVPURCH ) – purchase invoices
J51 (INVDIRECT) – cost invoices
J52 (COMNOTE) - commission invoices
eInvoicing Process
Uruguay
The Uruguayan Government require that large taxpayers send their on-shore invoices electronically . They must also be able to receive invoices electronically.
Electronic invoices (CFEs) are xml files in a format specified by the Uruguayan tax authority (DGI)
They are sent to a DGI web service and also via email to the counterparty.
Onshore / Offshore/ Contingency
Onshore invoices are those sent to Uruguayan companies. Offshore invoices are those sent to foreign companies. Contingency invoices are those produced when the DGI web service is not available.
These are the types of CFE available for the electronic documentation of operations:
o e-Invoice
o e-Invoice Credit note. } For operations among taxpayers (B2B)
o e-Invoice Debit note.
o e-Ticket.
o e-Ticket Credit note. } Only for Final Consumption (B2C)
o e-Ticket Debit note.
o e-Receipt.
o e-Resguardo – withholding tax
Each CFE type has its own set of sequence numbers.
- User creates sales invoice in AGSINV_UE
- On the working page the user selects Invoice Style ( Cash / Credit ) , Invoice Type ( On shore , off shore or contingency and CFE type ( eInvoice / eTicket)
3. SINV will generate an aud02 record and take the next sequence number for the selected CFE type.
4. The CFE xml file will be generated. This will be sent to the government web service which performs a preliminary validation.
If it is accepted the response will contain a token to identify the CFE and a time to check the final status.
At this stage a QR code is generated which is added to the invoice document. The invoice is then saved as a pdf and both it and the CFE xml file are emailed to the counterparty.
5. An ITAS batch job ( ctrl11) is submitted to run at the time specified by the DGI. This calls a second web service which reports if the CFE has been accepted or not.
The ITAS program calling the web service (J60) will email the creator of the invoice with the result. If the CFE has been accepted the accounting document will be posted. If not the aud02 will be marked as void.
6. Upon receiving the CFE the counterparty should send an acknowledgement. They can either accept or reject the CFE. The acknowledgement will be sent to the CFE email address which is monitored by Docman Server. When docman server receives an acknowledgement it emails the creator of the invoice. If the CFE has been accepted it updates the aud02 as acknowledged.
DOCENT
1. Incoming CFEs are received by DocmanServer and moved to the CFE folder to be processed.
2. The DOCENT menu option Process Electronic Invoice prompts for the CFE xml file to process
3. The user is shown the details from the CFE
They can accept or reject the CFE.
4. The response xml is generated using the ACKPARTES IGI style and is sent to the counterparty.
5. The DOCENT form is shown with the details from the CFE populated.
6. When the invoice is saved the CFE is moved to the invoices folder.
PINV_UE
- Incoming CFEs can also be processed in PINV_UE.
- The process is similar to DOCENT but user is prompted to select a purchase contract for the counterparty based on the RUT in the incoming CFE.
A CFE will need to be resent in the following cases.
- The CFE was invalid because of missing / incorrect client static e.g. incorrect RUT number.
- Network error or DGI web service unavailable
- Wrong CFE type ( eTicket / eInvoice ) selected.
The SINV_UE option Resend CFE will show CFEs available for resend :
This will show all unposted invoices not accepted by the DGI or marked as void.
Resending will regenerate the CFE xml from the IGI style so new client static will be picked up. The invoice rtf/pdf document may need to be updated manually.
If the CFE was rejected by J60 and marked as void a new sequence number will be generated.
There are also options to resubmit the status check if the J60 web service call failed and to recreate the QR code.
Each day the company must produce a report of all CFEs sent. This is created in AGSINV_UE > eFactura Daily report.
The program prompts for the date of the report and a Sequence number.
If a correction needs to be made to a previously sent report the sequence number should be increased. e.g. if Seq 1 was sent on 1st July but subsequently that day more CFEs were generated then the Seq 2 should be sent as a replacement of Seq 1.
It is generated using the IGI style EFACRECEPECIONREPORTE and sent to the DGI via web service.
EDFMAN have a webserver where clients can download there CFEs in XML or PDF format.
When the eInvoice is created a webservice is called which copies the xml and pdf files an stores the type, series, receipt no, amount and security code.
An ASP page allows clients to look up their invoice using these details
The log file for eInvoicing is itas\log\xx_einvoice.log where xx is the company code.
Set Up
S01 eInvoicing style should be set to Uruguay
2 new menu options are required
In SINV_UE there is a right click option for next numbers which need to be set up. These are the numbers that are assigned to each CFE. A different sequence is required for each type of CFE .
The settings also need to be completed:
- Report days before expiry : a report is generated each night by J09 ( URUGU_UE ) this will report CAE numbers ( Assigned numbers tab) that are due to expire
- QR Code URL . A QR code is printed on the eInvoice document which points to this URL plus some parameters so that the CFE can be retrieved from the DGI site.
- Webservice URL – DGI webservice
- Certificate Thumbprint : Thumbprint of the digital signature used to sign the CFEs
- UI rate – Used in calculation of threshold to see if eTicket should be sent to DGI
- Next envelope ID – identified used in CFE envelope
- eTicket UI Threshold: Used in calculation of threshold to see if eTicket should be sent to DGI
- eInvoice email initials : CMP email address used as sender on CFE emails
Certificates need to be installed on all machines used to send / receive CFEs. The user must have read access to the private keys.
The following IGI Styles should be imported:
The following static data must be set up
Client Data
In CLI each counterparty that will be sending or receiving eInvoices should be set up as an eSender / eReceiver - Document type, number and address should also be set. The other details are required for Mexico eInvoicing but are not required for Uruguay.
The CFE email address for the counterparty is set up in contacts. The contact should have a job role of “CFE”
Interface codes should be set on VAT
Most of the code is in ITASeInvoice.dll
The format for the CFE XML files is stored as IGI styles and IGI is used to generate the CFE from the dhl and aud02 details .
The following IGI styles are used :
| CFE | Export – J03 | CFE for Invoices |
| CFEDNDN | Export – J03 | CFE for Credit and Debit notes |
| SOBRE | Export – J03 | “Envelope” each submission to the DGI is sent in an envelope of sobre which may contain 1 or multiple CFEs |
| ACKCFE | Import – J60 | Parses the response to the CFE from the DGI |
| ACKPARTES | Export – J03/D02 | Response sent to the counterparty |
| ACKREPORT | Import – J03 | Parses response to the SOBRE from the DGI |
| PARSECFE | Import – J03 / D02 | Parses the incoming CFE from the counterparty |
| EFACCONSLTARESTADOENVIO | Export – J60 | Check the status of the CFE |
| RUCEMISORES | Import – L01 | Process the emisores file – List of electronic senders in XML format |
| ACKSOBRE | Import – J03 | Parses the response to the CFE from the DGI |
| PARSECAE | Import – J03 | Import the CAE – Next numbers file sent by the DGI |
| ACKPARTESCFE | Export – J03/D02 | Response sent to the counterparty |
| EFACRECEPECIONREPORTE | Export – J03 | Daily Report |
Each CFE has to be signed with an electronic signature based on a certificate issued by the DGI . The certificate has to be installed on the machine sending the CFEs.
The XSDs used to validate the CFE xml are stored in i:\exec\xsd
Emails to the designated eInvoice email address will be picked up by docman server
They are split into acknowledgements and CFEs
Acknowledgements from the counterparty which are parsed and the document creator is notified by email
Incoming CFEs are put into the incoming CFE folder for processing by AGPINV_UE / DOCENT
The QR Code is based on the following data:
Einvoice url
Inancor RUT (vatreg)
CFE Type
CFE Series
CFE No.
Amount
CFE Date
CFE Digest ( signature )
Eg:
https://www.efactura.dgi.gub.uy/consultaQR/cfe?212693310010,102,BC,9,1210,22/08/2013,Kq54MAEan7g9HD/TMLzRand3dI4=
Config files are used to config the WCF connection to the DGI webservice
They are stored in the itas\exec folder for J03 J60 and D02
The webservice to copy files to the webserver with the ASP page and the ASP Page itself are in the following projects
I:\source\WebServices\EINVOICEWEBSERVERUPDATE
And
I:\source\WebServices\eInvoiceWeb\
Mexico
SINV (J03), INVFEED(J01)
When an invoice is created an aud02 and aud05s will be created applying the next sequence number for the invoice type (invoice, credit note, debit note or customs invoice number)
A CFDI xml file is created and sent to the PAC via a REST web service.
The IGI style MEXINVOICE is used to generate the CFDI
The PAC will return a new version of the CFDI containing a digital signature and identification number UU-ID.
The UUID is then used to call a second web service which returns a pdf representation of the invoice in base64 format.
The pdf file is saved to the invoices folder and both are emailed to the counterparty.
INVDIRECT (J51), COMNOTE (J52)
When receivable costs and commissions are processed, a CFDI is also created. Again the PDF file will be downloaded from the PAC and sent to the counterparty.
INVPURCH (J50), PINV (J03), INVDIRECT, (J51) , COMNOTE (J52) and DOCENT (D02)
When payable costs and commissions or Purchase invoices are processed the operating company will receive a CFDI file from the counterparty.
This is processed and an aud02 with type = “RECEIVE” is generated.
The user will be shown the details from the CFDI can select the costs, commissions or purchases for the counterparty whose RFC matches the RFC on the CFDI.
Before an CFDI is processed it is sent a the PAC web service for validation.
If the CFDI fails validation a message is displayed to the user.
The url for the validation web service is set in AGSINV > Next numbers. Validation can be bypassed by removing this url.
If the client static is incorrect or the PAC web service is unavailable when the invoice is created the CFDI may need to be regenerated and resent. This is done via AGSINV > Resend CFDI
When an invoiced is reversed in Mexico it can be cancelled or reversed. There is a difference between the two from a tax point of view.
Cancellations are treated as though the original invoice was never raised. Therefore there is no tax to pay.
When a reversal is done the tax on the original invoice should be paid and then reclaimed at the end of the financial year.
To separate the two styles Cancellations have a document type of EC.
| MEXINVOICE | Export | Main EInvoice Style ( v3.2) |
| MEXINVOICE33 | Export | Main EInvoice Style (v3.3) |
| MEXPAGO10 | Export | CFDI for cash matching |
| MEXCOMERCIOEXTERIOR | Export | Addenda for export sales |
| MEXVEHICULOUSADO | Export | Addenda for Vehicle Sales |
| MEXCUSTOM | Export | Custom Addenda – Client specific |
| MEXCATALOGO | Export MEXBOOKS | Month end accounts list |
| MEXTB | Export MEXBOOKS | Month end trial balance |
| MEXAUXTRANS | Export MEXBOOKS | Month End report |
| MEXAUXCTAS | Export MEXBOOKS | Month End report |
Chile
SINV (J03), INVFEED (J01)
When an invoice is created an aud02 and aud05s will be created applying the next sequence number for the invoice type (invoice, credit note, debit note or customs invoice number)
An electronic invoice consists of an ENVIO ( envelope ) and one or more DTEs ( invoices ) . Each DTE will contain a TED which is a signed summary of the invoice.
IGI styles DTE, ENVIO CPENVIO and TED are combined with a CAF xml file there is one CAF per invoice type. The xml is signed and sent to the SII
Sending is a three stage process
- Get an authorisation token
- Send XML file with authorisation token receive track id for the invoice
- Check status using track id
PDF file is generated based on xsl-fo template and emailed to counterparty together with the xml file.
INVDIRECT (J51), COMNOTE (J52)
When receivable costs and commissions are processed, a DTE xml is also created and sent to SII. Again the PDF file will be generated and sent to the counterparty.
INVPURCH (J50), PINV (J03), INVDIRECT, (J51) , COMNOTE (J52) and DOCENT (D02)
When payable costs and commissions or Purchase invoices are processed the operating company will receive an XML file from the counterparty.
This is processed and an aud02 with type = “RECEIVE” is generated.
The user will be shown the details from the DTE can select the costs, commissions or purchases for the counterparty whose RFC matches the RUT on the DTE.
An acknowledgement xml is created for the envio ( the envelope ) and for each DTE in the envio
If the client static is incorrect or the SII web service is unavailable when the invoice is created the DTE may need to be regenerated and resent. This is done via SINV > Resend DTE
IGI Styles used
| DTE, | Export | Main EInvoice Style |
| TED | Export | Summary of DTE |
| ENVIO , CPENVIO | Export | “Envelope” each submission to the SII is sent in an envelope which may contain 1 or multiple DTEs |
| ACKDTE | Export | Acknowledgement |
| ACKDTE_RESULT | Export | Acknowledgement Details |
| RECIBO | Export | Acknowledgement Receipt |
| ENVIORECIBOS | Export | Acknowledgement Receipt Envelope |
| CHILEIEVIEC | Export | Used for Chilebooks – Month end reports |
Columbia
AGSINV (J03),
When an invoice is created an aud02 and aud05s will be created applying the next sequence number for the invoice type (invoice, credit note, debit note or export invoice number)
A webservice call is made to the Dispapeles ( Third party eInvoice processor ) which sends the eInvoice to the Tax Authority generates a PDF and XML and sends them to the counterparty
Each hour a status check process (J60 ) is run by windows scheduler to check the status of the invoice with Dispapeles , when it is sent the aud02 record is marked as complete and the accounting is posted .
If the client static is incorrect or the SII web service is unavailable when the invoice is created the eInvoice may need to be regenerated and resent. This is done via AGSINV > Resend eInvoice
Month End Report
A month end report can be generated in AGSINV to compare the eInvoices received by dispapeles to the records saved in the aud02 table
eInvoicing Structure
ITASeInvoice.COM
The ITASeInvoice.dll has a COM class which exposes the following functions
| SendEInvoice | Create eInvoice XML and send to TA |
| SendReport | Create Daily report and send to TA ( Uruguay Only) |
| ReceiveEInvoice | Process XML and create ADODB.Resultset containing the data for processing |
| PictureRTFCode | Gets RTF code for barcode ( Uruguay Only) |
| SendCFEToWebserver | Send a copy of the CFE xml and pdf to a webserver |
| CreatePDF | Create PDF ( Mexico and Chile) |
| ShowSummaryNotes | Show a screen allowing entry of additional narratives |
| ClientRFCOK | Check the RFC for non Mexican companies is as per the settings (Mexico only) |
| CerticateExpiry | Returns the expiry date of the digital certificate used for Uruguay |
| InsertReceivedAud02 | Insert the aud02 generated for incoming eInvoices |
| FnXMLRequired | Checks client static to see if eInvoice is required |
| FolderPath | Folder for eInvoices |
| DocmanFolder | Docman folder for eInvoices |
| InsertAud02 | Insert Aud02 record |
| GetNextEinvoiceNo | Get next sequence number |
| SendInvoiceEmail | Send email to the counterparty |
| GetCtrl104 | Get Einvoice Setting |
| CreateGuiaDespacho | Create Guia de Despacho ( Chile delivery note ) prompts for additional details |
| PromptResguardoTransactions | Prompt for transactions to be included in eResguardo |
| InsertResguardoTransactions | Insert eResguardo transactions |
Code
The code is in the following dot net dlls
\\hivedome-dev01\itas\source\dll\itaseinvoice\itaseinvoice.sln
The following flow diagram should give you an idea of what the bits of the dll do.
