Anular una factura no es un proceso que se pueda hacer con tanta ligereza. Debe haber un motivo de peso para hacerlo y nunca utilizar esta opción para corregir fallos en una factura inicial y luego volverla a generar, sobre todo, porque el 99% de estos errores los corrige la Rectificativa que para eso se ha creado. Técnicamente yo creo que sí se podría anular la sustitutiva pero tendrías que dar explicaciones de por qué no anulaste la simplificada en su momento.

Gracias a los dos ^\||/

Solo anulan cuando lo acaban de emitir y no se ha entregado al cliente, por que se Dan cuenta inmediatamente de un error al seleccionar el cliente.
Deberían ser más abiertos para anular una sustitutiva ya que el ticket es el que marca el pago del iva mientras no anules el ticket.

Solo anulan cuando lo acaban de emitir y no se ha entregado al cliente, por que se Dan cuenta inmediatamente de un error al seleccionar el cliente.
Deberían ser más abiertos para anular una sustitutiva ya que el ticket es el que marca el pago del iva mientras no anules el ticket, personalmente, no creo que sancionen por anular una sustitutiva errónea.

En el caso de anulacion de sustitutiva está claro que no hay alguna intención fraudulenta, otra cosa es que no se cumpla un punto específico del reglamento, bajo mi punto de vista, con ese pequeño defecto de no permitirlo.

subsanacion y rechazoprevio
 

En la version que colgaron antes de ayer aparece una nueva opcion en el rechazo previo "X"
y hay nuevas anotaciones en la lista en L17.

Siempre que haya un rechazo tiene que haber una subsanacion.
Tambien si hay que enviar registros que no fueron enviados hay que marcar Subsanacion como "S" por lo tanto las posibles Combinaciones en nodos de Subsanacion y Rechazo previo son:


Reenvio registro por Rechazo
<Subsanacion>S</Subsanacion>
<RechaPrevio>S</RechaPrevio>

Envio o Reenvio por no existir en hacienda
por algun problema en el envio
<Subsanacion>S</Subsanacion>
<RechaPrevio>X</RechaPrevio>

