Ley antifraude 2021 (VERIFACTU) - Programas informáticos

[sglorka]

Empezado por CarlosArjonomia

Si, estoy de acuerdo. Pero habrá que capar algunas opciones. Mejor que no lo hagan a que lo hagan mal. Por ejemplo en caso de rectificativas una sola opción. Anulando la factura con una factura negativa y emitiendo una nueva factura marcada como rectificativa. Nada de diferencias o sustitución.

Yo es que no entiendo porque nos liamos con la emisión de facturas rectificativas, parece que como no la entendemos entonces tendemos a torcer el reglamento. Aceptamos cosas como que hay que desglosar las bases tipos y cuotas en la factura completa y nadie lo discute. Yo sigo un 'abc' claro en este aspecto.

1.- Se produce una devolución de mercancía a posteriori de una operación de venta ->. Se emite Rectificativa x diferencia con la cantidad devuelta con la marca R1, o si hay una operación posterior con el mismo cliente y la operación tiene el mismo tipo de Iva que lo que me devuelven, aprovecho esa factura para hacer la devolución sin rectificativa.

2.- Se produce un descuento en factura a posteriori de una operación de venta (por ejemplo un Rapell o un Pronto pago) ->. Se emite Rectificativa x diferencia con el descuento aplicado con la marca R1

3.- Te equivocaste en la identificación de destinatario ->. Se emite una factura de abono anulando la factura original y luego emites una Rectificativa x sustitución con la clave R4

4.- Te equivocaste en los tipos impositivos ->. Se emite una factura de abono anulando la factura original y luego emites una Rectificativa x sustitución con la clave R4 ó como segunda opción, anulas la factura original y emites rectificativa x sustitución con clave R4 para que no te rechacen por segunda vez el tipo impositivo incorrecto.

5.- Te equivocaste en la fecha de expedición de la factura ->. Se emite una factura de abono anulando la factura original y luego emites una Rectificativa x sustitución con la clave R4 y la fecha correcta.

6.- No sabes en qué coño te has equivocado ->. Se emite una factura de abono anulando la factura original y luego emites una Rectificativa x sustitución con la clave R4.

Creo que, salvo recuperación de cuotas por impago, no hay más casos de emisión de rectificativas.

Este tema está muy acotado. Si me he dejado algún caso, por favor, que alguien lo apostille.

Y en cuanto las sustitutivas de una simplificada por una completa, es que no hay ni que pensar, se copia el contenido exacto de la simplificada sobre una completa con el cliente identificado y se emite una simplificada idéntica a la original en negativo para anularla. Siempre utilizando como fecha operación de ambas facturas la de la factura simplificada que queremos sustituir para evitar rechazos debido a Ivas que en el momento de la sustitución ya no están vigentes.

Espero que esto quite un poco de hierro al asunto y pido disculpas por ser tan pesado con las rectificativas

[navbuoy]

creo que ya se porque deje de hacer programas de Facturacion

aparte de porque ya no pagaban ni un 10% de lo que valia esa programacion, por cosas como las que estais "sufriendo"

mi consejo, conociendo a cosas como la AEAT y compañia es que busqueis otro "pasatiempo" mejor..... principalmente porque esos tios no se aclaran ni para poner el zapato en el pie que corresponde.
(en general toda la institucion gubernamental funciona asi, de puta pena)

al final terminareis desquiciados viendo que no acaba la cosa de poderse hacer sin trabas y errores de gente que ya es que no sean ni profesionales (los de la AEAT digo) sino que son un hatajo de incompetentes.

y encima formando un lio MONUMENTAL cuando seguro que hay formas mas inteligentes y sencillas de hacer eso que ellos "han implementado"

y para mas recochineo para "robar" dinero de manera legal eso si, el 45% de tus ganancias para ellos, fenomenal eh? trabaja y te haras rico si.... eso dicen

y no es que quiera quitarle las ganas a nadie de hacerlo, es simplemente que algunas cosas no tienen ninguna clase de pase.

uno de los que gano Gran Hermano o Supervivientes o algo de eso ya lo dijo "si me han quitado mas de la mitad del premio que gané, menuda mierda"

[navbuoy]

y no es que quiera quitarle las ganas de programar a nadie, vosotros sabreis muy bien lo que hacéis, es simplemente que algunas cosas no tienen ninguna clase de "pase"

