Gracias jlmoli_67

Nodo [Cupon]
 

Hola, no sé si alguno ha visto el nuevo nodo en esta versión.
Cupon
Identificador que especifica si tiene minoración de la base imponible por la concesión de cupones, bonificaciones o descuentos cuando solo se expide el original de la factura. Este campo es necesario porque contribuye a completar el detalle de la tipología de la factura.
Si no se informa este campo se entenderá que tiene valor “N”.

A ver si alguno entiende la parte que he subrayado, parece que si generas copia o duplicado NO?, lo veo fatal explicado.
O sea si aplico cualquier descuento en tiquet o factura tengo que informar este campo?
Uff este campo es muy chungo.

Esto es lo que indica el SII sobre ese campo.

Nosotros es un campo que lo tiene que marcar el usuario si lo quiere. Como ves solo se puede marcar en las rectificativas, no es para cualquier tipo de descuento.

Ufff, gracias, menos mal.

Chorus
 

Aunque lo he puesto en un post de la factura electronica, os dejo esto en el que se habla de verifactu y la B2B
Chorus, es lo que parece que va a ser la plataforma gratuita para cumplir con los requisitos minimos de la B2B, esperemos que sea así:
https://sede.agenciatributaria.gob.e...ta-sesion.html

Dureccion de envio para entorno de pruebas
 

Buenos dias,


Alguien me podria decir cual es la direccion para verifactu a la cual hay que enviar el xml mediante soap al entorno de pruebas?


Es la primera vez que lo intento y tengo un lio de mil pares de narices.


Gracias

Buenos días
Aún no existe el entorno de pruebas, hay que esperar, cuando publiquen en el BOE la Orden Ministerial se sabrá.
Dicen que en las próximas semanas (que puede ser, y ojalá sea, en los próximos meses:D)

Muchas gracias.

Pienso que deberian de haber dejado todo preparado antes de poner el reloj de los 9 meses a contar,pero en fin,es lo que hay. Te agradezco la informacion.

Hola,

El reloj de los 9 meses se activará a partir de que se publique la Orden Ministerial.

Saludos

Estupendo. Me das una alegria

Gracias

Lógica encadenamiento por incidencias
 

Hola, aunque esperaremos a la O.M. a ver como veis la lógica por incidencias.

Ejemplo 1
Incidencia:
Genero Factura 1 Envio Factura 1 (Me devuelve que tengo que enviar minimo 2 registros o esperar minimo 15 minutos)
Genero Factura 2 Encadeno con 1
Genero Factura 3 encadeno con 2

Ocurre una incidencia, error de disco... El registro numero 2 se corrompe y tengo que regenerarlo
genero Registro 2 de nuevo encadeno con 3 y creo Nodo <Incidencia>S</Incidencia>

Genero Factura 4 encadeno con nuevo registro 2


Ejemplo 2
Incidencia:
Genero Factura 1 Envio Factura 1 (Me devuelve que tengo que enviar minimo 2 registros o esperar minimo 15 minutos)
Genero Factura 2 Encadeno con 1
Genero Factura 3 encadeno con 2

Ocurre una incidencia, error de disco... El registro numero 2 se corrompe, la Base de datos se corrompe, no puedo recuperar registro, creo un log de incidencia(Que aun no sabemos si hay que hacer con estructura si estoy en envio inmediato)
Ahora hay 2 posiblidades:
He perdido un registro de factura, que si es algo importante lo recordare y podre marcar de nuevo, la siguiente factura, al no existir datos vuelvo a generarlo como Factura Numero 2 pero con el nodo <Incidencia>S</Incidencia> por que he detectado una anomalia pero con los datos que recuerdo.
O es una factura simplificada de algo de poco importe y no recuerdo nada: la siguiente factura, al no existir datos vuelvo a generarlo como Factura Numero 2 pero con el nodo <Incidencia>S</Incidencia> por que he detectado una anomalia, PERO SE PIERDE UNA FACTURA SIMPLIFICADA.

A ver como lo veis, y que hariais.

Esta tarde zoom hacienda
 

Buenos días
No voy a poder ver el zoom, si sabéis donde ño cuelgan después o podéis hacer un r3sumen os lo agradecería
Si podéis alguno preguntar si van a ser muy estrictos con la rotura de encadenamiento para los que envian(veri*factu) es ll que más miedo me da, ya que algún error no contemplado puede provocar una rotura de encadenamiento en algún momento dado. A ver si son un poco flexibles, ya que entiendo que si estanos enviando continuamente y de vez en cuando se produce esa rotura no deberían contemplarlo como algo grave.
Saludos