Y este otro que no se cuando hay que usarlo (ya que si has subido un registro, y ha sido admitido, se deberian usar los cauces de rectificativas marcados por el reglamento, por que si no no tendria sentido el nodo Subsanacion ¿o metemos hay todas las correcciones? :D :

<Subsanacion>S</Subsanacion>
<RechaPrevio>N</RechaPrevio>


Por otro lado es marear la perdiz, cuando podian haberlo puesto en un solo nodo las 3 combinaciones, por ejemplo "S","X","O", es ganas de que arriesguemos y nos equivoquemos en la combinación para el reenvio. Vaya tela

Total que para regenrar un registro voy a poner 3 opciones, para resumir, que es lo que NO han hecho ellos y supongo corregiran:
SS Primer Caso
SX Segundo Caso
SN Tercer Caso

Supongo que el encadenamiento de los registros de subsanacion seguiran la misma regla qu el resto, encadenar contra el ultimo generado.

Hola,

Quería saber como utiliza vd. la rectificativa: ¿ La utiliza como sustitutiva o siempre como fra. de abono ? Lo digo porque una sustitutiva "genera" un registro, el original, que no debe ser contemplado en los listados "oficiales" del programa, que son casi todos, salvo, claro está, aquellos listados donde se quiera consultar las facturas origen de una sustitutiva

Slds

Hola, lo siento pero no entiendo la pregunta. Si pudiera ser más explícito podría darle mi opinión

Hola, soy nuevo en el grupo, y me gustaría saber donde veis las versiones que van subiendo desde la Agencia Tributaria.

En la primera página el moderador ha puesto todos los enlaces a documentación, direcciones, ejemplos, etc...
https://www.agenciatributaria.es/AEA...ERI_FACTU.html

saludos

Te voy a adjuntar una pregunta / Respuesta a Verifactu por si te puede ayudar en tu decisión de anular Facturas

Pregunta :

Buenas tardes.

Quisiera plantear una situación que ocurre a la hora de anular una factura emitida por error en el día a día, o sea, errores de los que nos percatamos inmediatamente y que solventamos sobre la marcha. Vaya por delante, que la factura a anular no entra dentro de los supuestos de rectificación ya que es una operación donde se ha errado con el cliente destinatario, y además, no ha llegado todavía la fecha de devengo del impuesto, con lo que la única opción que me queda es la emitir una factura de abono con todos los conceptos en negativo y volver a emitir una nueva factura ordinaria por los conceptos de la factura anulada al cliente correcto.

¿ Cómo debo proceder en mi ERP si simplemente ANULO la factura ?

RESPUESTA de la AEAT

Buenos días:

Posiblemente en sede electrónica de la AEAT o en la propia Orden Ministerial pueda aclararse cómo corregir todo tipo de errores que puedan producirse en la emisión de una factura.
Respondiendo, en concreto a esta consulta, hay dos opciones

Opción 1: 3 registros de facturación, el primero perteneciente a la factura emitida por error, el segundo a la factura de abono en negativo que "anula" la factura errónea, y el tercero, correspondiente con la factura final

Opción 2: 3 registros de facturación, el primero perteneciente a la factura emitida por error, el segundo perteneciente al registro de anulación de ésta, y el tercero, correspondiente con la factura final

El uso de uno u otro método que se menciona en la consulta depende del tratamiento "integral (o posterior)" que haga el sistema informático de facturación con la factura a anular. Por ejemplo, si se contabilizase "inmediatamente" la factura emitida por error, la deberá rectificar con otra factura "opuesta" cuya contabilización "repararía" el asiento contable de la factura errónea y luego hacer la factura con los datos correctos (opción 1). Sin embargo, si el sistema "espera" un cierto tiempo antes de contabilizar la factura errónea, entonces se puede anular en ese lapso de tiempo y todo queda "arreglado" a nivel de facturación, haciendo luego la factura con los datos correctos (opción 2).

Atentamente,
AEAT.

Esta e la conclusión a lo que yo llego después de recibir la respuesta
Si anulo una factura mediante un registro de anulación, queda constatado el cambio que he hecho y por lo tanto, cumplo con el punto del reglamento 201 bis donde dice ".... alteraciones de las que no quede la debida anotación en los sistemas mismos... ". La respuesta que da, deja entrever que puedo alterar mi registro del SIF, no mi registro de facturación, para desligarle los albaranes que lo componía o poner a cero las líneas de la factura, si fuera el caso, y entonces quedaría mi factura a cero en el ERP. Como en las tablas redundantes existe la factura tal cual estaba originalmente, se podría consultar su contenido original sin problemas y seguiría diciendo lo mismo que lo que decía su registro de facturación.

Por otro lado, ten en cuenta que han creado un registro de subsanación. Esta herramienta te permite cambiar algún dato interno del registro de facturación original creando un nuevo registro de subsanación que enmenda el enviado anteriormente, siempre y cuando dicha subsanación no debiera haberse resuelto con una Rectificativa. Si te has equivocado en la fecha de operación o el tipo de Régimen tributario no procede enviar una rectificativa, debes enviar una subsanación. Siguiendo con el planteamiento, modificarías estos datos en tu registro del SIF y generarías el registro de subsanación para enmendar el anterior. ¿ No vas a crear otra factura nueva por este motivo, no ?.

Todo esto se resume en que, puedes cambiar datos de tu registro SIF anterior para que ahora diga lo que debe decir, y sus cambios quedan registrados con los diferentes registros de subsanación que debes enviar a la aeat.

Todo esto es un pensamiento propio, que desde luego, no lo planteo como "lo que debemos hacer", pero aquí lo dejo para su discusión

Aquí veo varios escenarios. Si el sif es verifactu con envío inmediato, prácticamente da igual lo que se quede en tu sistema. Y si no lo es lo que tienes que conservar son los xmls, lo que tengas en tus BD para mejor control es otro tema.
Ya dirán en el desarrollo reglamentario en que momento usamos rectificativas o la subsanación, de momento es mejor trabajar sobre las rectificativas por sustitución para el.maximo de casos que puedas reparar para seguir la trazabilidad que proponen con el reglamento. La subsanarlos es u poco como el Goto de Basic y puede darte problemas de que no les quede claro. Ya que si emites una subsanación por algo contemplado en el reglamento, como lo.que dices, corregir fecha, o datos cliente, al final estás haciendo el equivalente a anular la factura y volverla a emitir. Y como la anulación se hace siempre que no se haya registrado o emitido la factura, no sería fiable para ellos, ya que se pueden encontrar con una factura que la empresa receptora la declare como iva soportado y ya la hemos liado.
Contrila el uso de anulaciones y subsanaciones o por ahí vas a tener un problema

"Aclaraciones" de la AEAT por si el sirve a alguien
 

Respuesta de la AEAT

Buenos días:
Los desarrolladores de SIF tienen libertad para ofrecer sus productos de acuerdo a cualquiera de las opciones que se contemplan en el Reglamento, pudiendo ser:

- SOLO VERI*FACTU
- VERI*FACTU Y NO VERI*FACTU (funcionamiento a elegir por el obligado tributario usuario del SIF).
- ÚNICAMENTE NO VERI*FACTU.

Esta última opción de que solamente permitan el funcionamiento como NO VERI*FACTU, aunque está permitida y por lo tanto es posible, no parece tener mucho sentido porque en cualquier caso es obligatorio que todos los SIF tengan desarrolladas las capacidades necesarias para remitir registros de facturación a la AEAT, aunque no las lleven a efecto, y por ello quizás no se entendería que, si ya existen, no se ofreciera la posibilidad de utilizarlas, si no ahora, sí en el futuro.

Por otro lado, la primera opción de SOLO VERI*FACTU, desde el punto de vista del productor de SIF, presenta ciertas ventajas al no estar obligados a cumplir varios requisitos adicionales exigidos a los NO VERI*FACTU, como —entre otros— los siguientes: no están obligados a firmar los registros de facturación, ni a tener un registro de eventos; tampoco se les obliga a conservar, exportar ni dar acceso a los registros de facturación remitidos, etc


Atentamente,
Atención al Usuario
Departamento de Informática Tributaria
Email: [email protected]

A ver que creo que te has liado.
La anulación de una factura siempre es sobre una factura que ha sido emitida, generado el registro de facturación y enviado a la aeat. La pregunta que intentábamos esclarecer es, ¿ Una factura que se anula en el SIF, cuando la anulamos, la podemos poner a cero en nuestro SIF ?. Se supone que has enviado un primer registro de facturación y segundo registro de anulación.

La subsanación se hace cuando habiendo aceptado el registro la Aeat, has informado mal la fecha de operación por ejemplo (la has puesto mayor que la de expedición).
Para esto es el caso
<Subsanacion>S</Subsanacion>
<RechaPrevio>N</RechaPrevio>

En este caso, modificarías la fecha de operación en tu registro SIF y emitirías ahora el registro de subsanación con la nueva fecha.

Gracias por el aporte

Correcto. He respondido sobre la cuestión que no era el tema, o sea, sobre la pregunta que planteaban a hacienda, que no era correcta, ya que el error del destinatario sí está contemplada en las rectificativas.
Estoy entrando en bucle con las rectificativas, veo rectificativas en todos lados.

Pero ya es oficial y está publicado al completo?

Quiero decir, hasta ahora yo me movía principalmente con la documentación que colgaban en pdfs (descripción del servicio web v1.0 y algún fichero de "anexo") que por más que miro no encuentro...


Saludos

Una duda me surge


Los clientes que están sujetos al SII no están obligados a pasar por Veri*factu. Hasta aquí correcto, pero nuestro SIF tiene que cumplir alguna de las obligaciones de los no veri*factu p.e. la de conservación etc...?

Tienes que cumplir con el reglamento del SII. El reglamento es diferente para uno que para otro, y como ko te han dicho como conservar trazar...en n caso de SII, pues loque diga el SII y el reglamento de facturación, o sea, el mismo cumplimiento de normativa que tuvieras antes del reglamento de verifactu.

No es oficial. Pero el anexo en excell y algun dato en el xsd del servicio de envio si lo van cambiando. Con eso voy trabajando

Gracias ermendalenda

SII excluyente
 

Por el momento así es, el SII te excluye del deber de actuar conforme a las normas de veri*factu. Al menos de momento. En alguna charla de la AEAT eso dejaban caer.

"Cuando las barbas de tu vecino veas cortar..."


Aunque es solo una impresión personal creo que van a unificar los dos en veri*factu (SII + veri*factu). Tampoco tiene sentido que el NO veri*factu tenga unas reglas tan extrictas y en cambio el SII no tenga ninguna.
Y después de algunas tardes de sobremesa con algunos amigos del sector opinamos que al final todo se reducirá a una factura electrónica con sus pagos/cobros. Y FacturaE no será el último formato. El tiempo lo dirá.


Un saludo.

HTTPRio
 

Como todos. tirando código y creando otro nuevo. Y perdidos en el Olimpo.

A todo esto, ¿ alquien piensa subir el xml hecho "a pelo" a través del httprio sin usar los métodos definidos por la AEAT en su wsdl ?
(sin crear código automático importando el wsdl en delphi/c++ builder)

Gracias por anticipado.

Yo cuando saquen la OM y ya sepamos más o menos por donde nos movemos creo que lo intentaré con los métodos de la AEAT, el SII lo tengo a pelo pero esta vez voy a hacerlo con esos métodos porque creo que será más fácil. Dentro de un mes igual te digo lo contrario :)


