ITAS eInvoicing

Contents

Invoicing in ITAS....

eInvoicing Process....

Uruguay....

Onshore / Offshore/ Contingency....

CFE Types....

Outgoing eInvoice....

Incoming eInvoices....

Resending eInvoices....

Daily Report....

ASP Page....

Logging....

Set Up....

S01....

MTM set up....

SINV Next Numbers screen....

Digital Certificates....

IGI....

EFAC Codes....

Client Data....

Electronic Signatures....

XSD....

DocmanServer....

QR Code....

J03.exe.config....

Webservice and ASP Page....

Mexico....

Outgoing Electronic Invoices....

Incoming Electronic Invoices....

Resending CFDIs....

Cancellation vs Reversals....

Chile....

Outgoing Electronic Invoices....

Incoming Electronic Invoices....

Resending CFDIs....

Columbia

Outgoing Electronic Invoices...

Resending eInvoices

Month End Report

eInvoicing Structure....

ITASeInvoice.COM....

Code....

Flowchart....

 

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.

CFE Types

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.

Outgoing eInvoice

  1. User creates sales invoice in AGSINV_UE
  2. 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.

 

Incoming eInvoices

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

  1. Incoming CFEs can also be processed in PINV_UE.
  2. 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.

 

Resending eInvoices

A CFE will need to be resent in the following cases.

  1. The CFE was invalid because of missing / incorrect client static e.g. incorrect RUT number.
  2. Network error or DGI web service unavailable
  3. 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.

 

Daily Report

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.

 

ASP Page

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

 

Logging

The log file for eInvoicing is itas\log\xx_einvoice.log where xx is the company code.

Set Up

S01

S01 eInvoicing style should be set to Uruguay

 

MTM set up

2 new menu options are required

 

SINV Next Numbers screen

 

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:

  1. 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
  2. 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.
  3. Webservice URL – DGI webservice
  4. Certificate Thumbprint : Thumbprint of the digital signature used to sign the CFEs
  5. UI rate – Used in calculation of threshold to see if eTicket should be sent to DGI
  6. Next envelope ID – identified used in CFE envelope
  7. eTicket UI Threshold: Used in calculation of threshold to see if eTicket should be sent to DGI
  8. eInvoice email initials : CMP email address used as sender on CFE emails

 

Digital Certificates

Certificates need to be installed on all machines used to send / receive CFEs. The user must have read access to the private keys.

 

IGI

The following IGI Styles should be imported:

 

EFAC Codes

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

 

Technical

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 .

 

IGI

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

 

 

Electronic Signatures

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.

 

XSD

The  XSDs used to validate the CFE xml are stored in i:\exec\xsd

 

DocmanServer

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

 

QR Code

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=

 

J03.exe.config

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

 

Webservice and ASP Page

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

Outgoing Electronic Invoices

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.

 

Incoming Electronic Invoices

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.

 

Resending CFDIs

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

 

Cancellation vs Reversals

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

Outgoing Electronic Invoices

 

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

  1. Get an authorisation token
  2. Send XML file with authorisation token receive track id for the invoice
  3. 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.

Incoming Electronic Invoices

 

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

 

Resending CFDIs

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

Outgoing Electronic Invoices

 

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 . 

 

 

Resending eInvoices

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.