IVA de CAJA y Modificaciones en el Modelo 340 para NAV


Hola a todos,

Queremos informaros sobre las novedades para IVA de CAJA en NAV.

Como sabéis, dicha funcionalidad implicará una serie de cambios en el Modelo 340 y algunos informes de la aplicación, así como la configuración y uso del IVA no Realizado.

Queríamos daros unas pinceladas para que sepáis más o menos cómo funciona y cómo tendrán que usarlo vuestros clientes.

 

¿Dónde puedo descargar la funcionalidad?

NAV2009SP1/R2:

PartnerSource:  https://mbs.microsoft.com/partnersource/spain/deployment/downloads/tax-regulatory-updates/MSDNAV2009sp1VATdec340Spain

CustomerSource:  https://mbs.microsoft.com/customersource/spain/NAV/downloads/tax-regulatory-updates/MSDNAV2009sp1VATdec340Spain

 

NAV2013:

PartnerSource: https://mbs.microsoft.com/partnersource/spain/deployment/downloads/tax-regulatory-updates/MSDNAV2013VATdec340Spain

CustomerSource: https://mbs.microsoft.com/customersource/spain/NAV/downloads/tax-regulatory-updates/MSDNAV2013VATdec340Spain

 

NAV2013R2:

PartnerSource: https://mbs.microsoft.com/customersource/spain/nav/downloads/tax-regulatory-updates/MSDNAV2013r2dec340vatSpain

CustomerSource: https://mbs.microsoft.com/partnersource/spain/deployment/downloads/tax-regulatory-updates/MSDNAV2013r2dec340vatSpain

 

¿Debemos instalarlo en todos nuestros clientes?

Todos los clientes se verán afectados, ya que se han añadido nuevos campos que con el Modelo 340 antiguo no obtendremos correctamente. Dichos campos deben ser exportados vacíos/con ceros para los clientes que no trabajen con IVA de Caja.

Además no se podrá usar la opción de exportar Trimestralmente, solamente Mensualmente.

 

¿Existen Pre-requisitos antes de instalar esta funcionalidad en NAV?

Sí, es imprescindible que os instaléis previamente:

-         Actualización del IVA 2010.

-         Actualización del Modelo 340 – 2011.

-         Última actualización del Modelo 340 – Agosto 2012.

 

¿Qué objetos han sido modificados?

Se han modificado los siguientes objetos en ambas versiones:

 

¿Cambios que vienen para NAV en esta funcionalidad de IVA de CAJA?

Para aquéllos clientes que se acojan a este nuevo Régimen de IVA de Caja, tendremos que tener en cuenta lo siguiente:

-         Ya no estará disponible la opción de reporte Trimestral, solo Mensual.

-         Tendremos que configurar correctamente el IVA no Realizado y Grupos de Registro de IVA.

-         El IVA no se realizará en el momento de Registrar el documento (factura, abono…) sino que el IVA se realizará en el momento del Pago.

-         Tendremos que configurar los nuevos Código de Operación (“Z” y los opcionales 1..8).

-         Los Códigos de Operación “Z” (operación genérica de IVA de CAJA), 2 (operación de IVA de CAJA para Facturas con varios asientos – diferentes tipos impositivos) y 3 (operación de IVA de Caja para Facturas Rectificativas) serán automáticamente identificadas por NAV. El usuario podrá modificar dichas claves manualmente en la ventana preliminar (Líneas del Modelo 340), pero solo estas 3 serán soportadas en el estándar.

-         Los informes listados anteriormente se han modificado para mostrar el Texto “Régimen especial del criterio de caja” en caso de que nuestros documentos usen IVA no realizado.

 

Configuración Necesaria:

Para configurar el IVA no Realizado, tendremos que ir a Configuración de Contabilidad (Gestión Financiera/Configuración/Configuración de contabilidad):

 

Para crear un nuevo Grupo Registro de IVA para RECC, tendremos que ir a Config. Grupos registro de IVA y configurar grupos contables de manera similar a la que sigue (Gestión Financiera/Configuración/Grupos registro IVA):

-         Tipo IVA no realizado: Porcentual (esta es la única opción válida con Cartera)

-         Rellenar las cuentas de IVA no realizado necesarias (las del ejemplo son ficticias de los datos demo, tendríais que usar las vuestras y diferentes para cada tipo).

 

 

Y para configurar los nuevos Códigos de Operación para RECC, tenemos que ir a la ventana de Códigos de Operación (Gestión Financiera/Configuración/General/Códigos de operación):

 

 

Ejemplo de USO:

Para clientes no acogidos al régimen de IVA de Caja, el modo de uso sigue siendo el mismo que hasta la fecha. La única modificación es que ya no es posible el reporte Trimestral, solo mensual (e internamente que los nuevos campos serán exportados sin valores).

Para clientes acogidos al régimen de IVA de Caja, tendremos que seguir los pasos de configuración listados anteriormente (IVA no realizado, Grupos de Registro de IVA para IVA no realizado y añadir los nuevos Código de Operación para RECC).

Una vez tengamos esto listo, para Ventas y Compras funcionará del mismo modo:

  1. Tendremos que registrar nuestra Factura Emitida/Recibida, pero usando el Grupo Registro IVA configurado para IVA no Realizado que necesitemos. Ejemplo:

          Registramos una Factura el 15 de Enero 2014 para el cliente RECC, usando NR21NOR (IVA no realizado, 21%, Tipo Cálculo IVA: Normal)

 

2. Veremos en el Movimiento de IVA registrado, que el IVA se muestra a 0. Esto es así porque el IVA no será realizado en el momento de emitir/recibir la Factura, sino en el momento de
Enviar/Recibir el Pago.

