Venga, ya tengo un error serio.

[ermendalenda]

Tengo un sif, con un módulo particular que genera mal el xml
Donde tenia que poner NumSerieFactura he puesto NumSerieFacturaRegistroAnterior
De donde coj.. he sacado ese nombre, recordais si en la primera version 0.1 estaba así?
Ahora tengo que esperar a que terminen el dia para generar 800 subsanaciones. Vaya tela

[bmfranky]

Empezado por ermendalenda

Tengo un sif, con un módulo particular que genera mal el xml
Donde tenia que poner NumSerieFactura he puesto NumSerieFacturaRegistroAnterior
De donde coj.. he sacado ese nombre, recordais si en la primera version 0.1 estaba así?
Ahora tengo que esperar a que terminen el dia para generar 800 subsanaciones. Vaya tela

Pues acabo de revisar y , desde la versión 0.3 seguro que no se llama así, antes no se decirte no tengo nada mas viejo.

[ermendalenda]

Empezado por bmfranky

Pues acabo de revisar y , desde la versión 0.3 seguro que no se llama así, antes no se decirte no tengo nada mas viejo.

Lo habré arrastrado de lss pruebas con ticketbai, o me fumé un puerro ese día

[CarlosArjonomia]

Hoy veo que un cliente no está enviando. Me conecto y no se que les ha pasado a primera hora que va y me restaura una copia de seguridad por su cuenta de antes de verifactu, todas las configuraciones y registros de huella al garete. Va y hace una copia de la carpeta completa.

En las aplicaciones de escritorio estás cosas no las podemos controlar y se van a armar unos pifostios que no me quiero imaginar.

Vamos a perder la salud.

[ermendalenda]

Si es otra.yo tengo in franquiciado que por su cuenta hace copiss y restaura cuanfo tiene problemas.
Y ya despues llama
Da igual que se lo haya documentado, va a hacer lo que le da la gana y seguro que no se ha leido nada

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

Empezado por CarlosArjonomia

Hoy veo que un cliente no está enviando. Me conecto y no se que les ha pasado a primera hora que va y me restaura una copia de seguridad por su cuenta de antes de verifactu, todas las configuraciones y registros de huella al garete. Va y hace una copia de la carpeta completa.

A ver cómo lo solventas.
Nosotros les explicamos esto a los de la AEAT y "pantallazo azul".
Para ellos esto no puede pasar. No se siquiera, si lo han tenido en cuenta.

En cuanto a generar las nuevas facturas, imagino que crear una serie nueva (o poder configurar la serie para el nuevo número de factura) y conseguir así no repetir los números de las facturas que se han subido y perdido.
A partir de ahí se romperá el encadenamiento y en todo caso habrá que justificarlo a la AEAT si dicen algo (explicando que ha habido una pérdida de datos).
Rezar para que las facturas que tienen los clientes sean correctas y no haya que hacer nada con ellas (rectificativa), porque no se podría enviar (no tenemos la original).
En nuestro caso crearíamos de nuevo las facturas en el sistema indicando que son facturas "solo-para-contabilidad" (concepto raro) para que puedan constar en el sistema a todos los efectos, pero que no se suben a veri*factu. Esto último es para que todo cuadre en el ERP (contabilidad, listados, modelos hacienda, analíticas,...).

[bmfranky]

Lo del encadenamiento, no es realmente un problema, ten en cuenta que según ellos, al reinstalar , has de asignar un nuevo numero de instalación, entonces generas una nueva lista de encadenamientos.
Ahora ya entiendo porque tanta tontería de asignar un nuevo numero de instalación, para todo.

[edari]

Empezado por CarlosArjonomia

Hoy veo que un cliente no está enviando. Me conecto y no se que les ha pasado a primera hora que va y me restaura una copia de seguridad por su cuenta de antes de verifactu, todas las configuraciones y registros de huella al garete. Va y hace una copia de la carpeta completa.

En las aplicaciones de escritorio estás cosas no las podemos controlar y se van a armar unos pifostios que no me quiero imaginar.

Vamos a perder la salud.

Miedo da, de verdad


Me quedo por aquí. Cuando lo hayas "solucionado" nos cuentas la aventura.

[CarlosArjonomia]

Empezado por edari

Miedo da, de verdad


Me quedo por aquí. Cuando lo hayas "solucionado" nos cuentas la aventura.

Lo tengo todo redúndate, grabo registro en la DB local, lo envío a la AEAT, lo envío a una API propia, y cada día copia de seguridad a mis servidores a parte de las que hace el cliente.

¿Cómo lo solucioné?

Restaurando la última copia válida donde estaba todo.
Mirando que facturas habían metido nuevas.
Comprobar última factura recepcionada en la AEAT.
Sincronizar número de factura.
Meter de nuevo las facturas que no se habían enviado.

