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

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

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?
...

[bmfranky]

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

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.

[bmfranky]

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

[JM_1]

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

[rci]

Empezado por JM_1

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.

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

Empezado por JM_1

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

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.

Empezado por rci

Se nota que no interesa a hacienda que se implemente el modo "No Veri*Factu".

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

[JM_1]

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

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.

[JM_1]

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

Un saludo

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

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

[JM_1]

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

Gracias Neftali