Si son flexibles (que imagino que deben de serlo) no te lo van a decir porque podríamos pensar "ancha es Castilla". Yo intentaré estar pero todavía no lo tengo seguro.


Saludos.

Gracias
Otra cosa.
Ojocon los servicios de ubicación de windows para cambiar fecha y hotlra.
Menos mal que he puesto en el mismo programa la comprobación

Buenas.


Ya ha acabado el webbinar de la aet.


Resumiendo: En principio dicen que TODO lo publicado va a cambiar, cosa que no es extraña, así que lo tengamos en cuenta. Por lo demás no han aclarado mucho más de lo que ya medio hemos comentado por aquí.



Para que todo el mundo lo tenga claro (yo ya medio lo sabía) va a haber dos tipos de SIF (programas de toda la vida), los verifactu y los que no lo son pero los dos sistemas tendrán que tener la capacidad de enviar la misma información; los verifactu en tipo real y los NO verifactu a demanda de la aeat pero con el mismo formato. A los sistemas verifactu les dará igual la huella, la firma y el registro de eventos porque se envían de forma directa y a los NO verifactu les obligarán a mantener el encadenado, registros firmados y registro de eventos.


Un tema peliagudo es que hemos preguntado varios que qué pasa si el usuario de un sistema NO verifactu consigue abrir la base de datos y modificar registros y básicamente nos amenazan con que convenzamos al cliente para que envíe y quitarnos ese marrón de encima porque no tienen claro las repercusiones que nos puede traer si eso ocurre, y lo han dicho en varias ocasiones.


Se dan un plazo de un par de meses a partir de que se publique el desarrollo de la ley para poner a disposición las urls de pruebas así que paciencia.


De momento no se me ocurre nada más que se haya comentado y que sea relevante.


Saludos.

Edito: Irán poco a poco ampliando las FAQS con todas las dudas que les van llegando.

Lo escuché yo también y destaco más o menos la pregunta de

Da la sensación de que los que envían por SII es un sistema mucho más "ligth" que las empresas que lo hagan con Verifactu que encima serán pequeñas y medianas empresas...lo cual no tiene mucho sentido...


Y han venido a contestar...


Uyyy que no es más complicado acogerse a verifactu que al SII, que con el SII tienen que además subir las compras (que es cierto)...


Mi opinión es que tienen razón los "preguntantes".....sobretodo a nivel de usuario de facturación es mucho más limitante hacerlo por Verifactu que por SII. No entiendo el motivo...


También han dicho que puede acogerse todo el mundo que quiera al SII y solucionado...que no sé yo

Bueno... cualquiera que lo solicite puede entrar en el SII y quitarse de enmedio el rollo verifactu pero ganarás por un lado y perderás por otro por lo que no sé si merece la pena. Para mi (dependiendo también de la empresa) es más complicado el SII que el verifactu porque, como han apuntado, verifactu no entra en la naturaleza de la factura. En el SII dependiendo de la empresa se puede complicar la cosa bastante cuando entras en los distintos tipos de factura: intracomunitarias, exportación, inversión del sujeto pasivo, compras y gastos (que no existen en verifactu), etc. etc. Aparte de que las declaraciones de IVA pasan a ser mensuales que dependiendo de la empresa puede venir mejor o peor por lo que cada empresa es un mundo.


Saludos.

Gracias
Más o menos se imaginaba respecto a si quieres SIi pues ala, pero si emites toquets ya tienes que mandar sii, compras y ventas. Es diferente, tienes sus ventajas e inconvenientes.
Lo de que no haya que encadenar, pues estupendo, mucho mejor para todos. Si no van a faltar inspectores e informáticos.

Hola a todos.

Otra cosa que dijeron es que el código QR es para todas las facturas, ya sean Verifactu o no tienen que llevar el código QR. A no ser que hagas el SII.

Esta claro que si tu empresa esta en el SII te libras de todo esto. Pero eso puede ser una solución para el cliente, pero no para los que hacemos programas de facturación, ya que para que el programa sea competitivo tendrá que estar adaptado por lo menos a VERIFACTU.

Además el que una empresa haga el SII no es tan sencillo, ya que si haces el SII pasas al REDEME y por lo tanto tienes que hacer el IVA mensual y no Trimestral, registrar las compras, ciertas operaciones intracomunitarias, etc...