yo entre que te volvian loco los clientes con el tema del programa de facturacion (ya sabeis, lo tipico de siempre, pactamos un precio por algo pero luego vienen con las modificaciones y hazle esto tambien y hazle lo otro tambien pero a la hora de pagar ah no, que habiamos acordado ese otro precio.... seguro que sabeis de lo que hablo)

y luego que antes, pues quizas con suerte y buena labia conseguias venderlo por 15k o 20k euros pero luego ya no querian pagar ni 5.000 euros por un programa de Facturacion hecho a medida

luego los lios como este que estoy presenciando, que tiene visos de nunca acabar de solucionar errores para "comunicarse" con su sistema, seguramente por una pesima implementacion/programacion del mismo claro

y mas cosas pero bueno, por eso deje de dedicarme a cosas de esas

[JoseLeeTo]

Buenos dias a todos.

Gracias en primer lugar por vuestra a ayuda. Pude desarrollar el envio TicketBai en su momento, gracias a este foro.

Tengo una duda al enviar. Trabajo con C# (Visual Studio 2015).
Cada vez que trato de enviar, obtengo siempre una respuesta en HTML, advirtiéndome que "el certificado no es correcto, o no se ha seleccionado correctamente" - Error 403.
He instalado el certificado en todos los navegadores que tengo, en el almacén de "Personal", pero a la hora de enviar, selecciono dicho certificado (es el mío personal de la FNMT - y es funcional dado que entro en las sedes perfectamente, he realizado la declaración con el mismo, etc...) .... pero la respuesta a través del código es un HTML (no un XML) con ese error 403.

¿Alguien ha logrado enviar sin problemas, teniendo el certificado instalado en el navegador? ¿Qué puede estar ocurriendo para que no esté validando mi certificado?

Mil gracias de antemano.
Un saludo

[ermendalenda]

Empezado por JoseLeeTo

Buenos dias a todos.

Gracias en primer lugar por vuestra a ayuda. Pude desarrollar el envio TicketBai en su momento, gracias a este foro.

Tengo una duda al enviar. Trabajo con C# (Visual Studio 2015).
Cada vez que trato de enviar, obtengo siempre una respuesta en HTML, advirtiéndome que "el certificado no es correcto, o no se ha seleccionado correctamente" - Error 403.
He instalado el certificado en todos los navegadores que tengo, en el almacén de "Personal", pero a la hora de enviar, selecciono dicho certificado (es el mío personal de la FNMT - y es funcional dado que entro en las sedes perfectamente, he realizado la declaración con el mismo, etc...) .... pero la respuesta a través del código es un HTML (no un XML) con ese error 403.

¿Alguien ha logrado enviar sin problemas, teniendo el certificado instalado en el navegador? ¿Qué puede estar ocurriendo para que no esté validando mi certificado?

Mil gracias de antemano.
Un saludo

El certificado debe ser del mismo cir que el emisor de la factura, en caso contrario debes rellenar los nodos de envio por terceros.

[JoseLeeTo]

Empezado por ermendalenda

El certificado debe ser del mismo cir que el emisor de la factura, en caso contrario debes rellenar los nodos de envio por terceros.

Muchas gracias.


Entiendo que con lo de "cir", te refieres al nif. ¿No?

El certificado es el mío personal - de la FNMT - y las pruebas las estoy realizando con un emisor de facturas con mi nombre y NIF.
Pero el error, es el que comento con código 403 - El certificado no es correcto, o no se ha seleccionado correctamente.

Creo que el error, no es en la validación del XML como tal, porque ni llega a validarlo. No devuelve un XML de respuesta de error... sino un HTML, como código de error de ese tipo.
Les consulté, y me contestaron que en ese tipo de errores, devolvían un HTML (la misma página de error que si conectas a sus servicios, y no te validas).
Al existir un error previo a la validación del XML (de certificado según ellos), creo que ni siquera valida

Y es que no se me ocurre nada más, ya que entiendo que solamente hay que instalar dicho certificado en el almacén Personal.
Al menos en TicketBai, funciona correctamente así desde siempre.


Muchas gracias

[ermendalenda]

Empezado por JoseLeeTo

Muchas gracias.


Entiendo que con lo de "cir", te refieres al nif. ¿No?

El certificado es el mío personal - de la FNMT - y las pruebas las estoy realizando con un emisor de facturas con mi nombre y NIF.
Pero el error, es el que comento con código 403 - El certificado no es correcto, o no se ha seleccionado correctamente.

