España: Normativa sancionadora sistemas informáticos

[quim]

Víctor,

Hasta donde sé, los SIF, Sistemas Informáticos de Facturación, tienen la obligación de funcionar como Sí Verifactu y como No Verifactu, independientemente que el cliente sólo quiera Sí Verifactu


Salu2

Efectivamente, un sistema de facturación puede ser NO Veri*factu y el cliente puede optar por no acogerse también, en ese caso tu sistema deberà de cumplir con la inalterabilidad, trazabilidad, eventos, etc y además estar preparado para Veri*factu por si en algun momento el cliente u otro cliente SI desea acogerse, también estar preparado en caso de inspección (requerimiento de registros de facturación en formato Veri*factu)

Pero para nada hay la obligación de NO Veri*Factu. Un SIF si es Veri*factu, con ello basta

En mi caso, no voy a implementar los requisitos espartanos a que nos obligan para los No Veri*factu y trataré de convencer a mis clientes para que lo adopten
Si por el camino pierdo alguno por no querer acogerse, el coste seguramente será menor que cumplir los requisitos imposibles de los NO Veri*factu
Además, si tu software contempla la posibilidad de no enviar los registros a la AEAT, ya estás dando una pista de que por 'algo' no quieres dar esa información y algo ocultas
El software tiene que ser transparente y no colaborar con el fraude fiscal, es mi humilde opinión

[paquitohm]

Hola Quim,

Gracias por tu respuesta.

No sé si existe oficialemente el sustantivo "No Verifactu", pero el concepto creo que sí existe.
Me explico: Si el usuario no elige el sistema Si Verifactu, entonces, CREO, que hay una serie de obligaciones, que podríamos llamar sistema "No Verifactu" y una de ellas sería por ejemplo el registro de eventos, que no es obligatorio, hasta donde yo sé si el usuario optó por "Si Verifactu"

Menudo galimatías me ha salido de si y no verifactu. jajajajajajajajajajajaja
La parte contratante de la primera parte será considerada como la parte contratante de la primera parte


[Editado] PD. En todo caso, como dije anteriormente, para (auto) certificar el SIF, hasta donde yo sé, se exige que el programa tenga la posibilidad de funcionar como Si Verifactu y como No Verifactu, indistintamente de la opción del usuario

[quim]

[Editado] PD. En todo caso, como dije anteriormente, para (auto) certificar el SIF, hasta donde yo sé, se exige que el programa tenga la posibilidad de funcionar como Si Verifactu y como No Verifactu, indistintamente de la opción del usuario

Ahí discrepo. Con que el SIF se certifique como Veri*Factu es suficiente
Saludos

[paquitohm]

quim,

Es cierto. Perdón por el error
La "cosa" es así y espero no equivocarme otra vez, el SIF puede ser:

·Si Verifactu
·Si Verifactu + No Verifacu

Pero lo que no puede ser únicamente es No Verifactu

Así que una opción es meter a todos los clientes por el ramal "Sí Verifactu"

[VictorCasajuana]

Opino como quim, Puedes tener un sistema Veri*Factu y te ahorras el cumplimiento de todas las obligaciones ( casi imposible ) que te indican. En cambio si optas por No Verifactu, te estás metiendo en un pantanal complicado, hacienda ya te tendrá en el punto de mira, y cumplir con todo lo que piden es algo casi inalcanzable técnicamente, a parte que deberás incorporar igualmente todas las comunicaciones para cumplir con Veri*Factu, eso sí que es un requerimiento a cumplir.
Yo optaré por la solución Veri*Factu ya que si optas por esta opción, no es obligado tener la modalidad No Veri*Factu, y si algún cliente no quiere tener Veri*Factu obligatoriamente, como dice quim, pierdo el cliente y a nivel económico, tiempo y riesgo a asumir salgo ganando por todos los frentes.
Hacienda ha indicado que si como desarrollador optas por el modo Veri*Factu y un cliente que tiene tu software no se quiere actualizar, estás exento de cualquier responsabilidad al respecto, algo a tener muy en cuenta.
Salud!

[FiveWiDi]

Hola a todos,

3 dudas.

