TICKET BAI (TicketBAI); Nuevo sistema de la Agencia Tributaria del Pais Vasco

[Sanduzelai]

Hola de nuevo, me estoy volviendo loco con el envio a zuzendu de una factura SUBSANAR.
A ver si me podéis dar algo de luz de que estoy haciendo mal.

Tengo la siguiente factura XML

<?xml version="1.0" encoding="UTF-8"?>
<ns2:SubsanacionModificacionTicketBAI xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:ns2="urn:ticketbai:zuzendu-alta">
  <Cabecera xmlns="">
    <IDVersion>1.0</IDVersion>
    <Accion>SUBSANAR</Accion>
  </Cabecera>
  <Sujetos xmlns="">
    <Emisor>
      <NIF>XXXXX5543</NIF>
      <ApellidosNombreRazonSocial>XXXXX S.L.</ApellidosNombreRazonSocial>
    </Emisor>
    <Destinatarios>
      <IDDestinatario>
        <NIF>XXXXX5543</NIF>
        <ApellidosNombreRazonSocial>Expendeduria 1 Eibar</ApellidosNombreRazonSocial>
        <CodigoPostal>20600</CodigoPostal>
        <Direccion>XXXX</Direccion>
      </IDDestinatario>
    </Destinatarios>
    <VariosDestinatarios>N</VariosDestinatarios>
  </Sujetos>
  <Factura xmlns="">
    <CabeceraFactura>
      <SerieFactura>X94</SerieFactura>
      <NumFactura>30</NumFactura>
      <FechaExpedicionFactura>10-03-2022</FechaExpedicionFactura>
      <HoraExpedicionFactura>11:56:33</HoraExpedicionFactura>
      <FacturaSimplificada>N</FacturaSimplificada>
      <FacturaEmitidaSustitucionSimplificada>N</FacturaEmitidaSustitucionSimplificada>
    </CabeceraFactura>
    <DatosFactura>
      <FechaOperacion>10-03-2022</FechaOperacion>
      <DescripcionFactura>2022-03-10 11:56:12</DescripcionFactura>
      <DetallesFactura>
        <IDDetalleFactura>
          <DescripcionDetalle>PRODUCTO 1</DescripcionDetalle>
          <Cantidad>1</Cantidad>
          <ImporteUnitario>5.45</ImporteUnitario>
          <Descuento>0.00</Descuento>
          <ImporteTotal>6.60</ImporteTotal>
        </IDDetalleFactura>
      </DetallesFactura>
      <ImporteTotalFactura>6.60</ImporteTotalFactura>
      <RetencionSoportada>0.00</RetencionSoportada>
      <Claves>
        <IDClave>
          <ClaveRegimenIvaOpTrascendencia>01</ClaveRegimenIvaOpTrascendencia>
        </IDClave>
      </Claves>
    </DatosFactura>
    <TipoDesglose>
      <DesgloseFactura>
        <Sujeta>
          <NoExenta>
            <DetalleNoExenta>
              <TipoNoExenta>S1</TipoNoExenta>
              <DesgloseIVA>
                <DetalleIVA>
                  <BaseImponible>5.45</BaseImponible>
                  <TipoImpositivo>21</TipoImpositivo>
                  <CuotaImpuesto>1.15</CuotaImpuesto>
                  <OperacionEnRecargoDeEquivalenciaORegimenSimplificado>N</OperacionEnRecargoDeEquivalenciaORegimenSimplificado>
                  <TipoRecargoEquivalencia>0.00</TipoRecargoEquivalencia>
                  <CuotaRecargoEquivalencia>0.00</CuotaRecargoEquivalencia>
                </DetalleIVA>
              </DesgloseIVA>
            </DetalleNoExenta>
          </NoExenta>
        </Sujeta>
      </DesgloseFactura>
    </TipoDesglose>
  </Factura>
  <HuellaTBAI xmlns="">
    <Software>
      <LicenciaTBAI>TBAIGIPRE00000000XXX</LicenciaTBAI>
      <EntidadDesarrolladora>
        <NIF>XXXXX5543</NIF>
      </EntidadDesarrolladora>
      <Nombre>MIMAQUINA</Nombre>
      <Version>1.0</Version>
    </Software>
  </HuellaTBAI>
  <SignatureValueFirmaFactura>XXXXX1vwExVhRNItOmEBAIsA+5X3iUGce+tHQM4LPcV1q5aLXXXXXX1KkbzJnVylu0DnL6F0LEo1rwwFJtQNoneERZRo+5wYbUmS</SignatureValueFirmaFactura>