Todo cuadró. Pero si te pasa con 10 a la vez en un día....

Además el nivel de stress es mucho más elevado que cuando no andábamos jugando con la AEAT directamente.

Me estoy planteando un sistema de control que un vez activado verifactu en la máquina del cliente. Se generen archivos ocultos en carpetas del sistema que guarden: último número de factura, y último encadenamiento.

Cuando se ponga en marcha el programa irá a mirar esos registros que el usuario no sabe que existen y no los puede tocar, y mirar si coincide el número de factura y último encadenamiento. En caso de que no coincida bloquear el programa para que pidan asistencia.

Lo de bloquear programas también da miedo. Un fallo en la programación puede bloquear a cientos de usuarios a la vez y la tienes liada.

Este problema no lo tienen los que usan programas en web, ya que controlan ellos las DB.

¿Ideas para evitar el cataclismo?

[jakematespain]

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

A ver cómo lo solventas.
Nosotros les explicamos esto a los de la AEAT y "pantallazo azul".
Para ellos esto no puede pasar. No se siquiera, si lo han tenido en cuenta.

En cuanto a generar las nuevas facturas, imagino que crear una serie nueva (o poder configurar la serie para el nuevo número de factura) y conseguir así no repetir los números de las facturas que se han subido y perdido.
A partir de ahí se romperá el encadenamiento y en todo caso habrá que justificarlo a la AEAT si dicen algo (explicando que ha habido una pérdida de datos).
Rezar para que las facturas que tienen los clientes sean correctas y no haya que hacer nada con ellas (rectificativa), porque no se podría enviar (no tenemos la original).
En nuestro caso crearíamos de nuevo las facturas en el sistema indicando que son facturas "solo-para-contabilidad" (concepto raro) para que puedan constar en el sistema a todos los efectos, pero que no se suben a veri*factu. Esto último es para que todo cuadre en el ERP (contabilidad, listados, modelos hacienda, analíticas,...).

Hola, ¿esto sería legal o correcto? Poder configurar tú programa para que unas determinadas facturas o series de facturación no se suban al Verifactu. Tengo muchas dudas, no se si alguien ha planteado algo parecido. Esta claro que se tendría que hacer justificando el motivo.
Gracias.

[emailesc]

Empezado por CarlosArjonomia

Lo tengo todo redúndate, grabo registro en la DB local, lo envío a la AEAT, lo envío a una API propia, y cada día copia de seguridad a mis servidores a parte de las que hace el cliente.

¿Cómo lo solucioné?

Restaurando la última copia válida donde estaba todo.
Mirando que facturas habían metido nuevas.
Comprobar última factura recepcionada en la AEAT.
Sincronizar número de factura.
Meter de nuevo las facturas que no se habían enviado.

Todo cuadró. Pero si te pasa con 10 a la vez en un día....

Además el nivel de stress es mucho más elevado que cuando no andábamos jugando con la AEAT directamente.

Me estoy planteando un sistema de control que un vez activado verifactu en la máquina del cliente. Se generen archivos ocultos en carpetas del sistema que guarden: último número de factura, y último encadenamiento.

Cuando se ponga en marcha el programa irá a mirar esos registros que el usuario no sabe que existen y no los puede tocar, y mirar si coincide el número de factura y último encadenamiento. En caso de que no coincida bloquear el programa para que pidan asistencia.

Lo de bloquear programas también da miedo. Un fallo en la programación puede bloquear a cientos de usuarios a la vez y la tienes liada.

Este problema no lo tienen los que usan programas en web, ya que controlan ellos las DB.

¿Ideas para evitar el cataclismo?

Nosotros grabamos los XML en disco, además de en la base de datos, pero en una carpeta tipo OneDrive, para que se sincronicen en el momento. Si el ordenador explota o pasa algo al menos tenemos los registros de facturación. Me estoy planteando también grabar archivos de texto o XML con los datos de la factura en sí, y borrarlos por la noche cuando los envíen a nuestros servidores, ya que si pasa algo en medio del día, aunque tenemos una copia de seguridad diferencial de la BBDD, si pasa algo lo más seguro es que se pierda alguna factura

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

Con veri*factu las facturas están en la AEAT, de ahí puedes sacar algo.
Lo "divertido" viene con los clientes han escogido no-veri*factu.

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

Empezado por jakematespain

Hola, ¿esto sería legal o correcto? Poder configurar tú programa para que unas determinadas facturas o series de facturación no se suban al Verifactu. Tengo muchas dudas, no se si alguien ha planteado algo parecido. Esta claro que se tendría que hacer justificando el motivo.

Hay algunas situaciones en las que tienes que tener esa posibilidad. Nosotros nos hemos encontrado con varias...

