Dynamics NAV e-Purchasing in Mexico

Here in Mexico, we have a government very interested in track all the operations between companies, that´s why we have electronic accounting and electronic invoicing.

With Dynamics NAV we have some problems, the “out-of-the-box” system lacks of some functionality to achieve the goal.

In this post, I’m gonna show the e-purchase functionality designed for the purchase area.

In Mexico we have the CFDI (Internet Digital Fiscal Bill), it’s a xml file with the Sales/purchase transaction information. We have several versions but in this year, the government add information related to the purchased items or services.

With this new data, we can add a special table called “SAT ProdServ Item Relation” and put in that table what we want to post in NAV when an xml file is processed.

clip_image002

What we need to do with this? We develop a new codeunit to process the xml files, we grab the files from a folder, read the file and fill a “cloned purchase order”

clip_image004

As you can see in the image, we make an Imported xml list with some functions:

Import Purch xml – This button grabs the xml files from a folder in your computer.

New Invoice from xml – Because we have all the info in the xml file, we can create a purchase invoice from the file.

Search & Match – Clicking in this button allows NAV to look for an existing Posted Purchase Invoice trying to match the xml to the posted invoices by RFC (Mexican Federal taxpayer registration), invoice amount (with a user-defined variation) and/or invoice date (also with a user-defined variation). If the system found a document, the posted invoice number is added to the list (green formatted line).

If you open the line, you can find the xml imported information that allow us to create a new vendor if we can’t find the RFC in the system.

clip_image006

With the new fields required by the last xml version (3.3) and the “SAT ProdServ Item Relation” we can fill the lines automatically.

clip_image008

Also, we added Job related information to add the purchase to a job and Dimension Control

clip_image010

AS you can see, with this development, we added support to Dynamics NAV to achieve a more automated process for purchase control without “touch” the NAV standard functionality or objects.

Extending possibilities

We added support for Standard Vendor Purchase Codes use with this objects; if you create a purchase standard code for the Vendor, we can use that (for G/L account) to make a Dimension distribution of the expense (as an example, cost center control).

Also we added a validation tool to check if the CFDI is valid using a Web Service of the government sending the required information (which we have in the import process of the xml file). If we have an approved answer for the service we can create the purchase, if we have a rejection from the service, the xml cannot create nor be assigned to a document in the system.

Anuncios

Una estupidez mas del SAT

La semana pasada un cliente me envio dos xml´s generados desde NAV ya que no pasaban el validador del SAT.

Resulta que la semana pasada el SAT realizó un cambio en su validador de CFD´s integrando una función nueva de validación
denominada BOM (Byte Order Mark) sin informar a la gente de este cambio.

Dicho BOM está establecido como obligatorio para los archivos codificados en UTF-16, sin embargo en el anexo 20 de la RMF indica que la codificación deberá hacerse acorde a lo establecido por el W3C; en el W3C se establece la obligatoriedad para el UTF-16 pero también establece que para UTF-8 NO ES NECESARIO y también indica que la codificación a utilizar para los xml´s de CFD deberá ser en UTF-8 de manera obligatoria.

El hecho es que al hacer este cambio sin avisar, el validador del SAT rechazó TODOS los xml´s generados a nivel nacional durante esa semana. Esto implicó que los CFD´s generados a nivel nacional desde el inicio de este esquema de facturación quedarían invalidados automáticamente.

Este pasado lunes 18, el validador REGRESO A SU ESTADO ANTERIOR (SIN BOM) debido a que se dieron cuenta de la metida de pata que dieron.

Los dos xml´s que me envió el cliente los volvi a comprobar y pasaron OK

De verdad que como dicen en un foro dedicado a las facturas electronicas “la gente que trabaja ahi esta porque conoce a alguien, no porque sepa algo”.