Creo que el error, no es en la validación del XML como tal, porque ni llega a validarlo. No devuelve un XML de respuesta de error... sino un HTML, como código de error de ese tipo.
Les consulté, y me contestaron que en ese tipo de errores, devolvían un HTML (la misma página de error que si conectas a sus servicios, y no te validas).
Al existir un error previo a la validación del XML (de certificado según ellos), creo que ni siquera valida

Y es que no se me ocurre nada más, ya que entiendo que solamente hay que instalar dicho certificado en el almacén Personal.
Al menos en TicketBai, funciona correctamente así desde siempre.


Muchas gracias

Sí así es.
Entonces no se me ocurre otra cosa que no sea que hay algún error en la llamada desee donde lees el certificad, que el firewall esté cortando algo o tengas desactivado algo de llamadas tsl..

[ermendalenda]

Sobre lo que acaban de publicar en el boe:
sobre el hash anterior lo que tiene que ir en la HuellaAnterior:

4º Los primeros 64 caracteres de la huella o «hash» del registro de facturación inmediatamente anterior.

Entonces pienso yo que tienen previsto en algun momento pasar al hash512 o cualquiera sabe, por que el hexadecimal del hash256 SIEMPRE tiene 64 caracteres.

[ermendalenda]

Hola, los que trabajamos en programas de escritorio tenemos aqui un problema:

f)En cualquier caso, el obligado tributario usuario del sistema informático deberá asegurarse de que la fecha y hora empleadas por dicho sistema informático para fechar los registros de facturación son exactas, con un margen máximo de error admitido de un minuto

Ya que si permitimos en algún momento trabajar sin internet no podemos controlar que por alguna incidencia se cambie el reloj. Incluso que algun listo se las "sepa todas" y quiera cambiar una factura de fecha. Y tampoco podemos cortar de que no se pueda facturar sin conexion

Por favor que alguien haga la consulta, yo los tengo bombardeados.

Me respondo:
Si no hay conexion ya hay que marcar incidencia pase lo que pase.

[Zento]

Empezado por ermendalenda

Hola, los que trabajamos en programas de escritorio tenemos aqui un problema:


Ya que si permitimos en algún momento trabajar sin internet no podemos controlar que por alguna incidencia se cambie el reloj. Incluso que algun listo se las "sepa todas" y quiera cambiar una factura de fecha. Y tampoco podemos cortar de que no se pueda facturar sin conexion

Por favor que alguien haga la consulta, yo los tengo bombardeados.

Me respondo:
Si no hay conexion ya hay que marcar incidencia pase lo que pase.

El obligado tributario del sistema informático es el usuario final. Así que tú como desarrollador puedes estar tranquilo. Si cambia la fecha o la hora tampoco debería funcionar SSL. En cualquier Windows actual eso está más que cubierto.

[bmfranky]

Empezado por JoseLeeTo

Buenos dias a todos.

Gracias en primer lugar por vuestra a ayuda. Pude desarrollar el envio TicketBai en su momento, gracias a este foro.

Tengo una duda al enviar. Trabajo con C# (Visual Studio 2015).
Cada vez que trato de enviar, obtengo siempre una respuesta en HTML, advirtiéndome que "el certificado no es correcto, o no se ha seleccionado correctamente" - Error 403.
He instalado el certificado en todos los navegadores que tengo, en el almacén de "Personal", pero a la hora de enviar, selecciono dicho certificado (es el mío personal de la FNMT - y es funcional dado que entro en las sedes perfectamente, he realizado la declaración con el mismo, etc...) .... pero la respuesta a través del código es un HTML (no un XML) con ese error 403.

¿Alguien ha logrado enviar sin problemas, teniendo el certificado instalado en el navegador? ¿Qué puede estar ocurriendo para que no esté validando mi certificado?

Mil gracias de antemano.
Un saludo

Hola te respondo por aqui y asi le puede servir a alguien mas.


En el App.config teneis que poner que usais la identificacion con certificado, asi:

<security mode="Transport">
<transport clientCredentialType="Certificate" />
</security>