1-Seguimos en este hilo? o abrimos uno específico para VERIFACTU? (En Off-Topic seria lo correcto)

2-Curiosidad. Mirando un fichero que tengo nombrado como "Anexo_OM_RD-1007-2023(v0.5.0_2023-12-20).xlsx", que son especificaciones del XML, veo algo curioso. Se 'podrían' enviar 1000 registros con el tag 'RegistroAltaFacturas' y en cada uno de éstos otros 1000 con el tag 'IDFacturaRectificada'. Quizás alguna gran empresa eléctrica o de telefonía puede en su día rectificar o substituir facturas (sólo serían 1.000.000 de facturas como máximo).

3-Veo que una factura puede emitirse por el propio DESTINATARIO (en las especificaciones del XML parece contemplarse esta circunstancia).
De hecho ayer me comentaban un caso de una aseguradora que emite las facturas de sus proveedores en las cuales ella es la destinataria; son trabajos baremados y así facilitan el papeleo a las pequeñas empresas que les dan servicio (ahora entiendo que exija que sean empresas y no autónomos, pero eso es otro tema).
Entonces, si esa pequeña empresa realiza además trabajos para otras empresas o a particulares, ¿Cómo se trataría el tema del encadenamiento? ¿Quién ha de enviar el registro por VERIFACTU? Por qué está claro que la pequeña empresa pierde el control de la emisión de sus facturas, al menos las destinadas a la aseguradora. ¿Podría solucionarse usando una número de serie para cada origen/emisor de la factura?

[paquitohm]

Hola Carlos,

1. Yo seguiría. Estos foros están llenos de OT que lo que hacen es animar el foro
2. Ok !
3. Esta pregunta-respuesta oficial quizás responda tu inquietud:
Pregunta: En el diseño del registro de alta, en el nodo SistemaInformatico, aparece un campo que es el
NumeroInstalacion. ¿a qué se refiere?
Respuesta: El campo <NumeroInstalacion> es un nº propio de cada instancia/instalación concreta (o SIF) de un producto de
facturación particular. Este campo sirve para diferenciar diferentes instancias/instalaciones de SIF de un mismo obligado
tributario que emplea productos "iguales" en todos ellos (por ejemplo, distintos PC que tienen instalado una mismo
programa y versión para facturar, para así poder distinguir cuál de ellos ha expedido cada factura y generado su
correspondiente registro de facturación) .

[FiveWiDi]

Hola Carlos,
3. Esta pregunta-respuesta oficial quizás responda tu inquietud:
Pregunta: En el diseño del registro de alta, en el nodo SistemaInformatico, aparece un campo que es el
NumeroInstalacion. ¿a qué se refiere?
Respuesta: El campo <NumeroInstalacion> es un nº propio de cada instancia/instalación concreta (o SIF) de un producto de
facturación particular. Este campo sirve para diferenciar diferentes instancias/instalaciones de SIF de un mismo obligado
tributario que emplea productos "iguales" en todos ellos (por ejemplo, distintos PC que tienen instalado una mismo
programa y versión para facturar, para así poder distinguir cuál de ellos ha expedido cada factura y generado su
correspondiente registro de facturación) .

Si, si. Esto lo tengo claro. Es el caso de una empresa que tiene 2 o más ordenadores y factura desde cualquiera de ellos.

Es que es muy raro lo que me explicaron de que la empresa para la que trabajan les expide SUS facturas cuyo destinatario es la empresa para la que trabajan.

Y en la definición del XML veo que hay un 'tercero' que ha expedido la factura.
Tag 'EmitidaPorTercerosODestinatario' con la explicación 'Identificador que especifica si la factura ha sido emitida por un tercero o por el destinatario (contraparte).

Y posiblemente yo tendré este caso encima de la mesa en su momento.

[paquitohm]

Es que es muy raro lo que me explicaron de que la empresa para la que trabajan les expide SUS facturas cuyo destinatario es la empresa para la que trabajan.

Ese sistema lo conozco yo a través de la agricultura y la ganadería: Como algunos pequeños agricultores o ganaderos no tienen sistemas administrativos que les permitan expedir facturar es la propia empresa que compra sus producciones la que se hace una autofactura

[VictorCasajuana]

Hola a todos,