</ns2:SubsanacionModificacionTicketBAI>

He comprobado los datos y parece que estan bien (tal y como pone en la factura modelo colgada en la web de gipuzkoa.eus)
Pero siempre recibo el error:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ns2:TicketBaiResponse xmlns:ns2="urn:ticketbai:emision">
    <Salida>
        <FechaRecepcion>14-03-2022 10:52:10</FechaRecepcion>
        <Estado>01</Estado>
        <Descripcion>Rechazado - ALTA PREP</Descripcion>
        <Azalpena>Baztertua - ALTA PREP</Azalpena>
        <ResultadosValidacion>
            <Codigo>002</Codigo>
            <Descripcion>Fichero no cumple el esquema XSD. Detalle del error: cvc-elt.1: Cannot find the declaration of element 'ns2:SubsanacionModificacionTicketBAI'.</Descripcion>
            <Azalpena>Fitxategiak ez du betetzen XSD eskema. Errorearen xehetasuna: cvc-elt.1: Cannot find the declaration of element 'ns2:SubsanacionModificacionTicketBAI'.</Azalpena>
        </ResultadosValidacion>
    </Salida>
</ns2:TicketBaiResponse>

¿Veis algo mal en mi factura que a mi se me escapa?

[jreverendo]

Empezado por Sanduzelai

Hola de nuevo, me estoy volviendo loco con el envio a zuzendu de una factura SUBSANAR.
A ver si me podéis dar algo de luz de que estoy haciendo mal.



¿Veis algo mal en mi factura que a mi se me escapa?

La unica diferencia con respecto a la mia es:

<ns2:SubsanacionModificacionTicketBAI xmlns:ns2="urn:ticketbai:zuzendu-alta">

[unomasmas]

Empezado por Sanduzelai

Hola de nuevo, me estoy volviendo loco con el envio a zuzendu de una factura SUBSANAR.
A ver si me podéis dar algo de luz de que estoy haciendo mal.

Tengo la siguiente factura XML

<?xml version="1.0" encoding="UTF-8"?>
<ns2:SubsanacionModificacionTicketBAI xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:ns2="urn:ticketbai:zuzendu-alta">
  <Cabecera xmlns="">
    <IDVersion>1.0</IDVersion>
    <Accion>SUBSANAR</Accion>
   </Cabecera>
...

</ns2:SubsanacionModificacionTicketBAI>

He comprobado los datos y parece que estan bien (tal y como pone en la factura modelo colgada en la web de gipuzkoa.eus)
Pero siempre recibo el error:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ns2:TicketBaiResponse xmlns:ns2="urn:ticketbai:emision">
    <Salida>
        <FechaRecepcion>14-03-2022 10:52:10</FechaRecepcion>
        <Estado>01</Estado>
        <Descripcion>Rechazado - ALTA PREP</Descripcion>
        <Azalpena>Baztertua - ALTA PREP</Azalpena>
        <ResultadosValidacion>
            <Codigo>002</Codigo>
            <Descripcion>Fichero no cumple el esquema XSD. Detalle del error: cvc-elt.1: Cannot find the declaration of element 'ns2:SubsanacionModificacionTicketBAI'.</Descripcion>
            <Azalpena>Fitxategiak ez du betetzen XSD eskema. Errorearen xehetasuna: cvc-elt.1: Cannot find the declaration of element 'ns2:SubsanacionModificacionTicketBAI'.</Azalpena>
        </ResultadosValidacion>
    </Salida>
</ns2:TicketBaiResponse>

¿Veis algo mal en mi factura que a mi se me escapa?

Cambia:

<ns2:SubsanacionModificacionTicketBAI  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"  xmlns:ns2="urn:ticketbai:zuzendu-alta">

Por:

<ns2:SubsanacionModificacionTicketBAI xmlns:ns2="urn:ticketbai:zuzendu-alta">

[Neftali [Germán.Estévez]]

