Ley antifraude 2021 (VERIFACTU) - Programas informáticos

[jguarda]

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

[pablog2k]

Empezado por jguarda

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

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

[Sistel]

Empezado por pablog2k

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

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.

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

Empezado por jguarda

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.

Empezado por pablog2k

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.

[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,....

[David M]

Buenas,

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

Saludos,
David M.

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

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

[seccion_31]

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:

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.

[bmfranky]

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. 


[cdlrubia]

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

[Franche]

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 ?

[bmfranky]

Empezado por Franche

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.