3 dudas.

1-Seguimos en este hilo? o abrimos uno específico para VERIFACTU? (En Off-Topic seria lo correcto)

2-Curiosidad. Mirando un fichero que tengo nombrado como "Anexo_OM_RD-1007-2023(v0.5.0_2023-12-20).xlsx", que son especificaciones del XML, veo algo curioso. Se 'podrían' enviar 1000 registros con el tag 'RegistroAltaFacturas' y en cada uno de éstos otros 1000 con el tag 'IDFacturaRectificada'. Quizás alguna gran empresa eléctrica o de telefonía puede en su día rectificar o substituir facturas (sólo serían 1.000.000 de facturas como máximo).

3-Veo que una factura puede emitirse por el propio DESTINATARIO (en las especificaciones del XML parece contemplarse esta circunstancia).
De hecho ayer me comentaban un caso de una aseguradora que emite las facturas de sus proveedores en las cuales ella es la destinataria; son trabajos baremados y así facilitan el papeleo a las pequeñas empresas que les dan servicio (ahora entiendo que exija que sean empresas y no autónomos, pero eso es otro tema).
Entonces, si esa pequeña empresa realiza además trabajos para otras empresas o a particulares, ¿Cómo se trataría el tema del encadenamiento? ¿Quién ha de enviar el registro por VERIFACTU? Por qué está claro que la pequeña empresa pierde el control de la emisión de sus facturas, al menos las destinadas a la aseguradora. ¿Podría solucionarse usando una número de serie para cada origen/emisor de la factura?

1. estaría bien
2. ok
3. Mi opinión al respecto, es que esos pequeños negocios que ahora delegan la creación de la factura a su proveedor ( lo he visto en agricultura ) tendrán que hacerla ellos, o con un SIF propio o utilizando la aplicación que habilitará hacienda. Técnicamente no pueden hacerlas los proveedores ya que se perderá el encadenamiento aunque hagas series independientes, ya que el encadenamiento es independiente de la serie, a parte de que el proveedor ha de tener los certificados de todos sus clientes para hacer las facturas en su nombre.

[paquitohm]

Autofactura, aclaración oficial

Pregunta: Como se van a tratar las autofacturas que hacen algunas empresas. Ya que emiten en nombre de
cliente. Presentará el que emite la autofactura?

Respuesta: Se entiende que se refiere a cuando es el propio destinatario de la factura quien expide materialmente la factura que su proveedor está obligado a expedirle. Esto está permitido por el reglamento de facturación y por el reglamento del RD
1007/2023, siempre y cuando el proveedor le haya otorgado al destinatario las facultades pertinentes para ello. En ese
caso, quien firmaría o remitiría a la AEAT el registro de facturación de la factura (de su proveedor a él) sería el
destinatario, con su propio certificado (del destinatario). Se recuerda quen en el caso de remisión, además se requiere
apoderamiento para dicho trámite o ser colaborador social con el adecuado convenio suscrito.

[VictorCasajuana]

Autofactura, aclaración oficial

Pregunta: Como se van a tratar las autofacturas que hacen algunas empresas. Ya que emiten en nombre de
cliente. Presentará el que emite la autofactura?

Respuesta: Se entiende que se refiere a cuando es el propio destinatario de la factura quien expide materialmente la factura que su proveedor está obligado a expedirle. Esto está permitido por el reglamento de facturación y por el reglamento del RD
1007/2023, siempre y cuando el proveedor le haya otorgado al destinatario las facultades pertinentes para ello. En ese
caso, quien firmaría o remitiría a la AEAT el registro de facturación de la factura (de su proveedor a él) sería el
destinatario, con su propio certificado (del destinatario). Se recuerda quen en el caso de remisión, además se requiere
apoderamiento para dicho trámite o ser colaborador social con el adecuado convenio suscrito.

pues aún más sencillo! así ya es una gestión que se deriva al cliente final (nuestro cliente que utiliza el SIF) para que haga los apoderamientos pertinentes.

[paquitohm]

Hola,

¿ Alguien tiene implementada el hash 256 de la huella en harbour ?

El ejemplo que ponen es en Java y es este, extraido de una imagen:

Code: Select all  Expand view

