Foros Club Delphi - Ley antifraude 2021 (VERIFACTU)

Foros Club Delphi (https://www.clubdelphi.com/foros/index.php)

- Internet (https://www.clubdelphi.com/foros/forumdisplay.php?f=3)

- - Ley antifraude 2021 (VERIFACTU) - Programas informáticos (https://www.clubdelphi.com/foros/showthread.php?t=95235)

Cita:

Empezado por rci (Mensaje 557813)

Hola Sistel, como lo haces?
En cada venta, antes de salvarla (y por lo tanto antes de generar TicketBAI / VeriFactu), compruebas si el numero de identificación introducido es correcto contactando con el webservice?
y si contesta que no es correcto muestras un error y no permites salvar hasta que hayan introducido un NIF correcto?

Muchas gracias

Hola,

Efectivamente, para las facturas con destinatario, se conecta al webservice de la AEAT y comprueba si el NIF y nombre son correctos.
Si no lo son, doy mensaje de error y no dejo emitir esa factura.

Saludos

Cita:

Empezado por Neftali [Germán.Estévez] (Mensaje 557817)

¿Y si se "cae" la conexión a Internet no se emiten facturas?
Creo que eso no debería ser así. Debes poder emitir aunque no tengas conexión.

Hola,

Mi sistema es una API en la nube.
Si no hay conexión a Internet, no puedes facturar (lo mismo que si se te va la luz).
Para garantizar conexión permanente a Internet, siempre se puede utilizar un router 4G de backup que conmuta automáticamente y saca el tráfico por la red de telefonía móvil si se cae la conexión por la fibra.
Y con un SAI ya bordas la instalación.

Saludos

acaso pretenden que cada ticket que emita un bar, tienda de calzado, peluqueria... etc, se vayan pidiendo los DNI a todo dios ...

Cita:

Empezado por jguarda (Mensaje 557822)

acaso pretenden que cada ticket que emita un bar, tienda de calzado, peluqueria... etc, se vayan pidiendo los DNI a todo dios ...

No, en ese caso pueden ser facturas simplificadas, sin identificar el destinatario.
Pero si quieres emitir una factura completa, los datos del destinatario (incluido el DNI) tienen que constar y ser correctos

Cita:

Empezado por rci (Mensaje 557818)

Imagino que en ese caso el programa de Sistel cruza los dedos para que sea correcto y permite salvar.:p

Hola,

Hoy por hoy las redes de fibra y 4G son muy estables.
En los más de 2 años que llevamos dando servicio TicketBAI a casi 300 usuarios (principalmente comercios, bares y restaurantes) las incidencias por corte de conexión han sido anecdóticas.
Y la ventaja de tener todo centralizado, guardado y a salvo del usuario en servidores de Internet ... no tiene precio.

Saludos

Cita:

Empezado por rci (Mensaje 557823)

Lo mismo que ahora.
La única diferencia que hasta ahora se hacía en papel y con Verifactu se hará también electrónico.
Pero la normativa de facturación es la misma de siempre.

Cita:

Empezado por pablog2k (Mensaje 557800)

si que está validando lo de la huella ... lo que pasa es que te la da aceptada con errores:
ejemplo:
registro con huella mal:

Código PHP:


		
			
<tikR:EstadoRegistro>AceptadoConErrores</tikR:EstadoRegistro>



<tikR:CodigoErrorRegistro>2000</tikR:CodigoErrorRegistro>

registro con huella bien:

Código PHP:


		
			
<tikR:EstadoRegistro>Correcto</tikR:EstadoRegistro>

como comenté, para poder arreglar las huellas de todos los documentos, tienes que empezar por el primero que esté mal, e ir subiendolo como subsanacion

perdón , a ver si sobre esto me podeís ayudar.
me acepta las facturas, pero con con errores por el tema de la firma, si realmente las está validando, no lo entiendo.

Cita:

<tikR:RespuestaLinea>
<tikR:IDFactura>
<tik:IDEmisorFactura>XXXXXXX</tik:IDEmisorFactura>
<tik:NumSerieFactura>0F240006</tik:NumSerieFactura>
<tik:FechaExpedicionFactura>22-01-2024</tik:FechaExpedicionFactura>
</tikR:IDFactura>
<tikR:EstadoRegistro>AceptadoConErrores</tikR:EstadoRegistro>
<tikR:CodigoErrorRegistro>2000</tikR:CodigoErrorRegistro>
<tikR:DescripcionErrorRegistro>El cálculo de la huella suministrada es incorrecta. Datos de entrada cálculo huella: IDEmisorFactura=XXXXXXX&NumSerieFactura=0F240006&FechaExpedicionFactura=22-01-2024&TipoFactura=F1&CuotaTotal=420.00&ImporteTotal=2420.00&Huella=&FechaHoraHusoGenRegistro=2024-10-03T16:15:03+02:00 Huella calculada: A8925885A65EB9F41DEEFAEBF9971DB688DC8F92D35B38ACACD34318FEEF3104</tikR:DescripcionErrorRegistro>

</tikR:RespuestaLinea>

estoy creando la huella con :

Código Delphi [-] Result := THashSHA2.GetHashString(CadenaVerifactu,THashSHA2.TSHA2Version.SHA256);

pensaba enviar está consulta a la aeat,,, ¿ la dirección correcta de soporte para estas consultas seria : [email protected] ?, ¿ o hay alguna específica para soporte informático a verifactu ?

Cita:

Empezado por Galahad (Mensaje 557826)

pensaba enviar está consulta a la aeat,,, ¿ la dirección correcta de soporte para estas consultas seria : [email protected] ?, ¿ o hay alguna específica para soporte informático a verifactu ?

Mejor aquí:

[email protected]

Saludos

Gracias a todos por vuestras respuestas.

Parece claro que es un problema de windows 7 con TLS 1.2, yo lo tengo activado como me comentáis y no funciona. Voy a probar a meter un parche de seguridad que me recomienda mi ultimo gran amigo (chatgpt) :D y os comento para tenerlo claro.

Saludos.

Si, ya te comentaba que en el 7 habia que aplicar un parche.

Cita:

Empezado por bmfranky (Mensaje 557831)

Si, ya te comentaba que en el 7 habia que aplicar un parche.

Cierto... voy a ello. :)

supongo que el envío a veri*factu de facturas (simplificadas), habrá que meterlo en un tThread distinto al hilo principal xq sino el terminal se quedará tostado hasta que termine el envio y recepción del resultado. Creo que esto es un problema tanto para el cliente como para nosotros. Si alguien quiere su ticket inmediato después de haber por ejemplo comprado algo en una tienda, el de la tienda tiene que pasar esto inmediatamente a veri*factu, por lo que se van a liar una colas de gente en ciertos negocios tremendas, amen de los cuelgues por falta de comunicación en la hacienda publica, y se me ocurren otro montón de situaciones, en donde veo inviable esto que pretenden.

Imaginemos alguien, que decide quitar internet de su negocio, pero quiere usar su sistema informático para dar un ticket al cliente. Hacienda le pagará el internet para que emita sus tickes a veri*factu, o le multará, en fin ... no se

al final, libreta y boligrafo y el que quiera factura ya se le mandara por carta postal, jejej

Leo varios post referidos a, qué hacer cuando rechazan una factura o la aceptan parcialmente, y veo que la mayoría de los post no son correctos y puede llegar a confusión este galimatías. En mi opinión y con el Reglamento de Facturación vigente y el Reglamento Verifactu, si te rechazan una factura y tienes contenido en la propiedad Respuestalinea del objeto Respuesta donde se especifica el motivo del rechazo, significa que la Aeat ha logrado parsear el registro enviado, situación distinta a la ocurrida cuando el servicio de la Aeat no ha podido hacerlo porque está fuera de línea, no tenemos Internet o nuestro modelo Xml no es correcto. En estos casos se recibe un objeto Respuesta con todas sus propiedades a Nothing o Null pero con la propiedad EstadoDeEnvio = Incorrecto. Sólo en este caso podremos reenviar el paquete de nuevo, ya que la Aeat no tiene nada registrado de este paquete.

Si recibimos contenido en la propiedad Respuestalinea del objeto Respuesta, sea lo que sea, ya no podrás volver a reenviar los registros que contenía dicho paquete, hayan venido Incorrectos o Parcialmente Correctos.
Disponemos de herramientas para solventar este caso.

La primera es subsanar el registro creando un Nuevo registro de Subsanación y olvidándote del registro rechazado, sólo puede corregir datos que no impliquen la emisión de una factura rectificativa, por ejemplo errores en fecha de operación, régimen tributario, la huella generada....Puedes generar un Alta por rechazo previo o un Alta por Subsanación sin rechazo previo según sea el caso

Y la segunda es nuestra querida amiga la Factura Rectificativa. Si nos rechazan una factura porque el tipo impositivo no existe, te tienes que olvidar de ese registro de facturación y emitir una factura rectificativa por sustitución haciendo referencia a esa factura rechazada para corregir ese error. Quedará un hueco en las facturas que tiene la Aeat (nos ha rechazado la factura) pero eso es normal ya que NO PODEMOS modificar facturas para arreglarlas. Haciendo referencia a dicha factura a través de la rectificación justificamos en la Aeat la existencia de ese hueco.

Cita:

Empezado por jguarda (Mensaje 557834)

hola , el proceso de generar el ticket, con el QR, es independiente a subir ese ticket a verifactu. De hecho, si tienes un corte de internet en un comercio, puedes (y debes)seguir emitiendo tickets sin problemas, y si el cliente se queja de que el QR no lleva a ningún sitio, le dices que estás sin internet y que a lo largo del día estará operativo el QR.
A mi tambien me parece inviable lo que pretenden hacer, pero porque no creo que estén preparados para recibir tantisima información de todos los comercios enviando registros. El modelo que pretenden implantar ya está operativo en el pais vasco, y desde este foro te pueden comentar compañeros que al final se ha implantado y la gente a tenido que pasar por el aro

Cita:

Empezado por Galahad (Mensaje 557826)

perdón , a ver si sobre esto me podeís ayudar.
me acepta las facturas, pero con con errores por el tema de la firma, si realmente las está validando, no lo entiendo.

estoy creando la huella con :

Código Delphi [-] Result := THashSHA2.GetHashString(CadenaVerifactu,THashSHA2.TSHA2Version.SHA256);

pensaba enviar está consulta a la aeat,,, ¿ la dirección correcta de soporte para estas consultas seria : [email protected] ?, ¿ o hay alguna específica para soporte informático a verifactu ?

hola , en la pagina 1 de este hilo tienes un ejemplo de como crear el hash, utiliza una de las librerías que incorpora DelphiXE8 creo, incluso la puedes generar como DLL por si tienes versiones mas antiguas de delphi

Cita:

Empezado por pablog2k (Mensaje 557837)

Hola,

Efectivamente, aquí, en el País Vasco, TicketBAI (que viene a ser, prácticamente, lo mismo que Verifactu) lleva ya varios años funcionando.
Al principio, la gente se echaba las manos a la cabeza con los posibles problemas: cortes, lentitud y demás.
Pero se ha comprobado que no: todo funciona, en general, sin problemas.

Hoy por hoy, no hay problemas en ningún sitio para tener Internet (por fibra, por 3G/4G, por satélite o combinados)

Y respecto a lo que leí sobre si Hacienda va a pagar la conexión a Internet necesaria en todos los comercios y negocios que emitan factura:
En el País Vasco, las Haciendas Forales permiten una deducción extraordinaria del 30% del importe de la implantación de TicketBAI (ordenadores, TPVs, impresoras, software, implantación, formación, ...)
(Si le le suma la deducción del IVA y la reducción por gasto del Impuesto de Sociedades o del IRPF, el coste final de la implantación es mínimo)
Muchos comercios han aprovechado esta oferta para actualizar sus equipos informáticos.
Aparte, la Hacienda Foral de Bizkaia también concede otra deducción del Impuesto de Sociedades o del IRPF si se entra voluntariamente en el sistema antes de la fecha que corresponda.
A las Haciendas les merece la pena casi regalar todos los costes a cambio de tener información instantánea de las facturas emitidas que ya no podrán ser objeto de fraude (borrado o manipulación antes de la declaración de IVAs)
No sé si al final la AEAT también permitirá deducciones especiales por los gastos de implantación de Verifactu.

Respecto al tema de la posible lentitud con la comprobación del NIF y nombre del destinatario (utilizando el webservice de AEAT) + los envíos de los datos de la factura a Hacienda:
Nos ha sorprendido lo bien que va.
Nuestro sistema, por ejemplo, recibe (en un servidor en la nube) los datos de la factura a emitir, hace las verificaciones, grabaciones, creación del XML, firma del XML, cálculo del código TBAI y del código QR retorno de todos los datos al comercio y envío (encolado) a Hacienda en unos 150-200 milisegundos de media.
La verdad es que no tenemos prácticamente nunca problemas de saturación.

Está claro que cuando la mayoría de los países de la UE ya tienen en marcha un sistema similar a Verifactu, es que se puede.

Saludos.

Cita:

Empezado por newtron (Mensaje 557830)

Parece claro que es un problema de windows 7 con TLS 1.2, yo lo tengo activado como me comentáis y no funciona. Voy a probar a meter un parche de seguridad que me recomienda mi ultimo gran amigo (chatgpt) :D y os comento para tenerlo claro.

https://learn.microsoft.com/es-es/me...tls-1-2-client

Cita:

Empezado por jguarda (Mensaje 557834)

Cita:

Empezado por pablog2k (Mensaje 557837)

[pablog2k] ya lo ha dicho.
Ambos procesos DEBEN ser independientes (generación y envío).
Lo lógico es montar una cola de envío que vaya enviando las facturas "a medida que pueda".
Si "se cae" internet, pues cuando vuelva las enviará todas.
Ya sea con un thread independiente, un programa independiente, un servicio,....

Novedades - Actualización de documentación

Buenas,

Han vuelto a publicar novedades:
https://www.agenciatributaria.es/AEA...olladores.html

Saludos,
David M.

Publicado esta madrugada (04/10/2024)

VERI*FACTU - Actualización de documentación en sistemas VERI*FACTU: Se ha publicado una nueva versión de la documentación asociada a los sistemas VERI*FACTU:

- Diseño de registro (0.14.4), con nuevo campo RefExterna y modificaciones en bloque RemisionRequerimiento y actualización en listas de claves de régimen. Se actualizan los esquemas XSD en consonancia.
- Documento de Validaciones y errores (0.9.0), con modificaciones asociadas a cambios en tipos de impuesto y claves de régimen, además de incluir un enlace al listado de códigos de error. Los cambios se muestran resaltados en amarillo, se encuentran pendientes de publicación en el entorno de Pruebas Externas. Se estima que estarán disponibles en las próximas semanas.
- Documento de Especificaciones técnicas del código QR (0.4.5), con modificaciones en los mensajes para sistemas que emitan facturas no verifacables y códigos de error.

Ante cualquier duda/sugerencia y/o falta de corrección sobre la nueva información publicada, se recuerda el buzón de consultas técnicas de VERI*FACTU:
[email protected]

Actualizo el mensaje#1 y el FTP

Sobre la falta de informacion sobre el comprobante WEB de la factura anulada, me dicen que lo van a consultar.

Informacion de la AEAT sobre presentar anulaciones sobre la misma factura:

Cita:

De forma detallada. Una secuencia correcta y válida es:

1. Se presenta inicialmente el alta de una factura que tiene este IDFactura:

<IDEmisorFactura>xxxxx</IDEmisorFactura>
<NumSerieFactura>F240003</NumSerieFactura>
<FechaExpedicionF>21-01-2024</FechaExpedicionFactura>

*Nota: Y además, el resto de información de la factura en sí, y del propio registro (encadenamiento, huella, etc.)

2. Posteriormente, se envía un registro de "Anulación", que apunta a ese mismo IDFactura:

<IDEmisorFacturaAnulada>xxxx</IDEmisorFacturaAnulada>
<NumSerieFacturaAnulada>F240003</NumSerieFacturaAnulada>
<FechaExpedicionFacturaAnulada>21-01-2024</FechaExpedicionFacturaAnulada>

*Nota: esto hace que esa factura pase a estar en estado anulada. El registro enviado tiene su propia huella, su propio encadenamiento con la factura anterior (que podría ser de alta o de anulación, cualquiera que haya sido expedida inmediatamente antes en ese SIF y para ese OEF). Remitiéndonos a la imagen que le adjuntamos antes, el resultado sería el que pone OK (7): "El registro remitido anula el registro de facturación de alta registrado dejando los nuevos datos recibidos."

3. Posteriormente, se envía otro registro de "Anulación", que apunta a ese mismo IDFactura:

<IDEmisorFacturaAnulada>xxx</IDEmisorFacturaAnulada>
<NumSerieFacturaAnulada>F240003</NumSerieFacturaAnulada>
<FechaExpedicionFacturaAnulada>21-01-2024</FechaExpedicionFacturaAnulada>

*Nota: esto actualiza los datos de esa factura, que seguirá estando anulada. El registro enviado tiene su propia huella, su propio encadenamiento con la factura anterior (que podría ser de alta o de anulación, cualquiera que haya sido expedida inmediatamente antes en ese SIF y para ese OEF). Remitiéndonos a la imagen que le adjuntamos antes, el resultado sería el que pone OK (8): "El registro remitido anula el registro de facturación de anulación registrado dejando los nuevos datos recibidos".

¿Por qué se admite esto? Porque —por ejemplo— podría ser necesario corregir la huella del registro de facturación que se envió en el punto 2, dado que ha sido "Aceptado con errores" porque hubo algún error en el encadenamiento. Así que se envía otro registro de anulación realizando un encadenamiento correcto.

Es decir, esta operación no debería ser algo habitual, pero sí que se contempla para corregir posibles datos erróneos de un registro de anulación previamente presentado (teniendo en cuenta los "pocos" datos erróneos que se pueden dar en un registro de anulación, dado que no incluye tanto detalle de la factura como los de Alta, pero sí que contiene otros datos que hacen referencia a los registros de facturación y que son susceptibles de enviarse mal —y así se permite corregirlos posteriormente—).

Ese es el motivo por el que se admite más de un registro de anulación sobre un mismo IDFactura. Esperamos haberle despejado esa duda.

Listado codigos de errror.

Han puesto en linea un listado d los codigos de error devueltos, https://prewww2.aeat.es/static_files...res.properties

Código PHP:


		
			
********* Listado de códigos de error que provocan el rechazo del envío completo ********* 

4102 = El XML no cumple el esquema. Falta informar campo obligatorio.

4103 = Se ha producido un error inesperado al parsear el XML.

4104 = Error en la cabecera: el valor del campo NIF del bloque ObligadoEmision no está identificado.

4105 = Error en la cabecera: el valor del campo NIF del bloque Representante no está identificado.

4106 = El formato de fecha es incorrecto.

4107 = El NIF no está identificado en el censo de la AEAT.

4108 = Error técnico al obtener el certificado.

4109 = El formato del NIF es incorrecto.

4110 = Error técnico al comprobar los apoderamientos.

4111 = Error técnico al crear el trámite.

4112 = El titular del certificado debe ser Obligado Emisión, Colaborador Social, Apoderado o Sucesor.

4113 = El XML no cumple con el esquema: se ha superado el límite permitido de registros para el bloque.

4114 = El XML no cumple con el esquema: se ha superado el límite máximo permitido de facturas a registrar.

4115 = El valor del campo NIF del bloque ObligadoEmision es incorrecto.

4116 = Error en la cabecera: el campo NIF del bloque ObligadoEmision tiene un formato incorrecto.

4117 = Error en la cabecera: el campo NIF del bloque Representante tiene un formato incorrecto.

4118 = Error técnico: la dirección no se corresponde con el fichero de entrada.

4119 = Error al informar caracteres cuya codificación no es UTF-8.

4120 = Error en la cabecera: el valor del campo FechaFinVeriFactu es incorrecto, debe ser 31-12-20XX, donde XX corresponde con el año actual o el anterior.

4121 = Error en la cabecera: el valor del campo Incidencia es incorrecto.

4122 = Error en la cabecera: el valor del campo RefRequerimiento es incorrecto.

4123 = Error en la cabecera: el valor del campo NIF del bloque Representante no está identificado en el censo de la AEAT.

4124 = Error en la cabecera: el valor del campo Nombre del bloque Representante no está identificado en el censo de la AEAT.

4125 = Error en la cabecera: el campo RefRequerimiento es obligatorio.

4126 = Error en la cabecera: el campo RefRequerimiento solo debe informarse en sistemas no VERIFACTU.

4127 = Error en la cabecera: la remisión voluntaria solo debe informarse en sistemas VERIFACTU.

4128 = Error técnico en la recuperación del valor del Gestor de Tablas.

3500 = Error técnico de base de datos: error en la integridad de la información.

3501 = Error técnico de base de datos.

3502 = La factura consultada para el suministro de pagos/cobros/inmuebles no existe.

3503 = La factura especificada no pertenece al titular registrado en el sistema.



********* Listado de códigos de error que provocan el rechazo de la factura (o de la petición completa si el error se produce en la cabecera) ********* 

1100 = Valor o tipo incorrecto del campo.

1101 = El valor del campo CodigoPais es incorrecto.

1102 = El valor del campo IDType es incorrecto.

1103 = El valor del campo ID es incorrecto.

1104 = El valor del campo NumSerieFactura es incorrecto.

1105 = El valor del campo FechaExpedicionFactura es incorrecto.

1106 = El valor del campo TipoFactura no está incluido en la lista de valores permitidos.

1107 = El valor del campo TipoRectificativa es incorrecto.

1108 = El NIF del IDEmisorFactura debe ser el mismo que el NIF del ObligadoEmision.

1109 = El NIF no está identificado en el censo de la AEAT.

1110 = El NIF no está identificado en el censo de la AEAT.

1111 = El campo CodigoPais es obligatorio cuando IDType es distinto de 02.

1112 = El campo FechaExpedicionFactura es superior a la fecha actual.

1114 = Si la factura es de tipo rectificativa, el campo TipoRectificativa debe tener valor.

1115 = Si la factura no es de tipo rectificativa, el campo TipoRectificativa no debe tener valor.

1116 = Debe informarse el campo FacturasSustituidas sólo si la factura es de tipo F3.

1117 = Si la factura no es de tipo rectificativa, el bloque FacturasRectificadas no podrá venir informado.

1118 = Si la factura es de tipo rectificativa por sustitución el bloque ImporteRectificacion es obligatorio.

1119 = Si la factura no es de tipo rectificativa por sustitución el bloque ImporteRectificacion no debe tener valor.

1120 = Valor de campo IDEmisorFactura del bloque IDFactura con tipo incorrecto.

1121 = El campo ID no está identificado en el censo de la AEAT.

1122 = El campo CodigoPais indicado no coincide con los dos primeros dígitos del identificador.

1123 = El formato del NIF es incorrecto.

1124 = El valor del campo TipoImpositivo no está incluido en la lista de valores permitidos.

1125 = El valor del campo FechaOperacion tiene una fecha superior a la permitida.

1126 = El valor del CodigoPais solo puede ser ES cuando el IDType sea 07 o 03. Si IDType es 07 el CodigoPais debe ser ES.

1127 = El valor del campo TipoRecargoEquivalencia no está incluido en la lista de valores permitidos.

1128 = No existe acuerdo de facturación.

1129 = Error técnico al obtener el acuerdo de facturación.

1130 = El campo NumSerieFactura contiene caracteres no permitidos.

1131 = El valor del campo ID ha de ser el NIF de una persona física cuando el campo IDType tiene valor 07.

1132 = El valor del campo TipoImpositivo es incorrecto, el valor informado solo es permitido para FechaOperacion o FechaExpedicionFactura inferior o igual al aÃ±o 2012.

1133 = El valor del campo FechaExpedicionFactura no debe ser inferior a la fecha actual menos veinte aÃ±os.

1134 = El valor del campo FechaOperacion no debe ser inferior a la fecha actual menos veinte aÃ±os.

1135 = El valor del campo TipoRecargoEquivalencia es incorrecto, el valor informado solo es permitido para FechaOperacion o FechaExpedicionFactura inferior o igual al aÃ±o 2012.

1136 = El campo FacturaSimplificadaArticulos7273 solo acepta valores N o S.

1137 = El campo Macrodato solo acepta valores N o S.

1138 = El campo Macrodato solo debe ser informado con valor S si el valor de ImporteTotal es igual o superior a +-100.000.000

1139 = Si el campo ImporteTotal está informado y es igual o superior a +-100.000.000 el campo Macrodato debe estar informado con valor S.

1140 = Los campos CuotaRepercutida y BaseImponibleACoste deben tener el mismo signo.

1142 = El campo CuotaRepercutida tiene un valor incorrecto para el valor de los campos BaseImponibleOimporteNoSujeto y TipoImpositivo suministrados.

1143 = Los campos CuotaRepercutida y BaseImponibleOimporteNoSujeto deben tener el mismo signo.

1144 = El campo CuotaRepercutida tiene un valor incorrecto para el valor de los campos BaseImponibleACoste y TipoImpositivo suministrados.

1145 = Formato de fecha incorrecto.

1146 = Excepto para ClaveRegimen 14 o 15, la FechaExpedicionFactura no puede ser anterior a la FechaOperacion.

1147 = Si ClaveRegimen es 14, FechaOperacion es obligatoria y debe ser posterior a la FechaExpedicionFactura.

1148 = Si la ClaveRegimen es 14, el campo TipoFactura debe ser F1, R1, R2, R3 o R4.

1149 = Si ClaveRegimen es 14, el NIF de Destinatarios debe estar identificado en el censo de la AEAT y comenzar por P, Q, S o V.

1150 = Cuando TipoFactura sea F2 y no este informado NumRegistroAcuerdoFacturacion o FacturaSinIdentifDestinatarioArt61d no sea S el sumatorio de BaseImponibleOimporteNoSujeto y CuotaRepercutida de todas las líneas de detalle no podrá ser superior a 3.000.

1151 = El campo GeneradoPorTercerosODestinatario solo acepta valores D o T.

1152 = La fecha de expedicion de la factura no puede ser inferior al indicado en la Orden Ministerial.

1153 = Valor del campo RechazoPrevio no válido, solo podrá incluirse el campo RechazoPrevio con valor X si se ha informado el campo Subsanacion y tiene el valor S.

1154 = El NIF del emisor de la factura rectificada/sustitutiva no se ha podido identificar en el censo de la AEAT.

1155 = Se está informando el bloque Tercero sin estar informado el campo EmitidaPorTerceroODestinatario.

1156 = Para el bloque IDOtro y IDType 02, el valor de TipoFactura es incorrecto.

1157 = El valor de cupón solo puede ser S o N si está informado. El valor de cupón sólo puede ser S si el tipo de factura es R1 o R5.

1158 = Se está informando EmitidaPorTerceroODestinatario, pero no se informa el bloque correspondiente. 

1159 = Se está informando del bloque Tercero cuando se indica que se va a informar de Destinatario.

1160 = Si el TipoImpositivo es 5%, sólo se admite TipoRecargoEquivalencia 0,5 o 0,62.

1161 = El valor del campo RechazoPrevio no es válido, sólo podrá incluirse el campo RechazoPrevio con valor X si se ha informado el campo Subsanacion y tiene el valor S.

1162 = Si el TipoImpositivo es 21%, sólo se admite TipoRecargoEquivalencia 5,2 ó 1,75.

1163 = Si el TipoImpositivo es 10%, sólo se admite TipoRecargoEquivalencia 1,4.

1164 = Si el TipoImpositivo es 4%, sólo se admite TipoRecargoEquivalencia 0,5.

1165 = Si el TipoImpositivo es 0% entre el 1 de enero de 2023 y el 30 de septiembre de 2024, sólo se admite TipoRecargoEquivalencia 0.

1166 = Si el TipoImpositivo es 2% entre el 1 de octubre de 2024 y el 31 de diciembre de 2024, sólo se admite TipoRecargoEquivalencia 0,26.

1167 = Si el TipoImpositivo es 5% entre el 1 de julio de 2022 y el 31 de diciembre de 2022, sólo se admite TipoRecargoEquivalencia 0,5.

1168 = Si el TipoImpositivo es 5% entre el 1 de enero de 2023 y el 30 de septiembre de 2024, sólo se admite TipoRecargoEquivalencia 0,62.

1169 = Si el TipoImpositivo es 7,5% entre el 1 de octubre de 2024 y el 31 de diciembre de 2024, sólo se admite TipoRecargoEquivalencia 1.

1170 = Si el TipoImpositivo es 0%, desde el 1 de octubre del 2024, sólo se admite TipoRecargoEquivalencia 0,26.

1171 = El valor del campo Subsanacion o RechazoPrevio no se encuentra en los valores permitidos.

1172 = El valor del campo NIF u ObligadoEmision son nulos.

1173 = Sólo se permite que la fecha de operación sea superior a la fecha actual si los detalles del desglose son ClaveRegimen=  14 o 15.

1174 = El valor del campo FechaExpedicionFactura del bloque RegistroAnteriores incorrecto.

1175 = El valor del campo NumSerieFactura del bloque RegistroAnterior es incorrecto.

1176 = El valor de campo NIF del bloque SistemaInformatico es incorrecto.

1177 = El valor de campo IdSistemaInformatico del bloque SistemaInformatico es incorrecto.

1178 = Error en el bloque de Tercero.

1179 = Error en el bloque de SistemaInformatico.

1180 = Error en el bloque de Encadenamiento.

1181 = El valor del campo CalificacionOperacion es incorrecto.

1182 = El valor del campo OperacionExenta es incorrecto.

1183 = El campo FacturaSimplificadaArticulos7273 solo se podrá rellenar con S si TipoFactura es de tipo F1 o F3 o R1 o R2 o R3 o R4.

1184 = El campo FacturaSinIdentifDestinatarioArt61d solo acepta valores S o N.

1185 = El campo FacturaSinIdentifDestinatarioArt61d solo se podrá rellenar con S si TipoFactura es de tipo F2 o R5.

1186 = Si EmitidaPorTercerosODestinatario es igual a T el bloque Tercero será de cumplimentación obligatoria.

1187 = Sólo se podrá cumplimentarse el bloque Tercero si el valor de EmitidaPorTercerosODestinatario es T.

1188 = El NIF del bloque Tercero debe ser diferente al NIF del ObligadoEmision.

1189 = Si TipoFactura es F1 o F3 o R1 o R2 o R3 o R4 el bloque Destinatarios tiene que estar cumplimentado.

1190 = Si TipoFactura es F2 o R5 el bloque Destinatarios no puede estar cumplimentado.

1191 = Si TipoFactura es R3 sólo se admitirá NIF o IDType = 07.

1192 = Si TipoFactura es R2 sólo se admitirá NIF o IDType = 07 o 02.

1193 = En el bloque Destinatarios si se identifica mediante NIF, el NIF debe estar identificado y ser distinto del NIF ObligadoEmision.

1194 = El valor del campo TipoImpositivo es incorrecto, el valor informado solo es permitido para FechaOperacion o FechaExpedicionFactura posterior o igual a 1 de julio de 2022 e inferior o igual a 30 de septiembre de 2024.

1195 = Al menos uno de los dos campos OperacionExenta o CalificacionOperacion deben estar informados.

1196 = OperacionExenta o CalificacionOperacion no pueden ser ambos informados ya que son excluyentes entre sí.

1197 = Si CalificacionOperacion es S2 TipoFactura solo puede ser F1, F3, R1, R2, R3 y R4.

1198 = Si CalificacionOperacion es S2 TipoImpositivo y CuotaRepercutida deberan tener valor 0.

1199 = Si ClaveRegimen es 01 no pueden marcarse las OperacionExenta E2, E3.

1200 = Si ClaveRegimen es 03 CalificacionOperacion sólo puede ser S1.

1201 = Si ClaveRegimen es 04 CalificacionOperacion sólo puede ser S2 o bien OperacionExenta.

1202 = Si ClaveRegimen es 06 TipoFactura no puede ser F2, F3, R5 y BaseImponibleACoste debe estar cumplimentado.

1203 = Si ClaveRegimen es 07 OperacionExenta no puede ser E2, E3, E4 y E5 o CalificacionOperacion no puede ser S2, N1, N2.

1205 = Si ClaveRegimen es 10 CalificacionOperacion tiene que ser N1, TipoFactura F1 y Destinatarios estar identificada mediante NIF.

1206 = Si ClaveRegimen es 11 TipoImpositivo ha de ser 21%.

1207 = La CuotaRepercutida solo podrá ser distinta de 0 si CalificacionOperacion es S1.

1208 = Si CalificacionOperacion es S1 y ClaveRegimen es distinto de 06, TipoImpositivo y CuotaRepercutida son obligatorios.

1209 = Si CalificacionOperacion es S1 y ClaveRegimen es 06, TipoImpositivo y CuotaRepercutida son obligatorios.

1210 = El campo ImporteTotal tiene un valor incorrecto para el valor de los campos BaseImponibleOimporteNoSujeto, CuotaRepercutida y CuotaRecargoEquivalencia suministrados.

1211 = El bloque Tercero no puede estar identificado con IDType=07 (no censado).

1212 = El campo TipoUsoPosibleSoloVerifactu solo acepta valores N o S.

1213 = El campo TipoUsoPosibleMultiOT solo acepta valores N o S.

1214 = El campo NumeroOTAlta debe ser nÃºmerico positivo de 4 posiciones.

1215 = Error en el bloque de ObligadoEmision.

1216 = El campo CuotaTotal tiene un valor incorrecto para el valor de los campos CuotaRepercutida y CuotaRecargoEquivalencia suministrados.

1217 = Error identificando el IDEmisorFactura.

1218 = El valor del campo Impuesto es incorrecto.

1219 = El valor del campo IDEmisorFactura es incorrecto.

1220 = El valor del campo NombreSistemaInformatico es incorrecto.

1221 = El valor del campo IDType del sistema informático es incorrecto.

1222 = El valor del campo ID del bloque IDOtro es incorrecto.

1223 = En el bloque SistemaInformatico si se cumplimenta NIF, no deberá existir la agrupación IDOtro y viceversa, pero es obligatorio que se cumplimente uno de los dos.

1224 = Si se informa el campo GeneradoPor deberá existir la agrupación Generador y viceversa.

1225 = El valor del campo GeneradoPor es incorrecto.

1226 = El campo IndicadorMultiplesOT solo acepta valores N o S.

1227 = Si el campo GeneradoPor es igual a E debe estar relleno el campo NIF del bloque Generador.

1228 = En el bloque Generador si se cumplimenta NIF, no deberá existir la agrupación IDOtro y viceversa, pero es obligatorio que se cumplimente uno de los dos.

1229 = Si el valor de GeneradoPor es igual a T el valor del campo IDType del bloque Generador no debe ser 07 (No censado).

1230 = Si el valor de GeneradoPor es igual a D y el CodigoPais tiene valor ES, el valor del campo IDType del bloque Generador debe ser 03 o 07.

1231 = El valor del campo IDType del bloque Generador es incorrecto.

1232 = Si se identifica a través de la agrupación IDOtro y CodigoPais tiene valor ES, el campo IDType debe valer 03.

1233 = Si se identifica a través de la agrupación IDOtro y CodigoPais tiene valor ES, el campo IDType debe valer 07.

1234 = Si se identifica a través de la agrupación IDOtro y CodigoPais tiene valor ES, el campo IDType debe valer 03 o 07.

1235 = El valor del campo TipoImpositivo es incorrecto, el valor informado sólo es permitido para FechaOperacion o FechaExpedicionFactura posterior o igual a 1 de octubre de 2024 e inferior o igual a 31 de diciembre de 2024.

1236 = El valor del campo TipoImpositivo es incorrecto, el valor informado solo es permitido para FechaOperacion o FechaExpedicionFactura posterior o igual a 1 de octubre de 2024 e inferior o igual a 31 de diciembre de 2024.

1237 = El valor del campo CalificacionOperacion está informado como N1 o N2 y el impuesto es IVA. No se puede informar de los campos TipoImpositivo (excepto con ClaveRegimen 17), CuotaRepercutida (excepto con ClaveRegimen 17), TipoRecargoEquivalencia y CuotaRecargoEquivalencia.

1238 = Si la operacion es exenta no se puede informar ninguno de los campos TipoImpositivo, CuotaRepercutida, TipoRecargoEquivalencia y CuotaRecargoEquivalencia.

1239 = Error en el bloque Destinatario.

1240 = Error en el bloque de IdEmisorFactura.

1241 = Error técnico al obtener el SistemaInformatico.

1242 = No existe el sistema informático. 

1243 = Error técnico al obtener el cálculo de la fecha del huso horario.

1244 = El campo FechaHoraHusoGenRegistro tiene un formato incorrecto.

1245 = Si el campo Impuesto está vacío o tiene valor 01 o 03 el campo ClaveRegimen debe de estar cumplimentado.

1246 = El valor del campo ClaveRegimen es incorrecto.

1247 = El valor del campo TipoHuella es incorrecto. 

1248 = El valor del campo Periodo es incorrecto.

1249 = El valor del campo IndicadorRepresentante tiene un valor incorrecto.

1250 = El valor de fecha desde debe ser menor que el valor de fecha hasta en RangoFechaExpedicion. 

1251 = El valor del campo IdVersion tiene un valor incorrecto

1252 = Si ClaveRegimen es 08 el campo CalificacionOperacion tiene que ser N2 e ir siempre informado.

1253 = El valor del campo RefExterna tiene un valor incorrecto.

1254 = Si FechaOperacion (FechaExpedicionFactura si no se informa FechaOperacion) es anterior a 01/01/2021 no se permite el valor 'XI' para Identificaciones NIF-IVA

1255 = Si FechaOperacion (FechaExpedicionFactura si no se informa FechaOperacion) es mayor o igual que 01/02/2021 no se permite el valor 'GB' para Identificaciones NIF-IVA

3000 = Registro de facturación duplicado.

3001 = El registro de facturación ya ha sido dado de baja.

3002 = No existe el registro de facturación.

3003 = El presentador no tiene los permisos necesarios para actualizar este registro de facturación.



********* Listado de códigos de error que producen la aceptación del registro de facturación en el sistema (posteriormente deben ser subsanados) ********* 

2000 = El cálculo de la huella suministrada es incorrecta.

2001 = El NIF del bloque Destinatarios no está identificado en el censo de la AEAT.

2002 = La longitud de huella del registro anterior no cumple con las especificaciones.

2003 = El contenido de la huella del registro anterior no cumple con las especificaciones.

2004 = El valor del campo FechaHoraHusoGenRegistro debe ser la fecha actual del sistema de la AEAT, admitiéndose un margen de error de 5 minutos.

2005 = El campo ImporteTotal tiene un valor incorrecto para el valor de los campos BaseImponibleOimporteNoSujeto, CuotaRepercutida y CuotaRecargoEquivalencia suministrados.

2006 = El campo CuotaTotal tiene un valor incorrecto para el valor de los campos CuotaRepercutida y CuotaRecargoEquivalencia suministrados.



********* Listado de códigos de error ajenos al servicio web (Formulario de facturación) ********* 

5000 = Parámetro obligatorio y contiene NULL.

5001 = El campo TipoFactura no tiene un valor correcto.

5002 = Se deben informar todos los datos de pago si se informa alguno de ellos.

5003 = La cuenta de pago debe estar rellena si se informa como forma de pago Transferencia o Recibo Domiciliado.

5004 = La cuenta de pago no debe estar rellena si no se informa como forma de pago Transferencia o Recibo Domiciliado.

5005 = Error al dar de alta la factura. Factura duplicada. 

5006 = Se deben informar todos los campos del bloque Datos FacturasRectificadas si se informa alguno de ellos.

5007 = Usuario no autorizado a realizar esta acción.

Verifactu facturas B2C

Buenos días compañeros.

Tengo un cacao muy grande en la cabeza con respecto a si tengo que enviar todos los tiques que haga nuestra máquina o no.
Nosotros hacemos balanzas de supermercado que son capaces de cobrarte, por lo tanto de emitir facturas simplificadas a particulares.

Tengo entendido que las facturas B2C no tienen la obligación de ser presentadas en formato electrónico a hacienda. Pero por otro lado en el reglamento de Verifactu pone que se aplica a todas las facturas, pero Verifactu no deja de ser un sistema de factura electrónica.... ¿entonces las facturas B2C sí están obligadas o no están obligadas a presentarse por sistema Verifactu? Porque también te dicen que hay un sistema No Verifactu..... He lanzado la consulta a hacienda pero unos te dicen que no, otros te dicen que sí.....

Muchas gracias

Entonces si envio una factura y me devuelve un error , por ejemplo con el NIF del cliente, ¿puedo editar la factura, guardarla y volver a enviar ?

Cita:

Empezado por Franche (Mensaje 557854)

Entonces si envio una factura y me devuelve un error , por ejemplo con el NIF del cliente, ¿puedo editar la factura, guardarla y volver a enviar ?

Si, pero has de volver a enviarla codificando alta por rechazo.

Se puede modificar una factura???

Cita:

Empezado por Franche (Mensaje 557854)

Entonces si envio una factura y me devuelve un error , por ejemplo con el NIF del cliente, ¿puedo editar la factura, guardarla y volver a enviar ?

Cita:

Empezado por bmfranky (Mensaje 557855)

Si, pero has de volver a enviarla codificando alta por rechazo.

bmfranky estás seguro?

Alguien piensa que NO se puede modificar una factura una vez salvada? Creia que era la base de la ley anti fraude pero a lo mejor me confundo.

Por aquí venia mi duda en un post anterior que quedó sin respuesta:

Cita:

Empezado por rci (Mensaje 557814)

Yo tengo una duda sobre el caso "incorrecta".
Entiendo que si al enviar hay algún error en la conexión, en los servidores de AEAT, ... con volver a intentar el envío ya se soluciona porque la factura ya está bien.
Pero en el caso que AEAT contesta y rechaza, es porque o tienes mal el XML o hay algún error no aceptable en la factura y debes corregirlo.
Bien pues aquí tengo la duda, en teoría, una factura no la puedes modificar no?
Si es un error del programa que ha generado mal el xml pues supongo que modificas el programa urgentemente para que genere bien el xml y lo vuelves a enviar.
Pero si lo que está mal son los datos de la factura?
Ya se, no tendría que permitir que un usuario guarde una factura con datos mal pero... y si pasa?
Creo que no puedo permitir al usuario modificar la factura para cambiar alguna información incorrecta... no?

O me estoy liando?

Muchas gracias!

MUCHAS GRACIAS !

Cita:

Empezado por rci (Mensaje 557857)

Cita:

ALTA POR RECHAZO
· Al ta por recha zo del regi s tro de fa ctura ci ón de a lta
i ni cia l (y que, por tanto, no exis te a ún en l a AEAT).

· Es l a s ubs a na ción de da tos de un regi s tro de
fa ctura ci ón de a l ta i ni ci a l, cua ndo no s e exi ge l a
emis i ón de una fa ctura rectifica tiva (u otro
meca ni s mo contempl a do en el Regl a mento de
Fa ctura ci ón).

· <Subs a na ci on>=S
· <Recha zoPrevi o>=X · VERI*FACTU

· La cla ve úni ca del regis tro de fa ctura ci ón no
debe exi s tir previa mente en la AEAT.

· El a lta previ a del regis tro de fa ctura ción fue
recha za da .

Alta del regis tro de fa ctura ci ón con los
nuevos da to

Interpreto que seria este caso.

Componente derivado de HTTRIO para facilitar los envíos a verifactu.

Os lo pongo , Por si le sirve a alguien como Idea o como ayuda.

El componente Requiere Delphi 12 , me baso en enviar XML preparados previamente almacenados con un certificado también almacenado en el software.

Bàsicamente le cargamos el certificado , el password un XML y lo enviamos.

Código:



unit VerifactuHTTPRIO;



interface



uses

  System.SysUtils,

  System.Classes,

  Soap.Rio,

  Dialogs,

  Xml.XMLDoc,

  Xml.XMLIntf,

  Soap.SOAPHTTPClient,

  Soap.SOAPHTTPTrans;







type



  TBeforeExecuteEvent = procedure(const MethodName: string; SOAPRequest: TStream) of object;

  TAfterExecuteEvent  = procedure(const MethodName: string; SOAPResponse: TStream) of object;



  TVerifactuHTTPRIO = class(THTTPRIO)





  private

    { Private declarations }

    FCertificate    : TMemoryStream;

    FCertPassword   : String;

    FXMLRequest     : TStringList;

    FXMLResponse    : TStringList;

    FOnAfterExecute : TAfterExecuteEvent;

    FOnBeforeExecute: TBeforeExecuteEvent;

    function StreamToString(aStream: TStream): string;

  protected

    { Protected declarations }

    procedure DoAfterExecute(const MethodName: string; Response: TStream); override;

    procedure DoBeforeExecute(const MethodName: string; Request: TStream); override;

  public

    { Public declarations }

    constructor Create(AOwner: TComponent); override;

    destructor Destroy; override;

  published

    { Published declarations }

    property OnAfterExecute: TAfterExecuteEvent read FOnAfterExecute write FOnAfterExecute;

    property OnBeforeExecute: TBeforeExecuteEvent read FOnBeforeExecute write FOnBeforeExecute;

    property Certificate   : TMemoryStream  read FCertificate write FCertificate;

    property CertPassword  : String  read FCertPassword write FCertPassword;

    property XMLRequest    : TStringList  read FXMLRequest write FXMLRequest;

    property XMLResponse   : TStringList  read FXMLResponse write FXMLResponse;



  end;



procedure Register;



implementation





constructor TVerifactuHTTPRIO.Create(AOwner: TComponent);

Begin

  Inherited Create(Aowner);



  FCertificate := TMemoryStream.Create;

  FXMLRequest  := TStringList.Create;

  FXMLResponse := TStringList.Create;



End;



destructor TVerifactuHTTPRIO.Destroy;

begin



  FCertificate.Free;

  FXMLRequest.Free;

  FXMLResponse.Free;



  inherited;

end;





procedure TVerifactuHTTPRIO.DoBeforeExecute(const MethodName: string; Request: TStream);

begin



  // Si hay XMLRequest la enviamos

  if FXMLRequest.Count > 0 then

  Begin

     Request.Position := 0; // Importante

     FXMLRequest.SaveToStream(Request);

  End;





  // Cetificado

  HTTPWebNode.ClientCertificate.Stream   := Certificate;

  HTTPWebNode.ClientCertificate.Password := CertPassword;





  if Assigned(FOnBeforeExecute) then

  begin

    FOnBeforeExecute(MethodName, Request);

    Request.Position := 0;

  end;



end;



procedure TVerifactuHTTPRIO.DoAfterExecute(const MethodName: string; Response: TStream);

var RespuestaXML : String;

begin



  // Asignamos la respuesta y Maquillamos XML

  RespuestaXML := StreamToString(Response);



  RespuestaXML := Xml.XMLDoc.FormatXMLData(RespuestaXML);



  FXMLResponse.Text := RespuestaXML;





  if Assigned(FOnAfterExecute) then

  begin

    FOnAfterExecute(MethodName, Response);

    Response.Position := 0;

  end;



end;





function TVerifactuHTTPRIO.StreamToString(aStream: TStream): string;

var

  SS: TStringStream;

begin

  if aStream <> nil then

  begin

    SS := TStringStream.Create('');

    try

      SS.CopyFrom(aStream, 0);

      Result := SS.DataString;

    finally

      SS.Free;

    end;

  end else

  begin

    Result := '';

  end;

end;





procedure Register;

begin

  RegisterComponents('Componentes Verifactu', [TVerifactuHTTPRIO]);

end;



end.

Como Usar:

Código:



procedure TFormSoap.Button2Click(Sender: TObject);

var direccion_envio : String;

begin





direccion_envio := 'https://prewww1.aeat.es/wlpl/TIKE-CONT/ws/SistemaFacturacion/VerifactuSOAP';



// Cargar el certificado

VerifactuRIO.Certificate.LoadFromFile('MiCertificado.pfx');

VerifactuRIO.CertPassword := '1234';





// Cargar el XMl  enviar , de fichero o de texto

VerifactuRIO.XMLRequest.LoadFromFile('XML_Envio_Verifactu.xml');



// Llamada

GetsfPortTypeVerifactu(False, direccion_envio, VerifactuRIO).RegFactuSistemaFacturacion(nil);



// Aquí tenemnos la respues

VerifactuRIO.XMLResponse.Text;



end;

Un Saludo

Cita:

Empezado por Delphier (Mensaje 557859)

Os lo pongo , Por si le sirve a alguien como Idea o como ayuda.
El componente Requiere Delphi 12 , me baso en enviar XML preparados previamente almacenados con un certificado también almacenado en el software.
Bàsicamente le cargamos el certificado , el password un XML y lo enviamos.

Gracias por compartirlo.
Lo subo al FTP y actualizo el mensaje#2 con códigos y demás....

Cita:

Empezado por cdlrubia (Mensaje 557852)

Tengo un cacao muy grande en la cabeza con respecto a si tengo que enviar todos los tiques que haga nuestra máquina o no.

La respuesta es sí.

Cita:

Nosotros hacemos balanzas de supermercado que son capaces de cobrarte, por lo tanto de emitir facturas simplificadas a particulares.

Tengo entendido que las facturas B2C no tienen la obligación de ser presentadas en formato electrónico a hacienda. Pero por otro lado en el reglamento de Verifactu pone que se aplica a todas las facturas, pero Verifactu no deja de ser un sistema de factura electrónica.... ¿entonces las facturas B2C sí están obligadas o no están obligadas a presentarse por sistema Verifactu? Porque también te dicen que hay un sistema No Verifactu..... He lanzado la consulta a hacienda pero unos te dicen que no, otros te dicen que sí.....

Consulta el mensaje #557126 dónde he contestado a una pregunta muy similar por la confusión que hay en este tema en general. Creo que te va a ayudar mucho a aclararte.

Buenas a todos,

Tengo una duda muy básica...

Voy a intentar la semana que viene hacer mi primera subida a pruebas y no tengo claro si en el xml la parte inicial que hace referencia al sopaenv es indiferente de si el fichero va al servidor de pruebas o al real. Esta parte concretamente:

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:sum="https://www2.agenciatributaria.gob.es/static_files/common/internet/dep/aplicaciones/es/aeat/tike/cont/ws/SuministroLR.xsd" xmlns:sum1="https://www2.agenciatributaria.gob.es/static_files/common/internet/dep/aplicaciones/es/aeat/tike/cont/ws/SuministroInformacion.xsd">
<soapenv:Header/>
<soapenv:Body>

Tengo que sustituir ahí los www2.agenciatributaria.gob.es por prewww2.aeat.es dentro del xml según vaya a un lado u otro o el xml siempre es igual

Gracias

Cita:

Empezado por edari (Mensaje 557863)

Tengo una duda muy básica... Voy a intentar la semana que viene hacer mi primera subida a pruebas y no tengo claro si en el xml la parte inicial que hace referencia al sopaenv es indiferente de si el fichero va al servidor de pruebas o al real. Esta parte concretamente:

Código:

<soapenv:Envelope

xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"

xmlns:sum="https://www2.agenciatributaria.gob.es/static_files/common/internet/dep/aplicaciones/es/aeat/tike/cont/ws/SuministroLR.xsd"

xmlns:sum1="https://www2.agenciatributaria.gob.es/static_files/common/internet/dep/aplicaciones/es/aeat/tike/cont/ws/SuministroInformacion.xsd">

Tengo que sustituir ahí los www2.agenciatributaria.gob.es por prewww2.aeat.es dentro del xml según vaya a un lado u otro o el xml siempre es igual

No, debes usar las URLs de producción aunque estas enviando al servidor de pruebas.
Y la verdad es un alivio que siga así.

La contrapartida vendrá más tarde: dado que no hay control de versión en las URL actuales, cuando Hacienda querrá hacer una nueva versión, deberán crear nuevas URL (posiblemente con un indicador de versión) y habilitarlas primero en entorno de test y más tarde en producción. Pero no estamos todavía allá. :rolleyes:

Cita:

Empezado por antoine0 (Mensaje 557865)

Aclarado lo del fichero.

Y en el comando que use para subir el xml ahí sí tengo que poner, hoy por hoy, las https://prewww...no?

Gracias antoine0,

Buenos días¡¡

Primero agradeceros a todos el gran esfuerzo.

a alguien más le esta pasando esto ?

Código:

Error al realizar el envío; (ESOAPHTTPException)-Service Unavailable (503) - 'https://prewww1.aeat.es/wlpl/TIKE-CONT/ws/SistemaFacturacion/VerifactuSOAP'

se ha caído el servidor de pruebas o solo funciona en horario laboral ? :)

:(

Cita:

Empezado por Matorral (Mensaje 557875)

Buenos días¡¡

Primero agradeceros a todos el gran esfuerzo.

a alguien más le esta pasando esto ?

Código:

Error al realizar el envío; (ESOAPHTTPException)-Service Unavailable (503) - 'https://prewww1.aeat.es/wlpl/TIKE-CONT/ws/SistemaFacturacion/VerifactuSOAP'

se ha caído el servidor de pruebas o solo funciona en horario laboral ? :)

:(

A mí tampoco me funciona.

Cita:

Empezado por Matorral (Mensaje 557875)

Buenos días¡¡

Primero agradeceros a todos el gran esfuerzo.

a alguien más le esta pasando esto ?

Código:

Error al realizar el envío; (ESOAPHTTPException)-Service Unavailable (503) - 'https://prewww1.aeat.es/wlpl/TIKE-CONT/ws/SistemaFacturacion/VerifactuSOAP'

se ha caído el servidor de pruebas o solo funciona en horario laboral ? :)

:(

lo acabo de probar y efectivamente esta OUT :D

Buenos días, aún me queda para llegar a la parte de los envíos, pero hay una cosa que me preocupa y pido que alguien por favor haga la prueba (cuando rehabiliten el servicio)
1-Emitir/enviar 1 factura simplificada
2-Emitir/enviar una factura sustitutiva/canje de la simplificada
3-Anular/enviar la sustitutiva
4-Emitir/enviar nueva sustitutiva/canje sobre la primera factura simplificada(que se supone se ha liberado)
5-¿Da ok o da ko(error)?
6-por otro lado(debería devolver error si se intenta mandar una sustitutiva que apunte a alguna simplificada que ya se ha emitido sustitutiva y no ha sido anulada(es así?)
Gracias

Dudas con algunos campos del XML

Hay algunos campos opcionales en el XML de "Registro Facturación Alta" que me gustaría corroborar por si me estoy equivocando...

- "FacturaSimplificadaArt7273": Entiendo que cuando se trate de facturas simplificadas siempre hay que poner (S)? No era más sencillo simplemente en TipoFactura poner F2 y punto? O es que el campo "FacturaSimplificadaArt7273" es para otra cosa?
- "FacturaSinIdentifDestinatarioArt61d": Cuando no tengamos los datos del destinatario, Y no sea una simplificada (las simplificadas no requieren destinatario), hay que poner (S) aquí?

Es que llamar a estos dos campos con el nombre del artículo (Art7273 y Art61d) me mosquea...

Otros campos raros son:
- "Macrodato"
- "NumRegistroAcuerdoFacturacion": ni p___ idea
- "IdAcuerdoSistemaInformatico": ni idea tampoco

El último campo, "Signature", entiendo que es la firma del XML pero solo para cuando se trate de No-Verifactu. Del No-Verifactu aún no me he preocupado porque considero esto más importante, por ahora.

Cita:

Empezado por espinete (Mensaje 557900)

- "FacturaSimplificadaArt7273": Entiendo que cuando se trate de facturas simplificadas siempre hay que poner (S)? No era más sencillo simplemente en TipoFactura poner F2 y punto? O es que el campo "FacturaSimplificadaArt7273" es para otra cosa?

Las facturas artículos 7.2 y 7.3 son facturas simplificadas (antiguos tickets) que llevan nombre, NIF y domicilio del destinatario. No es el caso habitual (dónde las facturas simplificadas son anónimas).

Cita:

Empezado por espinete (Mensaje 557900)

FacturaSimplificadaArt7273", este campo es opcional y si lo pones a SÍ indica que la factura es completa (F1) pero no se identifica al destinatario, por ejemplo en ventas a la Unión Europea a un cliente final no empresario o profesional.

FacturaSinIdentifDestinatarioArt61d, este campo es opcional, si lo pones a SÍ, significa que vas a emitir una Factura Simplificada con Identificación de Destinatario por que así te lo ha exigido éste.

Macrodato si el importe de la factura excede del valor absoluto de 100.000.000,00 debes poner SÍ, básicamente controla que no te has equivocado con ese importe que has informado

NumRegistroAcuerdoFacturacion cuando existe, tienen que ver con la posibilidad de emisión de facturas simplificadas por importes superiores a 3000€

IdAcuerdoSistemaInformatico tiene que ver con un software homologado por la administración tributaria para realizar una tarea específica