Evento 10 - "...antes de cerrarse o apagarse"
 

Para los que estáis implementando evento (sistema NO-VERI*FACTU); El que no se envían los registros de facturación de forma inmediata.

Para los que estáis implementando el tema de eventos, me interesa mucho saber qué tipo de sistema tenéis y "cuando" estáis implementando este evento, porque en la documentación pone "muy poco" y nosotros no nos aclaramos en qué punto generar este evento.
En nuestro caso tenemos un sistema 1..N servidores y 1..N puestos conectados.

La documentación y las preguntas y repuestas de la AEAT sólo dice esto:



Así que no tenemos claro la frase "antes de cerrarse o apagarse".
¿Al cerrar cada puesto?
¿Cuándo se desconecta el último puesto cliente?
¿Al apagar el servidor?
¿Al apagar el servicio, aunque no se apague el servidor?
...

Hola Neftali , esto ya lo estuvimos comentando , recuerda que yo te pregunté que consideraba ese inicio y fin de estar conectado si era el inicio de sesión o cuando se apagaba todo completamente realmente si lo hacéis servidor con con usuarios que se conectan debía ser cada vez que entra y sale un usuario ese mismo usuario encadenar en el mismo que ha entrado y salido y una referencia sobre ello en el servidor y cuando se apague hace una general como que se ha agado el servicio.
O sea desde mi punto de vista deberían hacer dos encadenamientos uno por cada usuario que se conecta vale y otro centralizado en el servidor por el hecho de siempre cubrir que ha hecho quien en qué momento y no suele cargar nos encadenamientos en el servidor, o sea como un log general del programa completo y un log en determinado por cada usuario/puesto que se conecta/desconecta.

Perdón como se ve pero es que se lo estoy dictando, al móvil no puedo escribir en este momento.

La verdad es que con la poca o casi nula documentación que hay sobre el registro de eventos, su obligatoriedad para el caso "No-VeriFactu" y sin especificar debidamente su casuística en documentos oficiales y sin ejemplos oficiales de mínimo, me recuerda un poco a ir por un pasillo con las luces apagadas e ir palpando las paredes con las manos a ciegas para no romperte el dedo de un pie con un pilar sobresaliente ...

Se nota que no interesa a hacienda que se implemente el modo "No Veri*Factu".
De hecho un responsable de la ley antifraude comento que inicialmente no estaba previsto ese modo, pero les "obligaron" a ponerlo y dijo que mas adelante va a desaparecer y todos los programas tendrán que ser modo Veri*Factu.

Nosotros o hemos implementado, pero hemos tenido que hacer bastantes consultas.
El tema de eventos no está claro y no hay mucha documentación como decís.

Desde un principio ya dejaron clara sus postura (en las primeras presentaciones). Ellos prefieren VERI*FACTU, de ahí que NO-VERI*FACTU le pongan tantos problemas y requerimientos... Por lo de los eventos es un cristo y un despropósito...

Estoy de acuerdo contigo. Si la administración prefiere un sistema u otro, pero ahí está la elección del cliente de uno u otro. Estaría bien si estuviera bien diseñado y pensado ese sistema de "castigo" para el No-VeriFactu, pero no. Es decir, el cliente es quien elige el sistema a usar, si VeriFactu o No-VeriFactu, y nosotros los que cumplir con ello si el cliente lo elige, y si escoge No-VeriFactu, el software es en realidad quien recibe todo el castigo de toda la enmaraña que hay que hacer para cumplir con la ley y toda la altísima probabilidad mayor de errores que hay que controlar y desarrollar con tan solo el registro de eventos, de forma adecuada, a parte de los registro de facturación. Se castiga a los SIF y no a los obligados de emisión, que podrían haber hecho más atractivo su "sistema preferido" (administración) al obligado, con incentivos como deducciones etc... respecto al No-VeriFactu.

Tratamiento anuladas en resumen de eventos
 

Hola, buenas tardes.

¿Cómo habéis afrontado vosotros en el registro de eventos, en resumen de eventos tipo 10 los registros anulados? ¿Alguien sabe con certeza si en los nodos <NumeroDeRegistrosFacturacionAltaGenerados> se anota todos los registros generados independientemente de si han sido anulados, y los nodos <SumaCuotaTotalAlta> y <SumaImporteTotalAlta> tienen las sumas de las cuotas y los importes de todas las facturas independientemente de si han sido anuladas y el nodo <NumeroDeRegistrosFacturacionAnulacionGenerados> simplemente registra el número de facturas anuladas?

O si por el contrario en el nodo <NumeroDeRegistrosFacturacionAltaGenerados> hay que restar el número de registros anulados y en los nodos <SumaCuotaTotalAlta> y <SumaImporteTotalAlta> hay que restar las cuotas y los importes de las que están anuladas? La documentación no es muy clara al respecto y no lo especifica para la importancia que tiene !!!:-|:confused:

Un saludo

Nosotros no hemos restado.
En alta, los de alta y en anulación los que corresponden a borrados/anulaciones.

Al final yo creo que intentan saber si has anulado 3 facturas o 300. En el primero caso no creo que pase nada, en el segundo "huele" a inspección para saber qué estás haciendo...

Yo interpreté lo mismo según el reglamento. Si no se especificaba, actuar así también.

Gracias Neftali