Empezado por unomasmas

Por lo que recuerdo haber leíado de un vistazo que le eché, la Administración (Hacienda) se atribuye algunas facultades que me parece que exceden con mucho la división de poderes como la de poder exigir las contraseñas, etc. de los equipos. No me parece a mi que, sin una orden judicial, pueda hacer esto...

Empezado por unomasmas

1. La Administración tributaria podrá personarse en el lugar donde se encuentre o se utilice el sistema informático, y podrá exigir el acceso completo e inmediato a donde resida el registro de los datos, o sus copias seguras, así como su descarga, volcado o copiado, consulta e impresión, siempre en formato legible, obteniendo, en su caso, el usuario, contraseña y cualquier otra clave de seguridad que fuera necesaria para el acceso completo al sistema informático y a los datos del mismo, todo ello de acuerdo con lo previsto en la normativa reguladora de los procedimientos de aplicación de los tributos.

Es lo de siempre, es que dejamos las cosas a medias y no queremos entender lo que se explica. No había entendido el primer mensaje...

"...como la de poder exigir las contraseñas..."
Pensé que te referías a que la AEAT puede pedir tener las contraseñas de tus sistemas para tenerlas en cualquier momento. Eso no me parece lógico ni tiene sentido.

En el segundo párrafo lo que dice (más o menos) es:
"...que si se presenta una inspección en tu empresa de la AEAT para revisar tus equipos porque piensan que estás defraudando, debes darles las contraseñas para acceder a ellos. Cosa normal y lógica. Si se presentan a hacerte una inspección no te preocupes que tendrán lo necesario judicialmente para hacerlo."
Lo que no tiene sentido es que se presente en la empresa una inspeción de hacienda y les digas: "lo siento, no pueden acceder al equipo porque no recuerdo la contraseña."
=> Lo siguiente es que van a coger los equipos y se los van a llevar. Ya no tendrás que preocuparte por las contraseñas.

Al final la ley lo que está diciendo es que:
1) o envías los ficheros a hacienda de forma regular.
2) o los guardas en tus equipos (firmados y con lo necesario para demostrar que no sean alterados) y por supuesto en cualquier momento que la AEAT necesite acceder a ellos se los tienes que poder facilitar de forma fácil. Si tus equipos tienen contraseñas cuando se presente el inspector de hacienda, pues se la tendrás que dar (no veo problema judicial en eso, es más es lo lógico).
Es lo que estás aceptando cuando en un punto pone:
Verificación del cumplimiento de la obligación por parte de la Administración tributaria

Pues eso, que la administración debe poder hacerlo. Y si tienes contraseñas pues se las tienes que dar. Si no de qué sirve todo este "choco" si cuando vayan a revisar lo que estás haciendo les puedes decir que no les das acceso.

Y cuando dice:
"La Administración tributaria podrá requerir y obtener copia de los registros de facturación conservados..."

Pues si los tienes encriptados les tendrás que dar la clave de desencriptación.

[ermendalenda]

Yo lo que veo que no tiene sentido es que podamos garantizar que los eventos no sea modificables sin un procedimiento claro, ¿por que?, pues bien, en las facturas si las enviamos inmediatamente no hay problema, si nos la quedamos y hacemos un encadenados no hay problema por que hay emitidos tiquets con qrs que sirven como verificación. Pero los eventos que guardemos no se puede hacer um blockchain, si no hay una entidad de hacienda que reciba esos datos o un reglamento específico que lo garantice. Cualquier cosa que hagamos es modificable. Si el cliente que tiene un software externo puede tener encriptado o con contraseñas imposibles de evadir, pero si la empresa que usa el software es la misma que hace el programa que me expliquen como se hace, si quieres meterle un timestamp ya obligan a una conexión continua con Internet, no es viable.

[Sistel]

Empezado por ermendalenda

...pero si la empresa que usa el software es la misma que hace el programa que me expliquen como se hace...

Hola ermendalenda,

Ahí está el quid de la cuestión:
Lo que buscan, a la larga, es que las empresas desarrolladoras de softwares contables y de facturación sean independientes de las empresas que los usan.
Y que las empresas desarrolladoras pongan los mecanismos de seguridad para que el cliente no pueda manipular la información.

