iDynamics SII - Ejemplos de personalización
Este documento predetende servir de guía para realizar las personalizaciones que serán más habituales en clientes.
Asignación autom. de datos de DUA
En el siguiente ejemplo hemos creado una Codeunit (en NAV2016 o NAV2017) suscrita al evento OnAfterAddDocument del informe 7141860 IDPSII Load Documents. Usamos dicho evento para que, cuando se cree un registro en la cola, asociado a una factura de compra, obtengamos y asignemos al registro de la cola los valores de DUA (número de DUA y fecha de registro) que hemos guardado en dos campos personalizados del cliente, IDP DUA No. e IDP DUA Posting Date, creados en la cabecera de factura de compra.
LOCAL [EventSubscriber] OnAfterAddDocument(VAR SiiDocument : Record "IDPSII Document")
WITH SiiDocument DO BEGIN
// Si el registro de la cola es una factura de compra, no rectificativa (no es un abono)
// recuperamos los datos de DUA que tenemos en dos campos personalizados de la factura de compra.
IF ("Document Type" = "Document Type"::"Received Invoice") AND ("Rectif. Type" = '') THEN BEGIN
IF PurchaseInvoice.GET("Invoice No.") THEN BEGIN
VALIDATE("DUA No.", PurchaseInvoice."IDP DUA No.");
VALIDATE("DUA Posting Date", PurchaseInvoice."IDP DUA Posting Date");
MODIFY(TRUE);
END;
END;
END;
En este caso, la validación de los campos de DUA del registro ya se encargará de modificar el código/tipo de factura que se envía a la AEAT. Como norma general, recomendamos realizar las modificaciones de valores del registro lanzando un VALIDATE, por si el valor de un campo tiene efectos secundarios en el resto de valores a enviar al SII.
Facturas simplificadas
Para indicar que una factura de venta, enviada a la AEAT, es simplficada, tan sólo es necesario modificar el valor del campo Invoice Type de la cola de documento de SII, para que su valor sea "F2" (o "R5", si es un abono). Una razón para que esto ocurra podría ser que la factura de venta esté asignada a un cliente particular configurado como "Venta al público", un check en la cabecera de factura de venta, o cualquier otro motivo.
No es necesario alterar el contenido de los campos de contraparte (que indican los datos del cliente al que se ha emitido la factura), ya que el propio iDynamics SII omitirá el envío de esta información.
Se presenta a continuación un ejemplo muy básico, para que sirva de punto de partida en cualquier cliente que requiera emitir este tipo de facturas.
LOCAL [EventSubscriber] OnAfterAddDocument(VAR SiiDocument : Record "IDPSII Document")
WITH SiiDocument DO BEGIN
// Obtenemos de alguna tabla de configuración el código del cliente de venta al público.
CashSalesCustomerCode := MetodoQueRecuperaElCodigo;
// Si el registro de la cola es una factura de venta, comparamos el código de cliente con un valor
// que corresponda al código del cliente de venta al público.
IF ("Document Type" = "Document Type"::"Issued Invoice") AND ("Rectif. Type" = '') THEN BEGIN
IF SalesInvoice.GET("Invoice No.") THEN BEGIN
IF SalesInvoice."Bill-to Customer No." = CashSalesCustomerCode THEN BEGIN
VALIDATE("Invoice Type", 'F2');
MODIFY(TRUE);
END;
END;
END;
END;
Si el cliente emite multitud de facturas al día, de tipo simplificada, es posible que prefiera enviar un resumen de las mismas, creando un único registro del tipo "F4" (resumen de facturas). Aunque no incluimos ningún ejemplo de código, ya que es un caso relativamente complejo que dependerá de las personalizaciones del cliente, para resolverlo sugerimos el siguiente planteamiento:
- Añadir el código anterior, para que las facturas simplificadas se marquen como "F2".
- Añadir un nuevo código al evento OnAfterLoadDocuments que recorra todas las facturas de la cola de envío, con tipo "F2", y acumule, en un único registro (por fecha) todos los campos de importe (campos 165, 180, 200, 201, y 240-294), eliminando los registros "F2" originales.
- Asignar a los campos Simplified Invoice From No. y Simplified Invoice To No. el valor de la primera y la última factura simplificada incluida en el resumen, y marcar el campo Simplified Invoice a TRUE (el VALIDATE de este último campo cambiará el tipo de factura a F4).
Facturas emitidas por terceros
Si se están enviando facturas emitidas por terceros, la tabla de documentos de SII 7141861 IDPSII Document contiene un campo llamado "Third Party", de tipo boolean, que permite indicar este hecho. Para asignarlo, la manera recomendada de proceder es suscribirse al evento OnAfterAddDocument, para recuperar la factura de origen y, si es de este tipo, asignar los valores correspondientes al registro de la cola.
Por ejemplo, suponiendo que hubiera un check NIF Emisor en la cabecera de las facturas de compra, este sería un posible código que implementaría la asignación:
LOCAL [EventSubscriber] OnAfterAddDocument(VAR SiiDocument : Record "IDPSII Document")
WITH SiiDocument DO BEGIN
// Si el registro de la cola es una factura de venta, recuperamos el NIF del emisor.
IF ("Document Type" = "Document Type"::"Issued Invoice") AND ("Rectif. Type" = '') THEN BEGIN
IF SalesInvoice.GET("Invoice No.") THEN BEGIN
IF SalesInvoice."NIF Emisor" <> '' THEN BEGIN
VALIDATE("Third Party", TRUE);
VALIDATE("VAT Issuer", SalesInvoice."NIF Emisor");
MODIFY(TRUE);
END;
END;
END;
END;
Indicar NIF del representante
La AEAT permite especificar el NIF del representante legal del cliente que recibe la factura emitida, del proveedor que emite la factura recibida, y de la propia empresa que presenta los datos a la AEAT. Para poder especificar esta información, se han agregado dos campos a la tabla 7141861 IDPSII Document: CP Legal Agent VAT No. y Legal Agent VAT No.. Dado que lo más habitual es que sea necesario indicar el representante legal del cliente o proveedor, vamos a incluir un ejemplo en el que se recupera el representante del cliente.
Nota: los campos que empiezan por CP se corresponden a los datos de la contraparte, que es el cliente en el caso de las facturas emitidas, y el proveedor en el caso de las facturas recibidas.
LOCAL [EventSubscriber] OnAfterAddDocument(VAR SiiDocument : Record "IDPSII Document")
WITH SiiDocument DO BEGIN
// Si el registro de la cola es una factura de venta, recuperamos el cliente, y de él
// recuperamos el representante legal, si existe ("NIF Representante" sería un campo
// personalizado que se habría agregado en la ficha del cliente).
IF ("Document Type" = "Document Type"::"Issued Invoice") AND ("Rectif. Type" = '') THEN BEGIN
IF SalesInvoice.GET("Invoice No.") THEN BEGIN
IF Customer.GET(SalesInvoice."Bill-to Customer No.") THEN BEGIN
IF Customer."NIF Representante" <> '' THEN BEGIN
VALIDATE("CP Legal Agent VAT No.", "NIF Representante");
MODIFY(TRUE);
END;
END;
END;
END;
END;
Tipo de identificador para clientes fuera de la UE
Por precaución, ya que hay múltiples maneras de identificar a clientes y proveedores, y no queremos asignar valores incorrectos, iDynamics SII sólo asigna de manera automática el tipo de identificación NIF Europeo (02), cuando el cliente está identificado como perteneciente a la UE en la configuración de IVA.
Si trabajamos con clientes/proveedores de fuera de la UE, no obstante, es probable que queramos asignar algún otro tipo de identificador de manera automática, para no tener que asignarlo manualmente en cada caso. El siguiente ejemplo asigna el tipo más habitual para estos casos Doc. emitido por país de residencia (04), pero es fácilmente modificable para asignar otro tipo, incluso pudiendo asignar el tipo en función de cualquier campo personalizado que se añada a la ficha del cliente/proveedor.
LOCAL [EventSubscriber] OnAfterAddDocument(VAR SiiDocument : Record "IDPSII Document")
RecConfEmp.GET;
WITH SiiDocument DO BEGIN
// Si el país está en blanco o es el de configuración de empresa lo consideramos Español.
IF (SiiDocument."CP Country Code" <> '') AND (SiiDocument."CP Country Code" <> RecConfEmp."Country/Region Code") THEN BEGIN
//Recuperamos el código de país
RecCountry.GET(SiiDocument."CP Country Code);
// Si no tiene código de país UE, lo consideramos 04
IF RecCounty."EU Country/Region Code" = '' THEN BEGIN
VALIDATE("CP VAT Identif. Type", "CP VAT Identif. Type"::"04");
MODIFY;
END;
END;
END;
Generación automática de operaciones de seguros
Para aquellos clientes que trabajen con operaciones de seguros, estas comunicaciones se pueden crear manualmente desde la cola de documentos de salida. Sin embargo, esta tarea puede ser laboriosa y, si el cliente cuenta ya con esta información almacenada en alguna tabla de NAV, su carga se puede automatizar. Para ello, recomendamos usar el evento OnAfterLoadDocuments, que se ejecuta al acabar el proceso estándar de carga de la aplicación.
A continuación se incluye un ejemplo de pseudo-código que explica como se generarían de manera automática este tipo de documentos, en el evento mencionado.
LOCAL [EventSubscriber] OnAfterLoadDocuments()
WHILE ALGO_ALGO_OBTEN_DATOS DO BEGIN
SiiDocument.INIT;
SiiDocument.SetInsuranceOperationDefaultValues();
// Un ID único que identifique la operación en este año.
SiiDocument.VALIDATE("Invoice No.",'ID1234');
// El año de la operación (si no se indica será por omisión el actual)
SiiDocument.VALIDATE("Fiscal Year", 2017);
// El importe de la operación.
SiiDocument.VALIDATE("Insurance Amount", 4500);
// El tipo de operación (si somos los emisores o receptores de la misma).
SiiDocument.VALIDATE("Insurance Operation Key", SiiDocument."Insurance Operation Key"::"B");
// El NIF (u otra identificación) de la contraparte
SiiDocument.VALIDATE("CP VAT No.", 'B97618573');
// El nombre de la contraparte.
SiiDocument.VALIDATE("CP Name", 'Cronus ES S.L.');
// El tipo de identificación (blanco equivale a NIF/CIF Español)
// https://docs.idynamics.es/es/sii/vatidtype.html
SiiDocument.VALIDATE("CP VAT Identif. Type", SiiDocument."CP VAT Identif. Type"::' ');
// El código de país (opcional si es España)
SiiDocument.VALIDATE("CP Country Code", 'ES');
// Una descripción opcional. Se puede omitir por completo, pero puede resultar
// útil si se quiere ofrecer alguna información adicional sobre la operación
// a los usuarios de NAV.
SiiDocument.VALIDATE("Operation Description",'Operación de seguros');
SiiDocument.INSERT(TRUE);
END;