import java.security.MessageDigest;
import org.apache.commons.codec.binary.Basel6;

public class Huella {

public static String getHashVerifactu(String msg)throws Exception {
MessageDigest digest = MessageDigest.getlnstance("SHA-256");
return new Basel6(f&lse) .encodeAsString(digest.digest{msg.getBytes(StandardCharsets UTF_8)));

public static String getReferenciaRegistro(String idEmisorFactura, String numFacturaSerie, String fechaExpedicion,
String tipoFactura, String cuotaTotal, String importeTotal, String huellaAnterior,
String fechaUsoHorarioRegistro) {
StringBuilder sb = new StringBuilder();
sb.append("IDE:misorFactura=") .append(idEmisorFactura) .append("&")
.append("NumSerieFactura="l .append(numFacturaSerie) .append("&")
.append("FechaExpedicionFactura="l .append(fechaExpedicion) .append("&")
.append("TipoFactura="l . append(tipoFactura) .append("& ")
. append ( "CuotaTotal=") . append (cuotaTotal) . append ( " & ")
.append("ImporteTotal=") . append{llnporteTotal) . append("&")
. append ("Huella=") . append {huellaAnterior) . append ( " & ")
. append (" FechaHoraHusoGenRegistro=") . append (fechaUsoHorarioRegistro) ;
return sb.toString();
public static String calcularHuella{String idEmisorFactura, String numFacturaSerie, String fechaExpedicion,
String tipoFactura, String cuotaTotal, String importeTotal, String huellaAnterior,
String fechaRegistro, String horaRegistro, String usoHorarioRegistro)throws Exception
String ref = getReferenciaRegistro(idEmisorFactura, numFacturaSerie, fechaExpedicion, tipoFactura, cuotaTotal,
importeTotal, huellaAnterior, fechaRegistro);
return getHashVerifactu(ref);
public static void main(String args(])throws Exception {
Huella h = new Huella();
System. out.println (calcularHuella ("89890001K", "12345678/G33", "01-01-2024", "Fl", "12. 35", "123. 45",
"123456789012345678901234567890123456789012345678901234567890abcd", "2024-01-01Tl2:00:00+0l:OO"));
}
}
 

[quim]

Hola,
¿ Alguien tiene implementada el hash 256 de la huella en harbour ?
 [/code]

Paquito, en harbour es muy fácil (como en casi todo) ...

Code: Select all  Expand view

//-----------------------------------------------------------------------------//
// Especificaciones de huella o hash
//-----------------------------------------------------------------------------//
// Algoritmo: SHA-256
// Codificación: UTF-8
// Formato de salida será:
//    - En sistema hexadecimal.
//    - En mayúsculas.
// Se validará la huella o hash en el servicio de remisión de registros de facturación.
// En caso de error, se marcará como “Aceptada con errores” y se deberá proceder a su revisión.
//-----------------------------------------------------------------------------//
function hb_Huella()

   local c := ""
   local h := {=>}

   h['Nif']                      := "B1234567"
   h['NumSerieFacturaEmisor']    := "AB-123456"
   h['FechaExpedicionFactura']   := hb_dtoc( date(), "dd-mm-yyyy" )
   h['TipoRegistroSIF']          := "01"
   h['TipoFactura']              := "F1"
   h['CuotaTotal']               := ltrim( str(261.61, 12, 2) )
   h['ImporteTotal']             := ltrim( str(1507.36, 12, 2) )
   h['HuellaRegistroAnterior']   := "ZmY2MDgxMzc2ZWIyMTI4ZDFiMDMyMDlkMTAyNmQ4ZDVmZGExMWJkYWRiMThjZTNkYjE4ODExZDg3MDUwZTNjMQ=="
   h['FechaHoraHusoGenRegistro'] := hb_TtoS( hb_datetime() )

   hb_heval( h, {|k,v,i| c += v} ) // | key, value, index |

return hb_base64Encode( hb_sha256(c) )
 

[paquitohm]

Gracias quim por el aporte del que todos nos beneficiaremos

Es fácil cuando se sabe hacer, claro está

Pero lo que sí me parece que resulta evidente es que el código es mucho más fácil que el código de JAVA