Y se pedirá homologación de los softwares para que sean éstos los que cumplan.

Saludos

[unomasmas]

Empezado por Neftali [Germán.Estévez]

Es lo de siempre, es que dejamos las cosas a medias y no queremos entender lo que se explica. No había entendido el primer mensaje...

"...como la de poder exigir las contraseñas..."
Pensé que te referías a que la AEAT puede pedir tener las contraseñas de tus sistemas para tenerlas en cualquier momento. Eso no me parece lógico ni tiene sentido.

En el segundo párrafo lo que dice (más o menos) es:
"...que si se presenta una inspección en tu empresa de la AEAT para revisar tus equipos porque piensan que estás defraudando, debes darles las contraseñas para acceder a ellos. Cosa normal y lógica. Si se presentan a hacerte una inspección no te preocupes que tendrán lo necesario judicialmente para hacerlo."
Lo que no tiene sentido es que se presente en la empresa una inspeción de hacienda y les digas: "lo siento, no pueden acceder al equipo porque no recuerdo la contraseña."
=> Lo siguiente es que van a coger los equipos y se los van a llevar. Ya no tendrás que preocuparte por las contraseñas.

Al final la ley lo que está diciendo es que:
1) o envías los ficheros a hacienda de forma regular.
2) o los guardas en tus equipos (firmados y con lo necesario para demostrar que no sean alterados) y por supuesto en cualquier momento que la AEAT necesite acceder a ellos se los tienes que poder facilitar de forma fácil. Si tus equipos tienen contraseñas cuando se presente el inspector de hacienda, pues se la tendrás que dar (no veo problema judicial en eso, es más es lo lógico).
Es lo que estás aceptando cuando en un punto pone:
Verificación del cumplimiento de la obligación por parte de la Administración tributaria

Pues eso, que la administración debe poder hacerlo. Y si tienes contraseñas pues se las tienes que dar. Si no de qué sirve todo este "choco" si cuando vayan a revisar lo que estás haciendo les puedes decir que no les das acceso.

Y cuando dice:
"La Administración tributaria podrá requerir y obtener copia de los registros de facturación conservados..."

Pues si los tienes encriptados les tendrás que dar la clave de desencriptación.

Lo que yo entiendo con esta redacción del RD es que, sin necesidad de orden judicial, un inspector de Hacienda se puede presentar en una empresa y pedir prácticamente lo que le de la gana (ya que puede exigirte contraseñas, etc). No sé hasta qué punto no se están pasando porque no controlo de temas jurídicos pero me parece que es un exceso de atribuciones y creo que esto únicamente se debería poder exigir con una orden judicial; lo considero en el mismo nivel que atribuirse el derecho a entrar en tu domicilio sin tu consentimiento sin orden judicial. Creo además que quien redacta los reales decretos es el poder ejecutivo, con lo que todavía más "inri"...

[Sistel]

Empezado por unomasmas

Lo que yo entiendo con esta redacción del RD es que, sin necesidad de orden judicial, un inspector de Hacienda se puede presentar en una empresa y pedir prácticamente lo que le de la gana (ya que puede exigirte contraseñas, etc). No sé hasta qué punto no se están pasando porque no controlo de temas jurídicos pero me parece que es un exceso de atribuciones y creo que esto únicamente se debería poder exigir con una orden judicial; lo considero en el mismo nivel que atribuirse el derecho a entrar en tu domicilio sin tu consentimiento sin orden judicial. Creo además que quien redacta los reales decretos es el poder ejecutivo, con lo que todavía más "inri"...

Hola,

La inviolabilidad del domicilio es un derecho fundamental reconocido en nuestra Constitución.
Se precisa orden judicial para entrar en un domicilio, ... salvo en el caso de delito flagrante.
(No sé si se consideraría delito flagrante estar emitiendo facturas falsas en tu casa)

Pero creo que la inviolabilidad se considera para domicilios de personas físicas, no para personas jurídicas (empresas) o locales de negocio.
Ahí creo que pueden intervenir sin orden judicial si tienen indicios fundados de que se están cometiendo delitos.
Aunque tampoco estoy totalmente seguro.

Saludos

[unomasmas]

Empezado por Sistel

Hola,