Una cosa que yo creo que intentaron decir es que se opte por VERIFACTU, ya que sino a parte de tener el registro de eventos, es casi imposible garantizar que no se puedan producir cambios en los registros de facturación. En el caso nuestro se trata de un programa comercial que se instala en el ordenador del cliente y por lo tanto puede entrar en cualquier momento y ponerse a borrar o restaurar ficheros, ¿y como controla eso tu programa?. Por no hablar de que puedan acceder a los ficheros y cambiar registros.

Yo creo que vamos optar por el camino de sólo VERIFACTU, ya que así es mas sencillo y la responsabilidad del programa es menor, y para los que hemos desarrollado TicketBAI no es tanto cambio. No se como no han hecho como en las forales, TODO EL MUNDO A TICKETBAI y punto.

Hola,

También aclararon que si se usa la opción Verifactu (opción que recomendaron encarecidamente), para el envío de las facturas se podrá emplear no sólo el certificado digital del obligado tributario sino también el de un tercero.
En este caso, el tercero deberá ser Colaborador Social y tener un documento por el que el obligado tributario le autoriza.
El modelo es éste

Saludos

Y aclararon que si se opta por utilizar Verifactu ya no hay obligación de firma de la factura ni de llevar el registro de eventos.
Por supuesto, sí se obliga en Verifactu a que la factura lleve un hash.

Gracias a todos los por la información
me han comentado varias cosas sobre los que van a hacer Veri*Factu(Envio):
*La Huella y el encadenamiento es necesaria, alguien ha comentado que para verifactu no lo es, pero debe estar equivocado, me han enseñado el esquema.
*La huella SHA256 en Hexadecimal y MAYÚSCULAS
*Se deben subsanar los errores (de los registros que te devuelvan con error) y volver a remitir los registros subsanados(Ya diran como, supongo que como incidencia....)

Resumen del Seminario
 

Hola a todos, os pongo las ideas que he sacado del seminario de ayer por si pueden ser de interés para alguno. Espero no haber cometido ningún error.

1.- Recomiendan el uso del sistema VeriFactu como opción segura para ofrecer al cliente. La opción del requerimiento tiene implicaciones que son de difícil cumplimiento y te cargan con una responsabilidad, la conservación, que es complicada de asegurar para una instalación desatendida.

2.- La imposibilidad de remitir temporalmente los registros de facturación por problemas técnicos puntuales la entienden y se abren a que utilicemos el campo Incidencia (S) de la cabecera del mensaje para notificar dicha situación. Incluso hablaron de casos en los que sólo hay Internet a ciertas horas del día y que eso es plausible.

3.- Han dejado bien claro que los sistemas VeriFactu están excluidos de la conservación, firma electrónica, accesibilidad y eventos de los registros de facturación. El evento de entrada / salida de Verifactu sólo atañe en el caso de que, NO estando en VeriFactu, (debes tener eventos) quisieras cambiarlo y entrar en Modo Verifactu, entonces deberías generar ambos eventos de salida y entrada. Ya en el nuevo modo, desaparecerían.

El modo Verifactu se resume en, envío automático, consecutivo, encadenamiento de registros y generación de huellas para cada registro de facturación. Ya para factura impresa o electrónica, adición de Qr.
Hablaron sobre el control de flujo (n,t). En principio lo van a cambiar, ya que, el número máximo de envío de registros en un mismo mensaje agrupado ya está limitado, son 1000. Por lo tanto, el parámetro “n” carece de sentido. Sí, van a utilizar el parámetro “t” en segundos.

4.- Aunque han dicho que van a mantener los servicios diferenciados para la remisión de registros a través de VeriFactu y a través de requerimiento, tiene la idea de que, dichos registros, contengan la misma información, por lo que se avecina otro cambio en la estructura del registro de alta y de anulación

5.- Piensan unificar en el mismo mensaje de envío, registros de alta y de anulación.

6.- La huella hash ya no será del nodo registro de facturación sino que se construirá con ciertos campos del xml que ya indicarán. Y lo más importante es que un error en esta huella no será considerado como motivo de rechazo sino como aceptada con errores.

7.- Dejaron entrever, que la idea final es que sólo exista un método de envío de registros de facturación a la aeat, por lo que al final, tenderemos a un híbrido entre el SII y VeriFactu como sistema de envío. Por ello, la idea de adherirse al SII para no cumplir con VeriFactu deberíamos desecharla.

8.- Los certificados electrónicos de terceros serán admisibles para remitir los registros de facturación de un obligado tributario, idéntico al SII.

gran resumen, de acuerdo con lo dicho, gracias compañero ^\||/