3. Si exporto el Modelo 340 para Enero 2014, veré una línea para mi Factura con IVA no realizado:

 

NOTA: No exportamos la información sobre “Base Imponible”, “Tipo Impositivo”, “Importe Total de la Factura”, etc…pues pensamos que es cómo debería funcionar. Si Hacienda cambia los requerimientos y fuera necesario, lo reportaríamos para que fuera solucionado, pero tiene más sentido que no se declaren aquí dichos importes, pues si exportamos Factura y Pago el mismo mes…los importes totales del Registro Tipo 1 pudieran duplicarse. Además las Facturas con IVA no realizado se han exportado desde NAV así anteriormente y no hemos obtenido queja. Cualquier cosa, por favor nos comentáis.

 4. Imaginemos que no Emitimos/Recibimos el importe de esa factura en Enero, sino que lo hacemos en Febrero. Tendremos por tanto un Pago que “realizará” nuestro IVA de la factura de Enero, en Febrero. Hasta ese momento el IVA pasará a estar realizado.

           Ejemplo: Pago el día 25/02/2014 a través de Diario para el Cliente RECC, liquidando por Nº documento la Factura anterior:

 

5. Ahora voy a los Movimientos de IVA relacionados con el PAGO. Si Navego veré que el IVA efectivamente se ha realizado.

 

 

Y si exporto el Modelo 340 para Febrero, veré que tengo mi Factura de nuevo (que corresponde con el Pago en NAV) exportado con “Clave de Operación” = “Z” (RECC), relacionado con el Nº documento inicial (Factura), y que informa a Hacienda con los 4 nuevos últimos
campos:

  • Fecha pago
  • Importes pagados
  • Medio de pago utilizado
  • Cuenta bancaria o medio de pago utilizado

 

La “Fecha Emisión” y “Fecha Operación” deben corresponder con la de la Factura inicial (o eso tenemos entendido según Hacienda).

NOTA: Hay un bug en la Herramienta de validación de Hacienda actualmente (o eso nos han confirmado esta tarde al teléfono) que no permite seleccionar Enero como Fecha de Emisión y un mes posterior (Feb, Marzo…) como Fecha de Pago. Si debería permitirlo y nos han confirmado que se solucionará. De hecho si probáis con una Factura de Febrero, y un Pago de Marzo si os dejará, por lo que es un bug en la herramienta de validación).

 

Comentarios adicionales:

-         Si el cliente ha efectuado Pagos en Efectivo (solo Clientes), estos serán incluidos también en la línea de Pagos en Efectivo exportada desde el Modelo 340.