• Cambias de ERP hasta Junio y migras a otro. Debes importar a tu ERP nuevo las facturas de ese año (o de los 4 últimos), para a partir de Julio enviar desde el tuyo. Esas importadas NO DEBEN subir porque ya se han subido desde el ERP antiguo.
• Trabajas con un TPV que genera los Tickets/facturas y ese TPV está integrado con nuestro ERP que se encarga de todo lo demás. Contabilidad, analíticas, cuadros de mando,... Esa importación de facturas no debe generar nada a Veri*factu porque ya lo hace el TPV
• Solucionar problemas de restauración de datos como el que he explicado. Debes añadir a tu sistema facturas que ya se han subido (porque en tu sistema se han perdido). Por ejemplo, para que la contabilidad en tu sistema quede coherente o si generas Modelos de hacienda sean correctos.
• Estas que recuerde, pero seguro que hay más.

[jakematespain]

Hola, nosotros nos habíamos planteado algo parecido, pero tenemos esa duda legal. Sobre todo es el tema de los tpvs. A nosotros nos llegan a nuestro software central como una factura simplificada, no como una factura normal y muchos clientes lo que hacían es generar una factura ordinaria con todas esas facturas simplificas.
El problema esta en que si usas el cliente genérico para los tpvs, no puedes crear una F3 de esas facturas simplificas. Si es un cliente ya identificado pues pasas esa factura F2 a una F3, pero el problema lo tenemos con esas facturas simplificadas F2 del cliente genérico, para poder pasar toda esa información a la contabilidad. Normalmente lo que hacemos es contabilizar esos arqueos, pero hay cliente que generaban las facturas para que pasaran a contabilidad, pero claro, como dices esas facturas simplificadas ya se enviaron desde el tpv. Habíamos pensado en usar una serie para esas cosas y marcar alguna opción de serie no activa en verifactu.
Por esos mis dudas sobre si era legal.
Gracias

[Faneka]

Empezado por jakematespain

Hola, ¿esto sería legal o correcto? Poder configurar tú programa para que unas determinadas facturas o series de facturación no se suban al Verifactu. Tengo muchas dudas, no se si alguien ha planteado algo parecido. Esta claro que se tendría que hacer justificando el motivo.
Gracias.

Yo tengo configurado para poder seleccionar unas series que han sido generadas con otro SIF pero el cliente las quiere meter para tenerlas en nuestro SIF, estas facturas han sido generadas y enviadas a VeriFactu con otro SIF y el nuestro no lo envía. Esto es legal, ya lo pregunte yo en su día.

[ermendalenda]

Os pongo otra historia:Y tebeis claro que los de verifactu podian tener un pequeño lio xon eso de tener en un sif actualizado facturas anteriores?. Por que a raiz de una pregunta que he hecho me han contestado, como es habitual a preguntas que no esperan, con una respuesta que nada tiene que ver, lo digo por si alguno se atreve a decirles "oye que como es logixo ñas facturas anteriores las tengo que dejar en el sistema". Yo no me he he atrevido a seguir preguntando por que ya sabeis lo que nos lleva una pregunta poco común.
A ver si se han pensado que lo de la instalación limpia en un SIF hay que borrar las base de datos.
A mi me ha asustado un poco la respuesta.

[Jarogo08]

Empezado por Faneka

Yo tengo configurado para poder seleccionar unas series que han sido generadas con otro SIF pero el cliente las quiere meter para tenerlas en nuestro SIF, estas facturas han sido generadas y enviadas a VeriFactu con otro SIF y el nuestro no lo envía. Esto es legal, ya lo pregunte yo en su día.

Facturas emitidas por terceros.

[ermendalenda]

Empezado por Jarogo08

Facturas emitidas por terceros.

No hombre.
Terceros es otra cosa. Terceros es El que la emite en nlmbre de otro, nada que ver xon distintos SIF del mismo OT e impirtarlas para tener la continuidad.
Aunqie las que han wmitido esos terceros las pudas impirtar pero respetando series, nuneracionws, cif emisor...

[Daviid]

Empezado por ermendalenda

Tengo un sif, con un módulo particular que genera mal el xml
Donde tenia que poner NumSerieFactura he puesto NumSerieFacturaRegistroAnterior
De donde coj.. he sacado ese nombre, recordais si en la primera version 0.1 estaba así?
Ahora tengo que esperar a que terminen el dia para generar 800 subsanaciones. Vaya tela

Pregunta por correo, igual ellos tienen copias de todos las versiones de https://sede.agenciatributaria.gob.e...pcion_SWeb.pdf que han creado.

Si buscas en google

"NumSerieFacturaRegistroAnterior"

con las comillas te salen varios XML o sea que en algún momento se usó.