Os pongo como queda en el app config.

    <client>
      <endpoint address="https://www1.agenciatributaria.gob.es/wlpl/BURT-JDIT/ws/VNifV2SOAP"
        binding="basicHttpBinding" bindingConfiguration="VNifV2SoapBinding"
        contract="ChecaNifsActivos.VNifV2" name="VNifPort1" />
      <endpoint address="https://prewww1.aeat.es/wlpl/TIKE-CONT/ws/SistemaFacturacion/VerifactuSOAP"
        binding="basicHttpBinding" bindingConfiguration="sfVerifactu"
        contract="ServicioVerifactu.sfPortTypeVerifactu" name="SistemaVerifactuPruebas" />
      <endpoint address="https://prewww10.aeat.es/wlpl/TIKE-CONT/ws/SistemaFacturacion/VerifactuSOAP"
        binding="basicHttpBinding" bindingConfiguration="sfVerifactu1"
        contract="ServicioVerifactu.sfPortTypeVerifactu" name="SistemaVerifactuSelloPruebas" />
    </client>
    <bindings>
      <basicHttpBinding>
        <binding name="VNifV2SoapBinding">
         <security mode="Transport">
            <transport clientCredentialType="Certificate" />     

          </security>
        </binding>
        <binding name="VNifV2SoapBinding1" />
        <binding name="sfVerifactu">
          <security mode="Transport">
            <transport clientCredentialType="Certificate" />
          </security>
        </binding>
        <binding name="sfVerifactu1">
          <security mode="Transport">
            <transport clientCredentialType="Certificate" />
          </security>
        </binding>
        <binding name="sfVerifactu2" />
        <binding name="sfRequerimiento" />
      </basicHttpBinding>
    <customBinding>
        <binding name="sfVerifactu">
          <textMessageEncoding messageVersion="Soap11" writeEncoding="utf-8" />
          <httpsTransport />
        </binding>
      </customBinding>
    </bindings>

Tambien os pongo la funcion para seleccionar los certificados del sistema y luego almacenarlos en bytes[] para guardarlos en la base de datos.

        public static X509Certificate2 ElegirCertificado()
        {
            try
            {
                X509Store store = new X509Store(StoreName.My, StoreLocation.CurrentUser);
                store.Open(OpenFlags.ReadOnly | OpenFlags.OpenExistingOnly);
                X509Certificate2Collection collection = (X509Certificate2Collection)store.Certificates;
                X509Certificate2Collection fcollection = (X509Certificate2Collection)collection.Find(X509FindType.FindByTimeValid, DateTime.Now, false);
                X509Certificate2Collection scollection = X509Certificate2UI.SelectFromCollection(fcollection, "Selección de Certificados", "Seleccione un certificado de la lista para firmar la factura electrónica", X509SelectionFlag.SingleSelection);

                X509Certificate2Enumerator Certificado = scollection.GetEnumerator();
                X509Certificate2 cert = new X509Certificate2();
                if (scollection.Count > 0)
                {
                    X509Certificate2Enumerator en = scollection.GetEnumerator();
                    en.MoveNext();
                    cert = en.Current;
                    if (DateTime.Now > cert.NotAfter)
                    {
                        throw new Exception("Certificado caducado");
                    }
                    else
                    {
                        return cert;
                    }
                }

                if (fcollection.Count == 0)
                {
                    MessageBox.Show("No hay certificados electrónicos instalados en tu equipo");
                }
                else
                {
                    if (scollection.Count == 0)
                    {
                        MessageBox.Show("No has seleccionado ningún certificado");
                    }
                }
                store.Close();
                var temp = scollection.OfType<X509Certificate2>();
                var cert1 = scollection.OfType<X509Certificate2>().Where(x => x.Subject == "CN=FNMT-RCM").First(); // + Program.configTaller.NombreTaller).First();
                return cert;
            }
            catch (Exception ex)
            {
                //  throw ex;
            }
            //X509Store store = new X509Store(StoreLocation.CurrentUser);
            //store.Open(OpenFlags.ReadOnly | OpenFlags.OpenExistingOnly);
            //X509Certificate2Collection certificates = store.Certificates;
            //X509Certificate2Collection foundCertificates = certificates.Find(X509FindType.FindByTimeValid, DateTime.Now, false);
            //var cert = foundCertificates.OfType<X509Certificate>().Where(x => x.Subject == "CN="+Program.configTaller.NombreTaller).First();
            return null;
        }