La inviolabilidad del domicilio es un derecho fundamental reconocido en nuestra Constitución.
Se precisa orden judicial para entrar en un domicilio, ... salvo en el caso de delito flagrante.
(No sé si se consideraría delito flagrante estar emitiendo facturas falsas en tu casa)

Pero creo que la inviolabilidad se considera para domicilios de personas físicas, no para personas jurídicas (empresas) o locales de negocio.
Ahí creo que pueden intervenir sin orden judicial si tienen indicios fundados de que se están cometiendo delitos.
Aunque tampoco estoy totalmente seguro.

Saludos

Gracias por la aclaración, Sistel. Con seguridad es como dices porque realmente me parecía demasiado patinazo por parte de la Administración tal y como yo lo pensaba

[Neftali [Germán.Estévez]]

¿En serio os preocupa eso?
Si se presenta un inspector de hacienda en una empresa o en tu casa, porque tiene pruebas o sospechas de que estás emitiendo facturas falsas con tu software ¿Le vas a decir que no le dejas entrar si no tiene orden judicial? O que no le das las contraseñas...

No sería lo que más me preocupa, si estoy en esa situación...

Lo que va a tardar en volver con una orden judicial va a ser la n-esima parte del tiempo que te puedes pasar en prisión tú (por diseñar el software) y el empresario (por generarlas), por un delito de "Falsedad documental" cuya pena segun "san google" va de 3 meses a 6 años de carcel, además de las consiguientes multas.

Podemos seguir discutiendo de lo que hacienda puede o no puede hacer, si queréis, yo soy el primero que confieso que de temas legales no tengo ni idea, pero para mi es una pérdia de tiempo, puesto que espero no encontrarme en esa situación (no tengo en mente generar software que permita doble contabilidad, facturas no existentes y demás...)

De verdad creo que si un inspector de hacienda se presenta en la empresa para hacer una inspeccción, no va porque se le ha ocurrido durante el desayuno o porque tiene un hueco antes de la comida. Imagino que irá con todo lo necesario según la ley, no ospreocupeis de eso.

[rci]

Hola, estoy desarrollando las compras en batuz (240 Facturas Recibidas y 140 Gastos Con Factura).

En el caso de facturas que no sean interiores, ya sea compras intracomunitarias o importaciones, entiendo que no hay iva pero igualmente tenemos que informar el bloque IVA / RentaIVA con sus correspondientes DetalleIVA / DetalleRentaIVA , para los modelos 240 y 140 respectivamente.

Dentro de estos detalles, los campos de CuotaIVASoportada y CuotaIVADeducible que valores tiene que tener? En qué casos es obligatorio informarlos?

Pensaba poner 0 porque son exentas y no hay IVA pero luego rechaza la factura con el error B4_2000124:
La Cuota IVA soportada tiene un valor incorrecto para el valor de los campos Cuota y Base imponible suministrados.


En cambio si hago igual que en una factura interior y pongo el importe de la cuota del iva de cada base tanto en CuotaIVASoportada como en CuotaIVADeducible (en el ejemplo serian 21 euros y 3 euros) en ese caso se acepta la factura sin errores, pero desde mi ignorancia me parece que las cuotas de iva soportada y deducible en esas facturas tendría que ser 0...
Disculpad pero no tengo claros esos conceptos.

Os muestro la parte final del xml que genero para este caso, en el ejemplo la factura tiene dos bases, pero con una sola da el mismo error:

...
      <CabeceraFactura>
        <NumFactura>TESTFINTRA</NumFactura>
        <FechaExpedicionFactura>01-01-2022</FechaExpedicionFactura>
        <FechaRecepcion>01-01-2022</FechaRecepcion>
        <TipoFactura>F1</TipoFactura>
      </CabeceraFactura>
      <DatosFactura>
        <DescripcionOperacion>Compras: TESTFINTRA</DescripcionOperacion>
        <Claves>
          <IDClave>
            <ClaveRegimenIvaOpTrascendencia>09</ClaveRegimenIvaOpTrascendencia>
          </IDClave>
        </Claves>
        <ImporteTotalFactura>130.00</ImporteTotalFactura>
      </DatosFactura>
      <IVA>
        <DetalleIVA>
          <CompraBienesCorrientesGastosBienesInversion>C</CompraBienesCorrientesGastosBienesInversion>
          <InversionSujetoPasivo>N</InversionSujetoPasivo>
          <BaseImponible>100.00</BaseImponible>
          <TipoImpositivo>21.00</TipoImpositivo>
          <CuotaIVASoportada>0</CuotaIVASoportada>
          <CuotaIVADeducible>0</CuotaIVADeducible>
        </DetalleIVA>
        <DetalleIVA>
          <CompraBienesCorrientesGastosBienesInversion>C</CompraBienesCorrientesGastosBienesInversion>
          <InversionSujetoPasivo>N</InversionSujetoPasivo>
          <BaseImponible>30.00</BaseImponible>
          <TipoImpositivo>10.00</TipoImpositivo>
          <CuotaIVASoportada>0</CuotaIVASoportada>
          <CuotaIVADeducible>0</CuotaIVADeducible>
        </DetalleIVA>
      </IVA>
    </FacturaRecibida>
  </FacturasRecibidas>
</LROEPJ240FacturasRecibidasAltaModifPeticion>

Muchas gracias!

[DemonAscun]

Hola,

Estamos intentando enviar facturas al servidor de pruebas de Gipuzkoa, concretamente a la dirección:

https://tbai-z.prep.gipuzkoa.eus/sarrerak/alta

y siempre nos da error 500- Internal Server Error.
¿Os sucede lo mismo?
Comenzamos a obtener este error después de la parada de mantenimiento del servidor del Jueves 17, antes de la parada la conexión era correcta pudiendo enviar altas, anulaciones, modificaciones y subsanaciones.

[Neftali [Germán.Estévez]]

Empezado por DemonAscun

Hola,
Estamos intentando enviar facturas al servidor de pruebas de Gipuzkoa, concretamente a la dirección:
https://tbai-z.prep.gipuzkoa.eus/sarrerak/alta
y siempre nos da error 500- Internal Server Error.

A mi me las está aceptando sin problemas en preproducción aquí:
https://tbai-prep.egoitza.gipuzkoa.e...nFacturas/alta

Y la URL de producción es esta::
https://tbai-z.egoitza.gipuzkoa.eus/sarrerak/alta

[txitxarru]

Hola.

Me esta surgiendo un problema a la hora de firmar y enviar el xml utilizando las secureblackbox.

Un cliente (persona física) se a instalado la tarjeta virtual del BakQ.

Lo que hace es instalarte un programita y te mete el bakQ como un certificado del sistema. Cuando intentas acceder seleccionado el certificado te pide usuario, contraseña y las coordenadas de la tarjeta de barcos.

Con autofirma funciona firma bien, pero cuando le pido a las secureblackbox que firme utilizando este certificado me devuelve el error.

Project factura.exe raised exception class EsbxXAdESSigner with message '-1: Failed to sign data
[EElPublicKeyCryptoError] Internal error (0/0x00000)'. Process stopped. Use Step or Run to continue.

¿Alguien le ha tocado lidiar con esto?.

[Sistel]

Empezado por txitxarru

Hola.

Me esta surgiendo un problema a la hora de firmar y enviar el xml utilizando las secureblackbox.

Un cliente (persona física) se a instalado la tarjeta virtual del BakQ.

Lo que hace es instalarte un programita y te mete el bakQ como un certificado del sistema. Cuando intentas acceder seleccionado el certificado te pide usuario, contraseña y las coordenadas de la tarjeta de barcos.

Con autofirma funciona firma bien, pero cuando le pido a las secureblackbox que firme utilizando este certificado me devuelve el error.

Project factura.exe raised exception class EsbxXAdESSigner with message '-1: Failed to sign data
[EElPublicKeyCryptoError] Internal error (0/0x00000)'. Process stopped. Use Step or Run to continue.

¿Alguien le ha tocado lidiar con esto?.

Hola txitxarru,

BakQ es un método de identificación, válido para acceso a muchos organismos.
Pero no es un certificado digital.

Para TicketBAI necesitas alguno de estos certificados digitales:

- Certificado digital de persona física.
- Certificado digital de representante de persona jurídica
- Sello electrónico de empresa
- Certificado digital de dispositivo.
- Certificado digital de autónomo.

Saludos

[JoseLeeTo]