saludos

Interesante
 

Usas el httprio inyectando xml creado a pelo ?
Eso es interesante. Tendrás que retomarlo con lo de la factura electrónica, a menos que se pongan las pilas y saquen un wsdl.

Hay código en algún lugar para ver como el httprio puede subir un xml "prefabricado" ?

Me da igual delphi que c++ builder.
Un saludo.

No sé si te refieres a esto, así lo tengo yo pero lo cogí de un ejemplo del propio club creo recordar:

en el BeforeExecute envío un archivo xml que previamente he generado (e_FicFEMI) y que se encuentra en una carpeta del servidor:

Código Delphi [-]

procedure TfrmEnvioFraEmi.HTTPRIO1BeforeExecute(const MethodName: string;
  SOAPRequest: TStream);

    var
      ss:TFileStream;
      vlfichero : string;

begin

    // configurar parámetros para seleccionar el archivo a enviar

    try
        SOAPRequest.Size:=0;
        ss:=TFileStream.Create(e_FicFEMI, fmOpenRead);
        SOAPRequest.Position := 0;
        SOAPRequest.CopyFrom( ss, ss.Size);
    finally
        ss.Free;
        SOAPRequest.Position := 0;
    end;





end;

en el AfterExecute capturo la respuesta y la guardo en otra carpeta del disco duro