Esto devuelve el certificado seleccionado.
Luego simplemente lo exportamos a bytes con una contraseña por nuestra seguridad.

 var certificado = ConfigDB.ElegirCertificado();// CertificadoSeleccionado();
            if(null != certificado)
            {
                string caducidad = certificado.GetExpirationDateString();
                Program.certificado = certificado.Export(X509ContentType.Cert, Program.passcertificado);<-- Este es el password que usaremos para guardar/usar el certificado.
                txtCaducidad.Text = caducidad;
                ConfigDB.ActualizarCertificado(1, Program.certificado, caducidad);
            }

[ermendalenda]

Empezado por sglorka

Y en cuanto las sustitutivas de una simplificada por una completa, es que no hay ni que pensar, se copia el contenido exacto de la simplificada sobre una completa con el cliente identificado y se emite una simplificada idéntica a la original en negativo para anularla. Siempre utilizando como fecha operación de ambas facturas la de la factura simplificada que queremos sustituir para evitar rechazos debido a Ivas que en el momento de la sustitución ya no están vigentes.

Espero que esto quite un poco de hierro al asunto y pido disculpas por ser tan pesado con las rectificativas

Buff que lio, que copias el contenido a una simplificada en negativo para anularla pero has dicho que se copia en una factura normal. Creo que has escrito algo erroneo. Por que además dices de ambas facturas y solo estás explicando 1.

Por otro lado, si verifactu se está equivocando...
Se puede hacer 2 cosas, rebatir ahora con verifactu o esperar al reglamento técnico y las faqs y si sigue igual rebatir de nuevo. Ya que si yo hago caso a ellos u tú no, uno de los 2 lo vamos a estar haciendo mal.

[ermendalenda]

Artículo 15. Facturas rectificativas.
1. Deberá expedirse una factura rectificativa en los casos en que la factura original no cumpla alguno de los requisitos que se establecen en los artículos 6 ó 7, sin perjuicio de lo establecido en el apartado 6 de este artículo.


2. Igualmente, será obligatoria la expedición de una factura rectificativa en los casos en que las cuotas impositivas repercutidas se hubiesen determinado incorrectamente o se hubieran producido las circunstancias que, según lo dispuesto en el artículo 80 de la Ley del Impuesto, dan lugar a la modificación de la base imponible.
Artículo 6. Contenido de la factura.
1. Toda factura y sus copias contendrán los datos o requisitos que se citan a continuación, sin perjuicio de los que puedan resultar obligatorios a otros efectos y de la posibilidad de incluir cualesquiera otras menciones:
....

Yo creo que la interpretación del reglamento para lss situaciones de error en los datos del cliente pueden ser ambiguas.
El reglamento dice claramente de que si las cuotas están mal calculadas es rectificativa pero sobre el resto del contenido no dice contenido erroneo dice que debe tener esos datos, con lo cual el error de cliente no está especificado, yo creo que dado la ambigüedad puede ser válido hacer las 2 cosas, la rectificativa o la subsanación.
Dado que hasta ahora no existía la subsanacion no había otra posibilidad, entonces yo pienso que con este nueva opción se ha complementado la forma de actuar.

[ermendalenda]

Si hago un barrido de contadores detecto una factura no generado el registro , he actuado así a ver si lo veis correcto:
Regenerando registro con registro anterior al último enviado, marcó sibsanacion=S y rechazoprevio=S, incidencia=S
Aunque no me la hayan rechazado, por que si no marcó rechazo como si, no la acepta. Y sólo como incidencia no lo veo

[ermendalenda]

Empezado por ermendalenda

Si hago un barrido de contadores detecto una factura no generado el registro , he actuado así a ver si lo veis correcto:
Regenerando registro con registro anterior al último enviado, marcó sibsanacion=S y rechazoprevio=S, incidencia=S
Aunque no me la hayan rechazado, por que si no marcó rechazo como si, no la acepta. Y sólo como incidencia no lo veo

Me contesto yo mismo
Solo como incidencia, pueden localizar que no ha habido un rechazo previo en el hueco que no envié.

[sglorka]

Empezado por ermendalenda

Yo creo que la interpretación del reglamento para lss situaciones de error en los datos del cliente pueden ser ambiguas.
El reglamento dice claramente de que si las cuotas están mal calculadas es rectificativa pero sobre el resto del contenido no dice contenido erroneo dice que debe tener esos datos, con lo cual el error de cliente no está especificado, yo creo que dado la ambigüedad puede ser válido hacer las 2 cosas, la rectificativa o la subsanación.
Dado que hasta ahora no existía la subsanacion no había otra posibilidad, entonces yo pienso que con este nueva opción se ha complementado la forma de actuar.