Buenos días, gracias por el resumen a todos. Entonces si el sistema es Verifactu tienes que utilizar un certificado para enviar pero no para firmar la factura. El certificado tiene que estar instalado en todos los ordenadores que envíen.

Sigo pensabdo que van a mezclar verifactu con la factura electronica

Sigo pensabdo que en el xml van a mezclar verifactu con la factura electronica y Tarde o temprano meterán las líneas de los conceptos facturados.

Excelente resumen, muchas gracias.

Si el sistema es SOLO verifactu, no se aplica el registro de eventos en ningún caso ? Ni entrada al sistema, salida,... ?

Si el Hash se calculará sobre ciertos campos no tendremos que serializar primero el XML para obtener el nodo, entiendo ?

Algunas de las diapositivas que considero más importantes en la presentación.
Espero que aclaren las cosas junto con la explicaciones que habéis ido comentando...












Diferencias entre VERI*FACTU y no VERI*FACTU:

Y aquí adjunto algunas que son más técnicas (y porque en el mensaje anterior ya no me va a dejar añadir más... :D:D

No hay eventos en modo VeriFactu, de ningún tipo.
Como el hash se va a calcular sobre campos concretos, lo podrás obtener antes de crear el xml por lo tanto, no tienes que obtenerlo del xml generado.

Añadido el documento al FTP del club y añadido enlace al mensaje #1 (recopilatorio).

Se simplifica bastante, muchas gracias

Una pregunta a ver si alguien me puede aclarar una duda que tengo desde hace tiempo.
¿Se deben generar los xml de cada factura por separado?
¿Luego de generados se genera el soap para enviar?
Gracias anticipadas.

En el supuesto de acogerte a envio inmediato: Comp no tienes que conservarlo puedes hacerlo como quieras, pero debes tener en cuenta que te pueden contestar en el resp del soap al enviar que el próximo envío el número de xmls por ejemplo sea 10 registros encapsulados en el mismo soap o 300segunfos de espera. Entonces lo recomendable es que generes el xml por un lado y encapsules en el soap al enviar.

Claro, ahora comentan que la huella va calculada de datos especificos de la factura (mucho más sencillo) y antes era del nodo <RegistroFacturacion>, que esto no facilitaba las cosas, de ahí mi duda.

Vale perfecto tiene lógica, mientras encapsulas calculas la huella desde los datos de factura, no de ningún nodo. mil gracias como siempre @ermendalenda.

A ver si se aclara esta gente de una maldita vez.

A mi me da un poco igual de donde se calcule, como genero el xml a pelo puedo elegir los nodos que quiera para calcular el hash antes de grabar el xml.
Supongo que ya cada uno tendrá sus complicaciones.
Lo que si tienes que calcular elhash antes de generar el qr de la factura, eso está claro, la explicacion de calcularla mientras encapsulas el soap antes de encapsular no es muy correcta, ya que en el qr, casi seguro va a ir parte del hash calculado, al igual que ticketbai con la firma, es la única forma que tiene para garantizar que no cambies algo entre la emisión y el envío.

Aqui ya me he perdido.... el hash antes de generar el qr de la factura

Si que me gustaría ver un ejemplo de como encapsulas uno o varios xml generados con anterioridad. Me sería de mucha ayuda

Yo te lo pongo pero no sé si te vas a liar más, ya que yo trabajo en Vb6 para generar el xml y despuñess las firmas y encapsulamientos soaps lo hago en php con llamadas desde curl.
En Delphi hay otras formas que los compañeros del foro seguro que te pueden guiar.

Mira el código para generar el XML (A pelo) es de esta forma:
Por otro lado puedo encapsular en php, ya que en VB6 desconozco la forma, pero en mi caso hemos pagado a una empresa la programación y el servicio de conservación y le vamos a enviar los xmls sin encapsular para que hagan toda la hilera de verificación del encadenamiento, validación schema xml-xsd, conservación, encapsulamiento, envios y control de errores, el envio lo harán con su certificado y ellos le dan este servicio a cada cliente al que le cobraremos un precio "razonable", y me libero de la parte peor. Cada cliente recibirá o podrá consultar el reporte de los envios y si hay errores se avisará y se tomará las medidas según cada caso, esto ya lo tenemos definido.

codigo ejemplo php encapsulamiento y envio
 

Aquí te dejo un encapsulamiento y envio, totalmente funcional para face y faceb2b en entornos de prueba y producción, si aprendes como funciona lo puedes modificar para cualquier definición que hagan teniendo en cuenta que yo le paso el path donde tengo el fichero y los datos por curl de esta forma:
[/php]