Análisis de Información

 

En Dynamics NAV existe una cantidad bastante respetable de reportes que pueden ser utilizados para obtener información, sin embargo la gran mayoría son fijos y su modificación implica tener que recurrir a un desarrollador para modificar esos reportes.

Otra opción es utilizar los análisis por dimensiones o los informes de análisis pero ambos están basados en dimensiones lo que a veces no corresponde con la información que se está buscando.

En el caso de que NAV se este ejecutando en SQL Server (versión normal o express) podemos acceder mediante conexiones ODBC desde Excel o podemos utilizar herramientas de análisis especiales (de las cuales hablare después).

El uso de SQL permite realizar consultas directas a la base de datos de NAV para obtener siempre la información mas reciente. Si esto lo conjugamos con la creación de vistas en SQL, tablas y gráficos dinámicos de Excel (en especifico usare la versión 2010 para este blog), nos permitirá generar reportes con información actual, de forma fácil y sobre todo, apuntada directamente a lo que se busca.

Inicialmente, que información se busca mas?

Pensemos como un analista de cuentas por cobrar, o por pagar, o almacenista, mejor vayamos con uno de ellos y solicitémosle que nos ponga en un Excel o un papel las filas y columnas que desea ver.

La gran mayoría de los reportes se basan en tablas especificas donde se almacena la información de la operación diaria.

Estas tablas son:

  • Item Ledger Entry
  • Customer Ledger Entry
  • Vendor Ledger Entry
  • Value Entry
  • G/L Entry
  • Sales Invoice Header
  • Sales Invoice Line
  • Purchase Invoice Header
  • Purchase Invoice Line

Las tablas anteriores las podemos tomar como base para los análisis pero deberemos mezclarlas con :

  • Customer
  • Vendor
  • Item
  • Dimension Value

Entre otras.

Deberemos de tratar de entender la forma de trabajo de NAV al realizar un proceso, por ejemplo, si queremos ver los productos que se han vendido deberemos entrar a item ledger entry, ahora bien, si queremos saber cuanto costo, en cuanto se vendió y de ahí sacar el beneficio tanto en monto como en porcentaje entonces lo mejor es empezar con value entry. Si esta información la queremos manejar por ejemplo por estado de la republica, deberemos unir la tabla base con customer a fin de obtener el dato.

Por ejemplo, utilidad por estado en base a los productos vendidos

Deberemos crear una consulta como la que pongo a continuación:

SELECT    
[EMPRESA$Value Entry].[Item Ledger Entry Type],
[EMPRESA$Value Entry].[Source No_],
[EMPRESA$Customer].County,
[EMPRESA$Value Entry].[Item No_],
[EMPRESA$Value Entry].Description,
[EMPRESA$Value Entry].[Invoiced Quantity],
[EMPRESA$Value Entry].[Cost Amount (Actual)],
[EMPRESA$Value Entry].[Sales Amount (Actual)],
[EMPRESA$Value Entry].[Posting Date],
([EMPRESA$Value Entry].[Sales Amount (Actual)]+[EMPRESA$Value Entry].[Cost Amount (Actual)])*-1 AS ‘Utilidad’

FROM         [EMPRESA$Customer] INNER JOIN
                      [EMPRESA$Value Entry] ON [EMPRESA$Customer].No_ = [EMPRESA$Value Entry].[Source No_]
WHERE     ([EMPRESA$Value Entry].[Item Ledger Entry Type] = 1)

En primer lugar,

Porque Value Entry en lugar de Item Ledger Entry?

Porque en la tabla Item Ledger Entry los campos de Cost Amount Actual y Sales Amount Actual son campos calculados por lo que no son visibles en SQL y son tomados desde Value Entry.

Porque Item Ledger Entry Type =1?

Porque el 1 representa Ventas

Como podemos ver, el INNER JOIN nos permite unir todos los registros de Value Entry tipo Venta con un Source No igual al numero de cliente registrado en NAV y de ahí llamamos el campo County que almacena el estado.

Ahora, que hacemos para poner esto en Excel?

Podemos guardar la consulta en SQL  para tener el código a la mano y entonces desde Excel conectar a la base (para ver este punto http://office.microsoft.com/en-us/excel-help/use-microsoft-query-to-retrieve-external-data-HA010099664.aspx)

image

Otra opción es crear la vista en SQL  y entonces dejarle al usuario la conexión de forma mas sencilla, para esto solo agregaremos la siguiente instrucción

CREATE VIEW nombrevista AS

SELECT…

Ahora bien, la información se presentara en el formato nativo de SQL definido por el tipo de campo

image

Para que los campos se vean mas entendibles en Excel deberemos modificar la sentencia SQL como se describe a continuación:

SELECT    
[EMPRESA$Value Entry].[Item Ledger Entry Type],
[EMPRESA$Value Entry].[Source No_],
[EMPRESA$Customer].County,
[EMPRESA$Value Entry].[Item No_],
[EMPRESA$Value Entry].Description,
CAST ([EMPRESA$Value Entry].[Invoiced Quantity] AS MONEY) AS ‘CANTIDAD FACTURADA’,
CAST ([EMPRESA$Value Entry].[Cost Amount (Actual)] AS MONEY) AS ‘IMPORTE DE COMPRA’,
CAST ([EMPRESA$Value Entry].[Sales Amount (Actual)] AS MONEY) AS ‘IMPORTE DE VENTA’,
CONVERT(CHAR(10),[EMPRESA$Value Entry].[Posting Date],103)  AS ‘Fecha Venta’,
CAST (([EMPRESA$Value Entry].[Sales Amount (Actual)]+[EMPRESA$Value Entry].[Cost Amount (Actual)])*-1 AS MONEY) AS ‘Utilidad’
FROM         [EMPRESA$Customer] INNER JOIN
                      [EMPRESA$Value Entry] ON [EMPRESA$Customer].No_ = [EMPRESA$Value Entry].[Source No_]
WHERE     ([EMPRESA$Value Entry].[Item Ledger Entry Type] = 1)

image

Conectando la vista desde Excel al terminar el asistente aparecera la siguiente ventana de opciones

image

Si elegimos la opción de tabla dinámica y grafico dinámico directamente obtendremos los datos ya listos para seleccionar

image

Hasta aquí esta parte.

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