(Recordar que debéis informar los campos “Importe Pago mín.” y “Cuenta para pagos en efectivo” en el Request Form/Page:

 

-         Si el cliente ha usado un Grupo Registro IVA con IVA de reversión e IVA no realizado (Servicio UE) - Inversión del Sujeto Pasivo, entonces la Clave de Operación para la FacturaRECC inicial, será “I”, pero cuando el IVA se realice, en el momento del Pago será “Z”.

-         Si el cliente ha hecho una Devolución/Abono con IVA no Realizado (RECC), la clave de Operación será la habitual (“D”) para el Documento inicial, pero el PAGO será reportado con la “Clave de Operación” = "3"

-         Si el cliente ha hecho una Factura con varios asientos y diferentes Tipos impositivos (%IVA), la factura Inicial será reportada como (“C”), pero el PAGO será reportado con la “Clave de Operación” = "2".

-         Si seleccionamos un “Grupo reg. prod. Gen. no deducible” en el Request Form/Page, las Facturas de Compra que incluyan líneas con dicho Grupo de registro serán excluidas de cálculo para la “Cuota Deducible” (solo Proveedores)

-         Recordar también que podéis automatizar la generación de Claves de Operación “opcionales” incluyendo la Clave de Operación específica para vuestros “Grupos contables productos”:

 

Cuando se exporte el Modelo 340 y contemos con registros para estos Grupos Contables, se tendrán en cuenta en las Líneas Modelo 340 propuestas, a excepción de las claves automáticas por sistema: “C”, “D”, “I”, “Z”, “2” y “3”. (esas prevalecerán).

 -         Podréis cambiar las Claves de RECC en las Líneas Modelo 340, pero solamente entre las posibles “Z” y “1..8”. No podremos cambiar una línea con clave “Z”, "2" o "3" automática para que sea Clave <> “Z” o “1..8”.

 

Herramienta Validación Modelo 340 – AEAT:

Las pruebas realizadas han sido testeadas con esta herramienta offline proporcionada por la AEAT para el Modelo 340:

http://www.agenciatributaria.es/AEAT.internet/Modelos_formularios/modelo_340.shtml

Programa de ayuda – Programa con formulario 2014 (últimas pruebas realizadas el día 17 de Febrero 2014, a expensas de que pueda ser volver a modificada por Hacienda).

 

Problemas/Errores conocidos/Escenarios no soportados/pospuestos:

Hay varias cosas que desde Desarrollo se listan como errores/problemas conocidos:

-        Debido a incongruencias entre la documentación recibida por Hacienda y la herramienta de validación, algunos escenarios pueden estar sujetos a cambio si fuera necesario. Si encontráis algo que se está exportando/reportando de manera incorrecta, hacérnoslo saber por favor. (por ejemplo ahora reportamos la factura original con IVA no Realizado con Importes en blanco, y el Pago donde el IVA ya se ha realizado. Puede que las facturas no sean requeridas finalmente y solo sea requerida la línea donde el IVA se realiza, o que las Facturas
iniciales requieran más información. Seguimos a la espera de clarificación en este sentido).

-        Si hubiera algún informe adicional que debiera ser modificado, en principio será labor del partner modificarlo siguiendo el patrón de los que ya se proporcionan (en principio este texto es lo único que se ha añadido para identificarlos).

-        Los Libros de Facturas Emitidas y Recibidas no han sido modificados para esta Ley, y no están soportados en el estándar.

-        Pagos hasta el 31 de Diciembre del año inmediatamente posterior (Pospuesto. Será revisado antes de finales de año)

-        Los Pagos deben Liquidar Facturas. Si no están liquidados no aparecerán en el 340. En el momento de liquidar dicho pago contra la Factura, será cuando el IVA se realice, y la información se muestre en el Modelo 340.

-        Solamente serán válidos los pagos que liquiden factura (en 1 línea usando “Liq. Por Nº documento”. Escenario de pagos en 2 líneas están fuera del alcance)

-        Las Claves de Operación Automáticas para RECC en NAV serán “Z” (genérico para operación de IVA de CAJA), “2” para Facturas con diferentes tipos impositivos con IVA de CAJA y “3” Facturas Rectificativas con IVA de CAJA. Las demás (1, 4, 5, 6, 7 y 8) podrán ser configuradas y asignadas por el usuario, pero no soportadas en el estándar.

 

ERRORES CONOCIDOS IVA NO REALIZADO con CARTERA (NAV2009Sp1/R2)

Existen varios errores reportados y ya corregidos en NAV2013 para IVA no Realizado y Cartera.

Para algunos ya existe el KB Article correspondiente. Para un par de ellos aún está por ser publicado. Por favor tenerlo en cuenta si usáis alguno de los siguientes escenarios. Podéis por favor contactar con nosotros a través de soporte si necesitáis los que no contienen aún un KB article o no podéis acceder a ellos en PartnerSource:

  • TFS 289612 - Error with Unrealized VAT and Apply payment (KB 2664615)
  • TFS 311131 - Wrong posting with Unrealized VAT and Cartera - Sales and Purchases (KB 2710220)
  • TFS 317759 - Apply Bills with Unrealized VAT - Wrong Amounts in VAT Entry for Sales and Purchase's sides (KB 2739839)
  • TFS 345207 - Settle bills in Posted Payment Orders with Reverse Charge VAT & Unrealized VAT does not work as settle bills from Payment Journal. 
  • TFS 354421 - Incorrect VAT entries after posting Credit Memo that applies an Invoice with Unrealized VAT after implementing KB 978857. 

Espero que os haya servido de ayuda esta información para empezar a usar esta funcionalidad e implementarla en vuestros clientes.

Ya sabéis que cualquier cosa, estaremos encantados de ayudaros a través de Soporte.

Saludos y hasta pronto!;

Vanessa.

 


Comments (36)

  1. Javier says:

    Simplemente indicados que desde hacienda se me transmito que tanto en la factura como en los pagos deben aparecer los datos de importes y bases de la factura y eso mismo les indicaron a mis clientes.

    Creo recordar que esta respondido en la sección de preguntas frecuentes de hacienda pero ahora no tengo el link

    Comparto vuestras quejas respecto a hacienda

    saludos

  2. Javier says:

    http://www.agenciatributaria.es/…/_Como_se_declaran_las_operaciones_sometidas_al_RECC_en_el_modelo_340_.shtml

    Os dejo el enlace

    indica que las facturas deben incorporarse normalmente como si no se le hubiese aplicado el iva de caja completándose la información  en el momento del pago añadiendo nuevos registros lógicamente

    Saludos

    Por cierto creo que la configuración no es  correcta, en mi opinión hay que crear grupos de iva

  3. Luis says:

    ¿Alguna noticia para las versiones anteriores a la 2009?

  4. Rubén Seco - CIC says:

    Buenas, una pregunta sencilla.

    1. Si un cliente No va a utilizar el IVA de Caja, pero si presenta el modelo 340 ¿Tendremos que aplicar todos los cambios que nos habéis proporcionado? Entiendo que SI (según lo que esplicais en este post)

    2. Si un cliente No va a utilizar IVA de Caja y no presenta el Modelo 340. ¿No hará falta implementar todos estos cambios?

    Muchas gracias

    Un cordial saludo

  5. sonia says:

    yo viendo estos datos nos surge una duda.

    La casuística que más se está dando es que tenemos clientes que sin estar acogidos tienen facturas de Proveedores que si están en este Régimen, por lo que se ven afectados indirectamente.

    Cuando se registra en Navision la factura de compra con IVA no realizado para contemplar este tema, el sistema le lleva a Mov IVA BASE Y CUOTA y aquí en el ejemplo DE VENTAS no lo hace asi.

    Se ha cambiado la funcionalidad del IVA NO REALIZADO ya que esto no nos cuadra

  6. Buenos días,

    gracias por vuestros comentarios. La verdad es que está siendo todo un reto con la información proporcionada por Hacienda.

    De hecho hoy la herramienta se ha vuelto a modificar, ahora permite tener registros tipo "Z" sin tener que rellenar los 4 nuevos campos de pago, y el problema que os comentábamos ayer de la Fecha para Enero que salía como error, ya no sale como error. Como veis…muy entretenido :-).

    Y las conversaciones con Hacienda de ayer fueron surrealistas (nos colgaron 4 veces) y no sabían confirmarnos nada de lo que preguntábamos :-).

    . Javier: Esto como ves en los comentarios, ya lo estuvimos evaluando. Llamamos a Hacienda y nos dijeron que aún no se sabía exactamente cómo proceder y que se haría un comunicado oficial.

    Hemos estado haciendo además ejemplos en la herramienta de validación, y si tenemos la Factura y Pago en Enero ambos por ejemplo, e informamos los importes tanto para la Factura como para el Pago, vemos en el Registro 1 (Resumen), que los importes totales salen duplicados, con lo cual se decidió seguir exportando las Facturas iniciales como hasta el momento.

    Hemos reportado no obstante esto a Desarrollo para que lo sigan analizando hasta que haya un requerimiento legal claro y firme.

    Además Javier, sobre los Grupos de IVA si, tenéis que crear nuevos como veis arriba en el ejemplo (las líneas azules son la configuración necesaria para los nuevos registros de IVA creados. En el ejemplo: NR21NOR, NR10NOR y NR4NOR.

    – Luis: No se van a publicar objetos anteriores a versión NAV2009, puesto que las anteriores están fuera del ciclo de soporte. Estamos pendientes de los objetos para NAV2013, pero para versiones anteriores, deberéis hacer vosotros las adaptaciones guiándoos por los objetos de NAV2009.

    – Rubén: Si un cliente no usa el IVA de CAJA:

    * Si va a usar el Modelo 340: Si necesitaríais los objetos actualizados

    * Si no va a usar el Modelo 340: No necesitará la actualización.

    – Sonia: La funcionalidad del IVA no Realizado no se ha modificado, tan solo la exportación del Modelo 340 para contemplar RECC.

    Los importes en los Movs de IVA son 0 hasta el momento en que la Factura se Paga. Si navegas sobre el Movimiento de Pago con que has liquidado la Factura, verás que la Base e Importe de IVA se realizan y toman los valores correspondientes. Hasta que la Factura no se ha liquidado por un Pago, el movimiento de IVA asociado tiene Base e Importe a cero.

    Saludos!,

    Equipo MS Dynamics NAV.

  7. Rubén Seco - CIC says:

    Otra duda para ver si me podeis aclarar.

    Si un cliente, usa modelo 340 pero no tiene IVA de Caja, hay que ponerle los cambios que nos estais dando. ¿Pero hay que ponerlo todo?

    Lo pregunto porque veo que retoca todos los informes de documentos comerciales y lo normal es que cada cliente tenga los suyos personalizados en otro rango de objetos, como pueden ser 50000..50099.

    Es decir,los documentos comerciales que se han modificado, influye a Iva de caja solamente? o influye a todo?

    Muchas gracias

    Un saludo

  8. Hola Rubén!,

    En los Informes la única modificación que se ha hecho ha sido añadir el texto “Régimen especial del criterio de caja” en el caso de que se use IVA no Realizado.

    Entonces no sería necesario modificar estos informes si el cliente no está acogido a este régimen.

    La única excepción sería que esa empresa NO acogida al Régimen de IVA de Caja recibiera facturas de un Proveedor que SI esté acogido a este régimen. En ese caso tanto el Modelo 340, como los informes (los proporcionados por Microsoft) o los vuestros en rango de cliente, deberían contener este texto.

    Saludos,

    Equipo MS Dynamics NAV.

  9. Rubén Seco - CIC says:

    Buenas de nuevo,

    Me ha quedado clara la explicacion que me habeis proporcionado de los dos Post que he puesto, pero todavia necesito saber lo siguiente:

    – Un cliente que no va a utilizar IVA de Caja. Tampoco tiene ningun proveedor que se va a acoger a Regimen de IVA. Pero SI presenta el modelo 340 y necesita presentarlo mañana.

    ¿Que cambios de todos los que nos dais en la version 2009 (objetos) tengo que realizar para poder cambiarle el modelo 340?

    Muchas gracias

    Un saludo

  10. Hola Rubén,

    Si tiene que presentar el Modelo 340 solamente:

    – Tabla 10744

    – Tabla 10745

    – Form 10744 (si utiliza cliente Clásico)

    – Página 10744 (si utiliza cliente Roles)

    – Report 10743

    Los informes no son necesarios.

    Además, si tiene operaciones con Inversión del Sujeto Pasivo de Servicios (IVA Reversión + “EU Service”) tendréis que tener antes el VAT2010 instalado.

    Si no lo usa, os lo podéis saltar como pre-requisito (pero hay que comentar la siguiente línea en el Report 10743 para que no os de errores de compilación (función GetOperationCode):

    IF CheckVATType(VATEntryRec) THEN

     EXIT('C');

    IF ((VATEntryRec.Type IN [VATEntryRec.Type::Purchase,VATEntryRec.Type::Sale]) AND

     (VATEntryRec."VAT Calculation Type" = VATEntryRec."VAT Calculation Type"::"Reverse Charge VAT")

     // AND VATEntryRec."EU Service")   <– esta línea

    THEN

     EXIT('I');

    Ese campo "EU Service" solamente estará en NAV2009Sp1/R2 tras implementar VAT2010.

    Dime si esto te ayuda, vale?

    Un abrazo!;

    Equipo MS Dynamics NAV

  11. jalopez says:

    Al verlo diferenciado, entiendo que los objetos de la 2013 no son válidos para 2013 R2 ¿no? ¿El "expected tomorrow" se refiere a hoy día 19 o a tomorrow día 20? 😉

    Saludos y gracias.

  12. Hola jalopez :-),

    se esperan mañana día 20 para la versión NAV2013R2.

    De todos modos no se esperan cambios con respecto a la versión anterior (NAV2013) en principio, pero tendremos un fob y publicación separados también.

    Saludos,

    Equipo MS Dynamics NAV.

  13. Hola a todos. Os planteo una duda que tenemos.

    ¿Por qué se ha descartado la opción Trimestral? Según se indica en la página de la AEAT, el periodo de declaración puede ser mensual o trimestral.

    http://www.agenciatributaria.es/…/_Cual_es_el_periodo_de_declaracion_del_modelo_340_.shtml

    ¿Existe alguna incompatibilidad con lo que ya había desarrollado en el modelo anterior o se publicará alguna modificación llegados al mes de Abril?

    Saludos.

  14. Hola Juanmi :-),

    supongo que en Desarrollo se han guiado por los cambios para este año según el siguiente link:

    http://www.agenciatributaria.es/…/Nuevo_modelo_303_y_modificacion_de_los_modelos_340_y_349__Orden_HAP_2215_2013__de_26_de_noviembre__BOE_del_29_.shtml

    Ahí veo este párrafo:

    << – Se modifica la descripción del campo “PERIODO” para eliminar los periodos trimestrales como consecuencia de la reducción del ámbito subjetivo de la obligación informativa sobre las operaciones incluidas en los libros registros, que se limita a los sujetos pasivos del IVA y del IGIC inscritos en el registro de devolución mensual. (Apartado 1 del artículo 36.2 Real Decreto 1065/2007).>>

    Según tu link :-), nos tendrán que habilitar el periodo Trimestral de nuevo para el año que viene si ;-), jajaja.

    Gracias y saludos!;

    Equipo MS Dynamics NAV.

  15. Pues está bastante claro…. De hecho, en la herramienta de validación, en la columna Periodo no aparecen las opciones trimestrales como sí ocurría en el modelo de 2013, y lo que más nos preocupa es que muchos de nuestros clientes nos dicen que ellos hacen declaración trimestral.

    En fin, ya veremos…

    Gracias.

  16. Hola a todos,

    hemos detectado un pequeño problemilla, en el caso de tener Facturas con Importe = 0, SIN régimen de IVA de CAJA y usando los nuevos objetos.

    Anteriormente si exportábamos las facturas con Importe = 0, pero con este desarrollo parece que hay 2 líneas que las excluyen del fichero (aun no tenemos claro si debería exportarlas o no, creemos que si).

    Hasta que lo clarifiquemos, os damos el lugar exacto donde se excluyen, por si las queréis incluir de nuevo, y porque si se os da este escenario, el Nº registros total de Tipo Registro 1 será incorrecto, al no exportar las facturas pero sí contabilizarlas:

    Ejemplo: 10 facturas normales, y 2 con Importe = 0.

    En el Registro Tipo 1 de Resumen nos exportará Nº registros = 12, mientras que tendremos solamente 10 líneas en el fichero.

    Con el siguiente cambio, obtendréis 12 registros, y 12 líneas en el fichero incluyendo las Facturas con Importe = 0:

    VATEntry – OnAfterGetRecord()

    VATBuffer.DELETEALL;

    CASE Type OF

     Type::Sale:

       BEGIN

         // SkipZeroCustLedgEntry("Transaction No."); // <– comentar esta linea

         IF "Unrealized VAT Entry No." <> 0 THEN

           SkipUnappliedCustLedgEntry("Transaction No.");

         BookTypeCode := 'E';

       END;

     Type::Purchase:

       BEGIN

         // SkipZeroVendLedgEntry("Transaction No."); // <– comentar esta linea

         IF "Unrealized VAT Entry No." <> 0 THEN

           SkipUnappliedVendLedgEntry("Transaction No.");

         BookTypeCode := 'R';

       END;

    END;

    En cuanto clarifiquemos si deberían o no exportarse, lo reportamos a desarrollo para que este cambio se haga oficial, o bien nos arreglen el Nº de registros y que las excluya :-), vale?

    Saludos!,

    Equipo MS Dynamics NAV

  17. SONIA says:

    Según el desarrollo- por medio de un cliente nuestro y hablando con Hacienda- se nos están dando dos situaciones que no se harían bien con este desarrollo para el caso de facturas de compra donde el Proveedor se ha acogido al régimen de criterio de caja. PODRIAS CONFIRMAR ESTOS DOS CASOS.

    SITUACION 1.  factura  de compra de Enero con pago en Enero. El sistema crea dos registros y según nos marcan solo debería ser uno.

    *Se crea un registro para la factura con clave vacía e importes cero

    *Se crea un segundo, el del pago con clave Z y los importes rellenados además de los campos propios del pago.

    según hacienda solo tiene que ir el segundo. El primer registro No debería ir.

    SITUACION 2. factura  de compra de Enero SIN pago en Enero.

    El sistema crea un registro

    *Se crea un registro para la factura con clave vacía e importes cero

    según Hacienda la clave tiene que ser Z y nosotros por el sistema estamos llevándolo vacío como operación normal, SI seria correcto no poner importes.

    Esto es lo que nos ha dicho nuestro cliente, lo hemos comprobado con Hacienda y hasta aquí os podemos indicar. podéis por favor por vuestra parte comprobarlo y nos decís.

  18. Buenos días Sonia!,

    muchas gracias por compartir esta información con nosotros.

    Como veis, hay mucha diversidad de opiniones. Desde Soporte hemos llamado a Hacienda en multitud de ocasiones y cada vez nos dicen una cosa, con lo cual no queda claro cómo proceder porque cada persona que nos atiende tiene una manera de interpretar la ley. Incluso una mujer nos admitió que no tenían formación del Modelo 340 :-).

    Ayer nos confirmó un partner que las facturas SI deben llevar importes, luego otro que no, ahora que las facturas si se crean y pagan en el mismo mes, no deberían aparecer… 🙂 con lo cual necesitamos una confirmación "oficial" y en la misma línea donde quede claro finalmente cómo proceder y qué se espera desde Hacienda.

    Desde nuestro punto de vista, con toda la confusión que se está creando, esta primera declaración no debería ser vinculante, pero si lo fuese, los datos que nosotros estamos emitiendo no adulteran para nada los importes que declaramos, con lo cual en este sentido estaríamos cubiertos (ya que nuestras facturas se reportan sin importes).

    Si en cualquier momento tenéis una consulta vinculante escrita por parte de Hacienda con una confirmación "oficial" al respecto, por favor no dudéis en hacérnosla llegar para escalarlo a Desarrollo y proceder a la modificación de la funcionalidad, finalmente con los requerimientos 100% claros.

    Muchas gracias a todos, y sentimos toda esta confusión,

    Esperamos que se "aclare" todo pronto :-),

    Saludos,

    Equipo MS Dynamics NAV.

  19. Laura says:

    Buenos días,

    tenemos un caso de un cliente que no está acogido a RECC, pero recibe una factura de un proveedor que tampoco esta acogido a RECC pero se aplica IVA no realizado. LA factura y el pago son de enero ambas.

    En el modelo 340:

    – la factura sale sin importes y con clave operación en blanco

    – ¿Por qué el pago sale con clave de operación Z si no es RECC?

    Un saludo

  20. Laura says:

    Hola,

    Gracias por la sugerencia de ayer, aunque consideramos que no puede ser una solución definitiva, ya que tenemos el caso de que un cliente no esta acogido al régimen de IVA de caja, pero puede recibir facturas de un proveedor que sí que lo esta. Pero a la vez puede recibir otras facturas de otro proveedor que no está acogido al IVA de caja, pero que sí que emplea IVA no realizado. Y con esta solución todas las facturas de IVA no realizado se considerarían como IVA de caja cuando no lo son.

    Quedamos a la espera de una modificación oficial.

    Saludos y gracias.

    Laura.

  21. Buenos días Laura,

    hemos eliminado la sugerencia anterior para que no sea confuso.

    Hemos estado evaluando otra posible "SUGERENCIA NO OFICIAL" que creemos que se adapta más a las necesidades que planteas, pero requiere de configuración previa de los Grupos Contables Generales.

    La idea es que igual que podemos configurar una Clave de Operación en la Configuración de Grupo Contable de Producto, podamos marcar ahí si ese Grupo Contable será utilizado para IVA de CAJA o no.

    Si ese nuevo campo booleano "Régimen IVA de Caja" NO está marcado, se exportará el IVA no Realizado sin los requerimientos propios del IVA de CAJA (es decir, sin "Z" en el pago sino blanco, y sin informar de los nuevo campos de información del Pago).

    Os ponemos los cambios a continuación, los cuales hemos sugerido a Desarrollo para su validación y confirmación en caso de que este escenario sea aceptado. Si no, esperamos que al menos esta sugerencia os sirva de ayuda.

    CREAR los siguientes 2 nuevos campos (vosotros usar otro ID válido en vuestra licencia)

    1. Nuevo campo "Régimen IVA de Caja" en la Tabla 251 – Gen. Product Posting Group

    Enabled Field No. Field Name Data Type Length Description

    Yes 6 VAT CASH Regime Boolean  

    2. Nuevo campo "Régimen IVA de Caja" en la Tabla 10744 – 340 Declaration Line

    Enabled Field No. Field Name Data Type Length Description

    Yes 39 VAT CASH Regime Boolean  

    Continua en otro post….

  22. continuación sugerencia…

    Y realizar los siguientes cambios en el Report  10743 – Make 340 Declaration

    3. Nueva variable GLOBAL:

         FilterArray@1100109 : ARRAY [50] OF Text[30];

         FileHeaderCreated@19078656 : Boolean;

         FileNameTextBoxVisible@19077241 : Boolean INDATASET;

         PrevDeclarationNumEnable@19078655 : Boolean INDATASET;

         VATCASHRegime@1170000000 : Boolean;    <<<************ Nueva variable

    4. Limitar el uso de "Z", "2" or "3" solo cuando "Régimen IVA de CAJA" = TRUE en la tabla 251 – Gen. Prod Posting Group.

       PROCEDURE GetOperationCode@1100016(VATEntryRec@1100000 : Record 254) : Text[1];

       VAR

         GenProdPostingGroup@1100001 : Record 251;

       BEGIN

         IF VATEntryRec."Document Type" = VATEntryRec."Document Type"::"Credit Memo" THEN

           EXIT('D');

         IF VATEntryRec."Unrealized VAT Entry No." <> 0 THEN BEGIN

           // VANE.BEGIN   <<<************ Nueva código BEGIN

           IF GenProdPostingGroup.GET(VATEntryRec."Gen. Prod. Posting Group") THEN

             IF GenProdPostingGroup."VAT CASH Regime" THEN BEGIN

           // VANE.END   <<<************ Nueva código END

               IF CheckVATType(VATEntryRec) THEN

                 EXIT('2');

               CASE VATEntryRec."Document Type" OF

                 VATEntryRec."Document Type"::Payment:

                   EXIT('Z');

                 VATEntryRec."Document Type"::Refund:

                   EXIT('3');

               END;

            // VANE.BEGIN

            END;   <<<************ Nuevo código

            // VANE.END

         END;

    5. Obtener información de si usamos "Régimen IVA de Caja" o no para cada Línea de IVA para copiar esta información a la tabla Temporal del 340: tabla 10744 – 340 Declaration Lines (Añadir variable GenProdPostingGroup):

    – VATEntry2 – OnAfterGetRecord

           OnAfterGetRecord=VAR

                              GenProdPostingGroup@1170000000 : Record 251;

                            BEGIN

                              OperationCode := GetOperationCode(VATEntry2);

                              // VANE.BEGIN <<<************ Nueva código BEGIN

                              VATCASHRegime := FALSE;

                              IF GenProdPostingGroup.GET(VATEntry2."Gen. Prod. Posting Group") THEN

                                IF GenProdPostingGroup."VAT CASH Regime" THEN

                                  VATCASHRegime := TRUE;

                              // VANE.END  <<<************ Nueva código END

                              VATBuffer."VAT %" := "VAT %";

                              VATBuffer."EC %" := "EC %";

                              VATBuffer."EC Amount" := 0;

    continúa en el siguiente post….

  23. …continuación sugerencia…

    6. Limitar el informar o no de los nuevos campos de Pago, solo si "Régimen IVA de CAJA" ha sido utilizado para esa línea de IVA en concreto. Se modifica en 2 funciones:

    – WriteDeclarationLinestoText

               txt := PADSTR(txt,500,' ');

               // VANE.BEGIN    <<********* añadir código BEGIN

               IF DeclarationLine."VAT CASH Regime" THEN

               // VANE.END     <<********* añadir código END

                 AddUnrealizedCollectionInfo(DeclarationLine,txt);

               Outstr.WRITETEXT;

               Outstr.WRITETEXT(txt);

             UNTIL NEXT = 0;

         END;

       END;

    – WriteAppliedPaymentsToText

               txt := PADSTR(txt,500,' ');

               // VANE.BEGIN  <<********* añadir código BEGIN

               IF DeclarationLine."VAT CASH Regime" THEN

               // VANE.END    <<********* añadir código END

                 AddUnrealizedCollectionInfo(DeclarationLine,txt);

               Outstr.WRITETEXT;

               Outstr.WRITETEXT(txt);

             END;

           UNTIL CustomerCashBuffer.NEXT = 0;

       END;

    7. Añadir información sobre si usamos IVA de CAJA o no para cada registro de IVA, en el momento de escribir las líneas temporales del 340:

         TempDeclarationLines.Type := VATEntry.Type;

         TempDeclarationLines."Unrealized VAT Entry No." := UnrealizedVATEntryNo;

         TempDeclarationLines."Bank Account Ledger Entry No." := FindPaymentInformation(TransactionNo);

         // VANE.BEGIN  <<********* añadir código BEGIN

         TempDeclarationLines."VAT CASH Regime" := VATCASHRegime;

         // VANE.END     <<********* añadir código END

         TempDeclarationLines.INSERT;

       END;

    Esperamos que con esta sugerencia obtengáis correctamente la información,

    Saludos,

    Equipo MS Dynamics NAV

    **************************************************

    Disclaimer

    Because some jurisdictions do not allow the exclusion or limitation of liability for consequential or incidental damages, the limitation and disclaimer set out below may not apply.

    ACCEPTANCE AND DISCLAIMER OF WARRANTY

    The software contained in this communication is provided to the licensee “as is” without warranty of any kind. The entire risk as to the results, usefulness and performance of the software is assumed by the licensee. Microsoft disclaims all warranties, either express or implied, including but not limited to, implied warranties or merchantability, fitness for a particular purpose, correspondence to description, title and non-infringement. Further, Microsoft specifically disclaims any express or implied warranties regarding lack of viruses, accuracy or completeness of responses, results, lack of negligence, and lack of workmanlike effort, for the software.

    ************************************************************************

  24. Laura says:

    Hola de nuevo,

    estuvimos analizando la solución que nos pasasteis en relación a diferenciar los casos de régimen de caja e IVA no realizado y tenemos una pregunta al respecto.

    ¿Por qué el nuevo campo booleano lo incluís en Grupo contable producto?, si no entiendo mal, un mismo producto yo puedo venderlo o comprarlo en ambas situaciones, si bien quien me marca si se acoge o no al régimen de caja es el cliente o proveedor.

    No se si el incluirlo en grupo contable producto es por algo que se nos está escapando, ¿podrías aclarárnoslo?

    Muchas gracias y saludos

  25. Hola Laura!,

    te contestamos:

    1. Lo hemos credo en Grupo contable producto porque es la misma tabla que se utiliza para crear los códigos de operación para el IVA de caja. Estos luego son los que podremos excluir además en el Request Form del Modelo 340.

    2. De la misma forma que en los grupos de registro de IVA se crean duplicados para indicar la configuración de aquellos que pertenecen a IVA No realizado, habría que hacerlo en la configuración de grupos contables de producto y duplicar aquellos que se utilicen tanto para IVA NR como para IVA de caja.

    3.      En las líneas del documento lo podéis mostrar y tener en cuenta al registrar dichas facturas con IVA de CAJA. Si no estuviera marcado, los grupos contables anteriores seguirían siendo válidos.

    Saludos,

    Equipo MS Dynamics NAV

  26. Laura says:

    Hola,

    ¿Cuándo tenéis previsto publicar la solución definitiva de forma "oficial"?

    Muchas gracias y saludos.

  27. Hola Laura!,

    como os comentamos, hemos escalado esta sugerencia al Departamento de Desarrollo para que lo evalúen. Hemos pasado los mismos cambios de código para que los validen, que los que os hemos pasado aquí.

    Aún seguimos a la espera de una confirmación oficial.

    Como os comentamos, si finalmente no se decide separar el uso de IVA no Realizado e IVA de CAJA, podríais al menos usar nuestra sugerencia "no oficial".

    En cuanto tengamos dicha confirmación, os informaremos.

    Saludos,

    Equipo MS Dynamics NAV.

  28. Laura says:

    Buenos días,

    Nos gustaría saber si ya tenemos contestación oficial respecto a si se va a publicar alguna modificación sobre el IVA de caja y el modelo 340 en este mes.

    Mucha gracias y saludos.

  29. Pacianus says:

    Hasta ahora al ejecutar el modelo 340 tenías dos pestañas, mov. iva y opciones.

    En la última actualización la pestaña mov. iva ha desaparecido.

    ¿A qué se debe?

    Saludos

  30. Juanjo says:

    Hola,

    Respecto al problemilla en el caso de tener Facturas con Importe = 0, SIN régimen de IVA de CAJA y usando los nuevos objetos y que son excluidas con las funciones SkipZeroCustLedgEntry y SkipZeroVendLedgEntry ¿Ha salido alguna solución oficial?

    ¿Es correcto comentar estas líneas o lo que hay que modificar es el contador de registros?

    Gracias.

    Un saludo.

  31. Sole says:

    Buenas tardes,

    con los cambios de este año, en el modelo 303 se pide que el importe de facturas rectificativas y abonos salga en una casilla aparte. ¿Cómo podemos hacer esto para que salga en el modelo de declaración de IVA sin que los usuarios tengan que estar calculándolo cada vez?

    Muchas gracias por vuestra atención

    Un saludo 🙂

  32. Tonino says:

    Buenas tardes,

    ¿Sabemos si hay confirmación oficial del desarrollo de diferenciar el IVA de caja y el IVA no realizado?

    Si es así, ¿nos podéis indicar cuando lo publicaréis o dónde obtenemos los objetos?

    Muchas gracias.

    Un saludo

  33. Buenas tardes a todos,

    antes de nada, disculpar la demora en responder a vuestras preguntas.

    Os contestamos:

    – Laura: No se ha publicado nada más por el momento en relación al IVA de Caja y Modelo 340.

    Solamente se han reportado un par de errores, pero no se ha publicado ningún fob nuevo.

    – Pacianus: Hemos comprobado que la pestaña Mov. IVA para poder establecer filtros sigue estando visible.

    Estáis usando la versión estándar, Pacianus?

    – Juanjo: Llamamos a Hacienda, y nos dijeron que no entendían el concepto de Factura con Importe cero :-S.

    Desarrollo por tanto ha decidido arreglar el contador del Nº registros, pero dejar sin comentar las líneas que hacen el SKIPZEROCUST/VENDLEDGERENTRIES. Por tanto las Facturas con Importe cero no aparecerán en el fichero exportado desde NAV, pero para solucionar el problema del contador, tenemos un parche. Si lo necesitáis, solo tenéis que poneros en contacto con soporte y os lo mandamos de manera gratuita. También será incluido en los Rollups para NAV2013 y NAV2013R2.

    – Sole: Hemos creado una nueva entrada de blog para responderos a esta consulta: Modelo 303: ¿Es necesario diferenciar entre facturas y abonos?

    – Tonino: Está escalado en el Departamento de Desarrollo pero aún no nos han confirmado nada.

    Desde el Departamento de Soporte en este mismo Blog os propusimos una posible sugerencia para establecer esta diferenciación.

    Esperamos que os sirva por el momento, y seguimos a la espera de una confirmación oficial por parte del Departamento de Desarrollo.

    Gracias por vuestro seguimiento en el blog.

    Es un placer para nosotras poder interactuar con vosotros y ayudaros.

    Saludos y buenas tardes,

    Equipo Microsoft Dynamcis NAV.

  34. Nacho says:

    Buenas tardes:

    Me estado leyendo todos los post, pero ninguno me aclara nada de mi problemática.

    Nuestro proveedores, normalmente cobran mediante pagaré. En la empresa, generan la factura en Cartera, pero sin generar efectos, y es en el diario de cartera, posteriormente donde lo generan. Antes de lo del IVA, el movimiento era Tipo PAGO, contra Tipo EFECTO. Ahora, eso no puede hacerse porque si no, me asienta el IVA en el momento de generar el efecto, y no cuando se liquida, por ello ahora el asiento es "En Blanco", contra tipo EFECTO. De esta manera, todo va bien, y es cuando liquido la orden de pago cuando se asienta el IVA en su cuenta definitiva. El problema surge cuando se equivocan en la generación del efecto, ya que no se puede desliquidar para hacer otro que lo corrija, ni se puede tampoco revertir la transacción. Ésto cuando era PAGO contra EFECTO, se podia hacer sin problemas. ¿Como podemos entonces realizar correcciones de los pagaré generados si el personal de administración se equivoca?. Gracias de antemano por vuestra ayuda.  

  35. Jose says:

    Buenos días, tengo un caso de un cliente que os expongo para ver si me podéis aclarar.

    Nuestro cliente tiene un proveedor que esta acogido al IVA de CAJA. se han registrado dos facturas de compra en enero, y durante ese mes se registra el pago de las dos facturas, en apuntes distintos, pero con el mismo Nº de documento y fecha.

    La cuestión es que cuando sacamos el MOD 340 para enero, me aparecen las dos facturas, esto OK, y luego un tercera línea que proviene del pago de las dos facturas, indicando únicamente el Nº de documento de la primera factura, y el importe es la suma de las dos facturas.

    El cliente me plantea si es posible, que en vez de una sola línea del pago de las dos facturas, que saliera una línea por el pago de cada factura.

    Un saludo y muchas gracias a todos.

  36. Pacianus says:

    Buenos días,

    Alguna noticia sobre la publicación de los cambios que sufrirá la estructura del modelo 347 debido al IVA con criterio de caja?

    Gracias.

    Publicado en el BOE la orden HAP/1732/2014, de 24 de septiembre.

Skip to main content