Si tienes dudas sobre este aspecto te resumo la consulta vinculante emitida en octubre de 2022 y que bmfranky publicó hace unos diás

Resolución de Dirección General de Tributos Vinculante V2245-22 del 26 de Octubre de 2022
"entre las causas que motivan la expedición obligatoria de una factura rectificativa se comprende la consignación de un nuevo destinatario de la factura cuando se incurrió en un error, criterio sustentado por este Centro Directivo entre otras en la contestación vinculante número V1792-06, de fecha 7 de septiembre de 2006. Debe señalarse que es causa de rectificación de las facturas la consignación errónea de cualquier dato o requisito obligatorio que se consigne en las mismas, como pudiera ser el caso de los datos de identificación del destinatario como sucede en la factura a la que se refiere el escrito de consulta. Por tanto, en caso de que se haya consignado de manera incorrecta la identificación del destinatario de la factura, el consultante deberá expedir una factura rectificativa que deberá constar en serie específica de factura."

[ermendalenda]

Empezado por sglorka

Si tienes dudas sobre este aspecto te resumo la consulta vinculante emitida en octubre de 2022 y que bmfranky publicó hace unos diás

Resolución de Dirección General de Tributos Vinculante V2245-22 del 26 de Octubre de 2022
"entre las causas que motivan la expedición obligatoria de una factura rectificativa se comprende la consignación de un nuevo destinatario de la factura cuando se incurrió en un error, criterio sustentado por este Centro Directivo entre otras en la contestación vinculante número V1792-06, de fecha 7 de septiembre de 2006. Debe señalarse que es causa de rectificación de las facturas la consignación errónea de cualquier dato o requisito obligatorio que se consigne en las mismas, como pudiera ser el caso de los datos de identificación del destinatario como sucede en la factura a la que se refiere el escrito de consulta. Por tanto, en caso de que se haya consignado de manera incorrecta la identificación del destinatario de la factura, el consultante deberá expedir una factura rectificativa que deberá constar en serie específica de factura."

Pues si que tienen lio, efectivamente la consulta vinculante es lo que prevalece. Gracias y siento haber insistido.
Aunque voy a responder con esto mismo al que respondió a la cuestión de verifactu a ver que dice.

[Becario127]

Hola buenos dias

Preguntaba por si este XML que genere esta bien para enviarse por verifactu o si me falta algo por agregar