Buenos días a tod@s;

Tengo una duda respecto a las Facturas Rectificativas, a ver si me podéis ayudar.

Supongamos que tenemos una Factura con serie "A", que queremos rectificar.
Ahora mismo, lo que hacemos, es realizar un Abono de la factura de la serie A, pero con signo negativo (-A)

Y por último, generamos una factura definitiva, con los datos que debería de haber tenido la factura inicial (Serie R)

Es decir: A ====> -A =====> R

A la hora del envío a Batuz, y cumplimentar el bloque de datos de Rectificativa (FacturaRectificativaType) , ¿dónde se tienen que cumplimentar dichos datos, ¿En la factura con serie "-A"? ¿O en la factura de la serie "R"? ¿O en ambas, haciendo referencia a la original?

Porque a priori, la factura "-A", que también habría que remitir a Batuz, está rectificando lo que había en la de la serie A, pero en definitiva la factura de la serie R, es la factura que rectifica la original.

¿Podéis indicarme cómo lo estáis haciendo?

Muchas gracias.
Un saludo

[Sistel]

Empezado por JoseLeeTo

Buenos días a tod@s;

Tengo una duda respecto a las Facturas Rectificativas, a ver si me podéis ayudar.

Supongamos que tenemos una Factura con serie "A", que queremos rectificar.
Ahora mismo, lo que hacemos, es realizar un Abono de la factura de la serie A, pero con signo negativo (-A)

Y por último, generamos una factura definitiva, con los datos que debería de haber tenido la factura inicial (Serie R)

Es decir: A ====> -A =====> R

A la hora del envío a Batuz, y cumplimentar el bloque de datos de Rectificativa (FacturaRectificativaType) , ¿dónde se tienen que cumplimentar dichos datos, ¿En la factura con serie "-A"? ¿O en la factura de la serie "R"? ¿O en ambas, haciendo referencia a la original?

Porque a priori, la factura "-A", que también habría que remitir a Batuz, está rectificando lo que había en la de la serie A, pero en definitiva la factura de la serie R, es la factura que rectifica la original.

¿Podéis indicarme cómo lo estáis haciendo?

Muchas gracias.
Un saludo

Hola JoseLeeTo,

Hay dos formas de registrar una factura rectificativa por sustitución.
Una forma es informando de los datos a rectificar y los datos rectificados (sin emitir ninguna factura negativa)
La otra forma es emitiendo una factura negativa (de la misma serie) y a continuación una rectificativa sin datos a rectificar, sólo con datos rectificados.

Lo tienes explicado en la pregunta 48 de https://www.batuz.eus/es/preguntas-f...egunta_7398227

Saludos

[unomasmas]

Hola a todos


Me he encontrado con un problema en un certificado de representante de empresa emitido por IZENPE.


El certificado firma la factura y se usa también para el envío a la Diputación (Gipuzkoa) y no da problemas. Sin embargo en mi código (C#) he puesto que haga una validación previa del certificado con el método Verify() de la clase X509Certificate2 (namespace System.Security.Cryptography.X509Certificates) y da este error el certificado:
+ PartialChain: No ha podido crearse una cadena de certificados en una entidad de certificación raíz de confianza


Y otros dos que entiendo que son consecuencia de este primero:
+ RevocationStatusUnknown: La función de revocación no puede comprobar la revocación para el certificado.
+ OfflineRevocation: La función de revocación no puede comprobar la revocación debido a que el servidor de revocación está sin conexión.



Me he fijado que en la "Ruta de certificación" sólo se incluye el certificado del cliente; no hay ningún otro certificado de autoridad por encima ¿sobre el que hacer la validación?. Entiendo que seguramente esto es lo que impide hacer la comprobación y provoca la rotura de la cadena generando el error. Pero no estoy completamente seguro de si esto es así.


Si tienes un certificado de IZENPE ¿Puedes verificar la ruta de certificación que tienes? ¿Se muestra solo ese certificado o se encadena con otros? Puedes acceder a ella (en Windows) desde el Panel de Control->Opciones de Internet (pestaña Contenido). Pinchas en Certificados. Seleccionas el Certificado. Pinchas en Ver y ahí puedes verlo en la pestaña "Ruta de certifiación".



Gracias.