saludos

Sí próximamente. Voy a poner xmls de verifactu y de face, todos hechos a pelo, para los que queráis avanzar

Gracias!!!

Pues tarde p temprano igual que en Italia, un formato para todo. Es un tema que ya se ll han reprochado.
Bajo mi opinion, Facturae será pero ampliaran/cambiaran ciertas cosas, de momento tiene un nodo llamado extensiones que puede que tiren por ahí. Me da la impresión de que son muy conservadores y les gusta aprovechar los recursos y estructuras que ya tienen, por ejemplo redsara

Veo que lo haces con un stream, muy interesante.
Lo traduciré a c++ builder y a hacer pruebas.
Un buen aporte.


Gracias.

Para que se puede necesitar
 

Verás, si creas el xml y lo archivas en una tabla para poder cotejarlo posteriormente con los datos originales y el hash podría pasar algo curioso si usas los métodos creados automáticamente a partir del wsdl de la AEAT.
Podría pasar que cualquier espacio o signo que varíes en el envío con dicho código a la AEAT no se corresponda con el xml archivado con su hash y posiblemente certificado. O simplemente el código creado automáticamente a paritr de la wsdl te los cree. O que una etiqueta del xml tú la dejes en blanco por no uso y el código no te cree la propia etiqueta. Todo esto haría que el hash se fuera por la borda.

Estoy valorando cambiar lo que ya tengo creado por c++ builder a partir del wsdl y pasarlo a código hecho a mano de tal forma que el xml archivado sea el mismo que copio y envio a la AEAT. Simplemente estoy valorándolo pero hay varias papeletas a favor de optar por esa opción.



Gracias de nuevo.


P.D. en mi caso el código SII lo creé de forma automática hace ya años, cuando comenzó, y cada cambio que hace la AEAT me obliga a cambiar programación en diversos sitios. De forma manual me habría resultado mas sencillo el mantenimiento del soft.

;)

Eso es cierto, yo el código de SII lo he variado muy poco, si que capturo la respuesta con los métodos de la AEAT y esa parte por ejemplo si la he tenido que cambiar más en alguna actualización. Una razón más para hacerlo a mano, bueno habrá que valorar. Ya te digo, igual dentro de un mes pienso lo contrario :)

saludos

Perdón, creo recordar que utilizo los métodos cuando consulto las facturas que he subido al SII, hay a veces si que hay más cambios, no en la respuesta del envío.

En el caso de vereifcatu va a ser dificl que pase, ya que el cálculo del hash se hará sobre nodos sueltos, numericos y el del CIF.
Algo así
Con lo cual no creo que admita caracteres extraños
Lo único que hay tener claro es que concatenes los campos, para el calculo del hash, con retornos de carro, ni caracteres nulos.

Corrijo
No concatenar con retornos de carro ni caracteres extraños

Etiquetas xml
 

Corrígeme si me equivoco (es posible en este caso) pero ¿ no hay que hacer el hash de toda la estructura XML ?
Incluyendo datos del fabricante y del producto.
Si no es así, ¿ puedes indicarme al menos si están descritos en algún pdf o comunicado de la AEAT ?


Gracias.

En la primera Versión era así, pero debido a posibles problematicas que han reportado en el periodo de consulta corrigieron y dijeron que iban a ser solo unos campos(nodos), en la excell de los esquemas(extensiones) también hacen referencia que ya diran sibre que nodos se calcula, pero que serán algunos. En el esquema del webinar del día 14 hay una pequeña referencia en el que encabezan como "IMPORTANTE" y se ven unos "posibles nodos" sobre los que se calculará, vi en ese cuadro que aparecía un nuevo nodo, el de cuotatotal, y he visto que ahora también aparece en el nuevo esquema. Así que hay muchas posibilidades de que en un alto porcentaje sean esos nodos y quizás alguno más.

Aquí el pantallazo de lo.que te comento

He tenido que reducir la imagen muchisimo, no permiten tamaños de mas de 33kb

aqui el detalle de los nodos