<soapenv:Envelope xmlns:soapenv="chemas.xmlsoap.org/soap/envelope/" xmlns:sum="ww2.agenciatributaria.gob.es/static_files/common/internet/dep/aplicaciones/es/aeat/tike/cont/ws/SuministroLR.xsd" xmlns:sum1="ww2.agenciatributaria.gob.es/static_files/common/internet/dep/aplicaciones/es/aeat/tike/cont/ws/SuministroInformacion.xsd" xmlns:xd="ww.w3.org/2000/09/xmldsig#">
<soapenv:Header/>
<soapenv:Body>
<sum:RegFactuSistemaFacturacion>
<sum1:Cabecera>
<sum1:ObligadoEmision>
<sum1:NombreRazon>a</sum1:NombreRazon>
<sum1:NIF>a</sum1:NIF>
</sum1:ObligadoEmision>
</sum1:Cabecera>
<sum:RegistroFactura>
<sum:RegistroAlta>
<sum1:IDVersion>1.0</sum1:IDVersion>
<sum1:IDFactura>
<sum1:IDEmisorFactura>49962410Q</sum1:IDEmisorFactura>
<sum1:NumSerieFactura>a</sum1:NumSerieFactura>
<sum1:FechaExpedicionFactura>2024-10-10</sum1:FechaExpedicionFactura>
</sum1:IDFactura>
<sum1:NombreRazonEmisor>a</sum1:NombreRazonEmisor>
<sum1:TipoFactura>a</sum1:TipoFactura>
<sum1:DescripcionOperacion>a</sum1:DescripcionOperacion>
<sum1:Destinatarios>
<sum1:IDDestinatario>
<sum1:NombreRazon>a</sum1:NombreRazon>
<sum1:NIF>a</sum1:NIF>
</sum1:IDDestinatario>
</sum1:Destinatarios>
<sum1:Desglose>
<sum1:DetalleDesglose>
<sum1:ClaveRegimen>a</sum1:ClaveRegimen>
<sum1:CalificacionOperacion>a</sum1:CalificacionOperacion>
<sum1:TipoImpositivo>a</sum1:TipoImpositivo>
<sum1:BaseImponibleOimporteNoSujeto>a</sum1:BaseImponibleOimporteNoSujeto>
<sum1:CuotaRepercutida>a</sum1:CuotaRepercutida>
</sum1:DetalleDesglose>
<sum1:DetalleDesglose>
<sum1:ClaveRegimen>a</sum1:ClaveRegimen>
<sum1:CalificacionOperacion>a</sum1:CalificacionOperacion>
<sum1:TipoImpositivo>a</sum1:TipoImpositivo>
<sum1:BaseImponibleOimporteNoSujeto>a</sum1:BaseImponibleOimporteNoSujeto>
<sum1:CuotaRepercutida>a</sum1:CuotaRepercutida>
</sum1:DetalleDesglose>
</sum1:Desglose>
<sum1:CuotaTotal>a</sum1:CuotaTotal>
<sum1:ImporteTotal>a</sum1:ImporteTotal>
<sum1:Encadenamiento>
<sum1:RegistroAnterior>
<sum1:IDEmisorFactura>a</sum1:IDEmisorFactura>
<sum1:NumSerieFactura>a</sum1:NumSerieFactura>
<sum1:FechaExpedicionFactura>2024-10-10</sum1:FechaExpedicionFactura>
<sum1:Huella>a</sum1:Huella>
</sum1:RegistroAnterior>
</sum1:Encadenamiento>
<sum1:SistemaInformatico>
<sum1:NombreRazon>a</sum1:NombreRazon>
<sum1:NIF>a</sum1:NIF>
<sum1:NombreSistemaInformatico>a</sum1:NombreSistemaInformatico>
<sum1:IdSistemaInformatico>2024-10-10</sum1:IdSistemaInformatico>
<sum1:Version>a</sum1:Version>
<sum1:NumeroInstalacion>a</sum1:NumeroInstalacion>
<sum1:TipoUsoPosibleSoloVerifactu>a</sum1:TipoUsoPosibleSoloVerifactu>
<sum1:TipoUsoPosibleMultiOT>a</sum1:TipoUsoPosibleMultiOT>
<sum1:IndicadorMultiplesOT>a</sum1:IndicadorMultiplesOT>
</sum1:SistemaInformatico>
<sum1:FechaHoraHusoGenRegistro>2024-10-28T09:02:49.291409</sum1:FechaHoraHusoGenRegistro>
<sum1:TipoHuella>01</sum1:TipoHuella>
<sum1:Huella>54DF1CC5E6B4A9B1C87B1924709853980C2D98DFD9112F133F6D5E38871C801F</sum1:Huella>
</sum:RegistroAlta>
</sum:RegistroFactura>
</sum:RegFactuSistemaFacturacion>
</soapenv:Body>
</soapenv:Envelope>

Muchas gracias

[Joze]

Buenos días:

Se ha publicado la Orden Ministerial


www . boe . es/diario_boe/txt.php?id=BOE-A-2024-22138 <--- (quitar espacios)

a partir del 29 de julio de 2025 no se podrá desarrollar ni comercializar ningún sistema informático que no esté adaptado

Abrazos a todos

[ermendalenda]

Empezado por sglorka

Si tienes dudas sobre este aspecto te resumo la consulta vinculante emitida en octubre de 2022 y que bmfranky publicó hace unos diás

Resolución de Dirección General de Tributos Vinculante V2245-22 del 26 de Octubre de 2022
"entre las causas que motivan la expedición obligatoria de una factura rectificativa se comprende la consignación de un nuevo destinatario de la factura cuando se incurrió en un error, criterio sustentado por este Centro Directivo entre otras en la contestación vinculante número V1792-06, de fecha 7 de septiembre de 2006. Debe señalarse que es causa de rectificación de las facturas la consignación errónea de cualquier dato o requisito obligatorio que se consigne en las mismas, como pudiera ser el caso de los datos de identificación del destinatario como sucede en la factura a la que se refiere el escrito de consulta. Por tanto, en caso de que se haya consignado de manera incorrecta la identificación del destinatario de la factura, el consultante deberá expedir una factura rectificativa que deberá constar en serie específica de factura."

Enviada consulta de nuevo agregando consulta vinculante, está vez a través de nuestra asesoría.