Ya me han contestado y teniais razon :(
Voy a contestarles con una nueva pregunta porque algunos de nuestros clientes tienen mas de una tienda y tienen dos bases de datos (una en cada sede) y con una réplica de SQL Server, para que la información sea la misma en las dos tiendas, pero permitir que sigan trabajando cuando haya eventuales problemas de comunicación entre ellas.

Pero claro, el envío de datos entre una base de datos y la otra (con la réplica) no es inmediato. por lo tanto no podemos encadenar las facturas de una tienda con las de la otra. A ver que me dicen. Ya os contaré.

Muchas gracias

Pregunta de novato en estos temas
 

Buenas, he empezado a crear el código para probar verifactu.
He rellenado los datos de la factura en una variable de tipo RegistroFacturacionAltaType, pero luego para enviarlo se tiene que rellenar un tipo RegFactuSistemaFacturacion.
¿Como creo este ultimo tipo y agrego la factura?

Hola, a mi me contestaron que el encadenamiento es por cada sif(programa) y cif, osea que si teneis varios programas, el encadenamiento es distinto, o usais la misma serie de facturas, para una tienda y la otra?
Por ejemplo pedis a la base de datos central el numero de factura /ticket antes de emitirlo?

Consejo
 

Hola, ¿por qué no validas el xml contra el esquema antes de hacer el envío?

Te evitas enviar xml mal formados o que les falten etiquetas obligatorias.

En TicketBAI ya lo recomendaron en su momento a los desarrolladores y en mi opinión es una ventaja.

Antes de enviar, al hacer la validación contra el XSD te avisa si cumple o no con el esquema.

Es solo una idea...

Saludos,
David M.

como puedes validar el xml antes de enviar para evitar errores ???

Hola, una cosa, a alguien mas le pasa que al verificar las facturas , mediante el qr, algunas dan error aunque hayan subido sin errores?

No programo en Delphi, pero haciendo una búsqueda rápida he encontrado esto en los foros:

https://www.clubdelphi.com/foros/showthread.php?t=35609

Es antiguo, pero es un ejemplo.

Seguramente habrá código más actualizado buscando un poco.

Saludos,
David M

Hola.
Nuestras aplicaciones van a funcionar solamente en modo VERIFACTU, con subida inmediata.
En las aplicaciones se va a ir generando un "registro de facturación" que irá registrando las altas y modificaciones y que será el que se irá subiendo a la AEAT.
Estoy ya subiendo y procesando las respuestas y almacenando en dicho registro los datos de estado, fecha, etc... y los CSV que envía la AEAT.

Mi duda es que no sé si los ficheros XML que utilizo para enviar y los ficheros XML de respuesta, es necesario conservarlos.

Hola bmfranky, si, el programa es el mismo y la base de datos es la "misma" pero realmente son dos que se van replicando.

Usamos series distintas para cada tienda porque antes de emitir la factura se consulta el numero que toca en la base de datos, pero al estar replicada, debemos consultar contadores distintos por no solaparse.

Les he expuesto esto mismo y me han contestado que lo tienen que consultar a los responsables:confused:

Creo que antes de cambiar nada voy a esperar si me contestan algo.

Muchas gracias!

pues ya nos vas contando, pero siendo dos tiendas, personalmente, asignaria dos series distintas y que encadene cada una por su cuenta, te evitas el tener que consultar por el numero de factura a asignar, otra cosa es que sincronices estocaje, y salvaguardes las facturas en otro servidor.
Pero las facturas, mas simple dos series distintas, o almenos ai lo veo yo...

Creo que el problema no es si debes usar dos series (doy por sentado que sí), pero si puedes usar dos cadenas (considerando que son dos SIF distintos).

Si se puede usar dos cadenas en tal caso, el desarrollo es relativamente sencillo, cada uno en su casa. Habrá dos números de instalación distintos, dos declaraciones responsables etc. Y por supuesto un solo código.

Si está prohibido hacerlo, hay que crear un punto centralizado de encadenamiento (que puede ser repartido entre los dos centros) y la complejidad aumenta bastante.

Haver, cada sif, tiene que guardar su encadenacion independiente, la encadenacion es por sif y por nif, siempre con las numeracion que ese sif utilice, entonces yo veo logico por ejemplo poner por ejemplo fv1-codigotienda-numero de factura de esa tienda, puesto que el sif ha de encadenar las facturas que el emita.
yo en su dia lo consulte, puesto que uso mi programa en 2 sitios diferentes y me dijeron que cada instalacion del programa ha de guardar su propio encadenamiento.

Entonces entiendo que, si yo genero una factura ordinaria y luego una factura simplificada, la simplificada debe encadenarse con la ordinaria que fue la última que se emitió antes de generar la simplificada no?

Es decir, que no tengo que encadenar las facturas ordinarias entre si y las facturas simplificadas entre si, que aunque vayan en series distintas y sean distintos tipos de factura, se encadenan siempre la última factura que se emita con la anterior emitida independientemente de que tipo de factura y serie lleve.

Estoy en lo cierto?

A esto venía yo, tengo un cliente que tiene 4 tiendas, todas con el mismo nif, cada tienda tiene sus propias series e identificador de tienda, entonces, cada una de las 4 instalaciones del programa que tiene se considera un SIF independiente y no hay que encadenar las facturas de los 4 SIFs juntos, si no que cada instalación encadena las facturas que emita? correcto?

Creo que solo hay que identificar cada una de las instalaciones en el apartado que lleva el xml para identificar al software, me suena que hay etiquetas para eso. Voy bien?

Os pego la respuesta a esa consula a los responsables.
Cada programa a de gestionar su propio encadenamiento, ademas de como contestaban a utro post anterior cada sif deve de encadenar sin saltos de facturacion a saber si facturo sobre 3 series/numeroacion aunque sean alternas siempre tengo que enviar las numeraciones correlativas a cada serie.

Si has de considerar que cada tienda es un "SIF" independiente porque cada tienda usa el suyo , no?
otro caso es que los tiquets los emita un unico programa , con una unica numeracion, por ejemplo 4 almacenes que envian material , pero solo hay un ordenador que emite las facturas de todos los albaranes...

Hola, gracias a vuestros comentarios empiezo a ver la luz al final del túnel en este caso de tener varias tiendas del mismo Obligado (mismo NIF Emisor). A ver si me aclaro.

Aquí viene la duda, en si puedo considerar que son dos SIF distintos. Y también sobre el número de instalación, que no tengo muy claro que valor poner.
Cada cliente de nuestra empresa es una instalación y un SIF distinto o cada tienda de cada cliente nuestro (cada servidor donde ponemos el ejecutable y la base de datos) es una instalación y un SIF distinto?


Por lo tanto cada tienda aunque sea del mismo obligado (mismo NIF) es una instalación distinta?

La documentación sobre el numero de instalación no parece que hable sobre esto:

Cada tienda ejecuta un programa instalado en su servidor. es el mismo programa pero son dos ejecutables distintos, uno encada tienda. Esto se considera un SIF distinto?

Muchas gracias

Hola, el SIF es el programa que utilizas para emitir las facturas, cada instalacion es independiente de la otra, un nif puede tener por ejemplo, 10 puntos de venta, cada uno encadena y genera numeraciones independientes , y si tienes 100 clientes con 10 programas cada uno tienes 1000 programas independientes trabajando para 100 clientes...
entonces las intalaciones de tu programa que emite facturas iran del 1 al 1000, y cada programa gestionara su encadenamiento , sea de 1 o 10 tipos de facturas diferentes.

cada cliente tendra de cada punto de venta su numeracion independiente.

Muchas gracias bmfranky. lo tendremos en cuenta.
Cuando dices "10 puntos de venta" te refieres a tiendas diferentes no?
porque claro en una misma tienda, cada cliente nuestro, puede tener varios ordenadores, cada uno con el programa y haciendo facturas, todos tiran contra la misma base de datos.
En ese caso imagino que si que es el mismo SIF y la misma instalación, no?

Saludos

Voy a intentar explicar mejor lo del encadenamiento, porque para una cosa que me quedo clara... ;-)


Cada emisor de facturas,"SIF" , ya sea un progrma de facturacion de oficina, caja , bascula , etc... , que emita un tiquet de venta, ha de encadenar sus propios tiquets,independientemente de los demas, otra cosa es que la caja, etc, no sea la que genera el tiquet, sino un servidor central que , a cada peticion de los programas cliente, les asigna una numeracion, ese es el que ha de realizar el encadenamiento , porque es el que genera y envia las "Facuras", lo demas puedes considerarlo impresoras con puntos de acceso.


1-> cada punto de venta deveriamos considerarlo un SIF, independientemente del Nif para el que emita facturas, puesto que puedes emitir facturas de diferentes Nif desde el mismo programa, pero el encadenamiento es temporal, osea si emites una factua de nif1 , serie 1 y despues del nif 2 seri 3 , se encadenan uno detras del otro, hasta donde se independiente del nif(Esto es suposicion mia, pero por lo que me indicabaqndeve ser asi, ya que en el encadenamiento tambien se incluye el nif)


2 ->cada instancia ejecutandose de tu sistema de facturacion se deve considerar un SIF independiente, puesto que lo es ahunque usen la misma base de datos. (Esto se puede obbiar si realmente usan los mismos campos) , pero es mas sencillo el encadenamiento, si se consideran independientes, pueto que si se generan 2 facuras a la vez, pero al enviarlas se envia la factura encadenada en segundo lugar, primero ,puede generar errores de encadenamiento.


3-> No solo cada tienda, como comento cada ejecutable independintemente del cif , es un SIF, distinto con su numero de instalacion, independientemente de la version instalada , en la descripcion de acienda se refieren a que no haya por ejemplo 3 programas con el mismo nombre, serie y numero de instalacion enviando facturas de varis clientes al mismo tiempo, me imagino que querran diferenciar si los fallos al enviar las facturas son devidos al software, la instalacion o "El Borrego Que Lo Usa"... ;-)


Esto no es palabra de ley, pero creo que ser aproxima bastante a lo que se intenta insinuar.

Te lo dejo mas claro arriba, pero , todos los programas usan la misma serie de facturas? No cada instalacion del programa es un SIF distinto, otra cosa es que usen la misma serie de facturas, otorgada por la base de datos, pero entonces la base de datos es la que tiene que encadenar... Un riesgo, lo mires como lo mires.
Para que me entienda, el ordenador 1 pide un numero de factutura a la base de datos para generarla , al mismo tiempo que el 2 , pero por causa x el 2 es mas rapido enviando la factura, rompes la cadena puesto que la factura de 1 que va antes llega despues...

Para encadenar un servidor las facturas dgeneradas por varios puntos de venta.


1 - cada terminmal de venta encadena o
2 - un gestor externo, programa web, o lo que sea crea una un *FiChain , o sea First generate, first chain... encadenamiento, pera cada registro. ahunque eso tira por tierra el sentido de SIF independiente... puesto que en este caso el Sif seria el conjunto de programas y gestor en uno, seria como teminales tontos de un sistema unix, realmente no estas generando nada en locaql, todo es web.



*No me mateis... Se que seria FiFo..

La pregunta interesante aquí es entender lo que es un SIF, dejando este punto claro, yo creo que el encadenamiento se entendería mejor.

El encadenamiento se debe hacer por NifObligadoTributario-NumeroSIF-OrdenCronológicoDeGeneraciónDeRegistroDeAltaoAnulacion.

La clave principal de los números de facturas emitidos por un mismo Obligado Tributario es NifObligadoTributario-NúmeroSerieFactura-FechaExpedición, o sea, esta tupla no se puede repetir.

¿ Qué es un SIF ?, explicado con palabras gruesas sería, "El Sistema ( software instalado en un ordenador o grupo de ordenadores) que es capaz de generar números de facturas de forma autónoma basándose en su propio contador"

Ejemplo 1 : Software de Gestión instalado en Servidor Central al que se accede por Wan o Lan desde múltiples puestos de trabajo. Cada puesto de trabajo emite facturas que provienen del mismo contador. Esto es un sólo SIF

Ejemplo 2 : Software de Gestión instalado en Servidor Central al que se accede por Wan o Lan desde múltiples puestos de trabajo. Cada puesto de trabajo emite facturas, cuya numeración, proviene del mismo contador central. Tiene también varios TPV's que a la hora de emitir factura, utilizan el mismo contador central. Si no hay conexión en ese momento, el Tpv o los puestos de trabajo, no puede emitir factura. Esto es un sólo SIF

Ejemplo 3 : Software de Gestión instalado en Servidor Central al que se accede exclusivamente por Lan desde múltiples puestos de trabajo. Cada puesto de trabajo emite facturas, cuya numeración, proviene del mismo contador central. Además, existen 5 delegaciones geográficamente dispersas con el mismo software de gestión instalado, pero cada delegación genera su propia línea de Facturas utilizando sus propios contadores que no comparten con el resto de delegaciones, o sea, una delegación no necesita conexión con el servidor central a la hora de emitir una factura. Estos son ( 1 + 5 = 6 ) SIF's

Ejemplo 4 : Software de Gestión instalado en Servidor Central al que se accede por Wan o Lan desde 5 puestos de trabajo, cada puesto de trabajo tiene su propia línea de contadores para la emisión de facturas y existen 5 TPV's que a la hora de emitir factura utilizan sus propios contadores, o sea, tanto los puestos de trabajo como el Tpv no necesitan conexión con el servidor central a la hora de obtener un número de factura. Estos son ( 5 + 5 = 10 ) SIF's

Ejemplo 5: Una tienda con dos Tpv's en red donde ambos tienen el mismo software y ambos generan su línea de facturación de forma independiente. Estos son ( 1+ 1 = 2) SIF's

Ejemplo 6: Una tienda con dos Tpv's en red donde ambos tienen el mismo software y generan su línea de facturación de forma simultánea, o sea, sólo hay un contador de facturas. Esto es 1 sólo SIF

Me queda la duda de un software en la nube, con base de datos multi-tenant, donde cada empresa tiene obviamente su propia facturación correlativa.
Entiendo que es un solo SIF, pero cada cliente/tenant lleva su propias numeración de facturas, así que habría que jugar con los campos IdSistemaInformatico, NumeroInstalacion, TipoUsoPosibleMultiOT, IndicadorMultiplesOT.

Volviendo a este tema, que me sigue generando alguna duda... :o

¿Cómo sabemos si una factura "Parcialmente Correcta", que se ha aceptado con errores/avisos, se debe subsanar/anular o rectificar? ¿No sería MÁGICO que la propia AEAT devolviera un campo indicando "se requiere subsanación" o "se requiere rectificativa"? Vamos, yo lo veo.

Pero como no lo van a hacer... ¿Cómo sabemos cómo actuar? ¿Teniendo una lista de las decenas de errores posibles y según cada caso, actuar en consecuencia, viendo qué error es en cada caso, etc.?

Porque queda claro que las facturas NO pueden modificarse (para eso estaba la ley antifraude, no?) Hay que rectificarlas.
Entonces... ¿en qué casos concretos se debe hacer una "subsanación" y no una rectificativa?

¿Podría ser algo así:

- Rectificativas: si cambia el importe de la factura, datos fiscales, algún dato erróneo, etc. (en definitiva, contenido de la factura incorrecto)
- Subsanación: error al generar el XML o el envío, no relacionado con el contenido de la factura (error en la huella, encadenamiento, algún dato mal informado...)

¿Es correcto?

¿Aparte de rectificativa y subsanación, hay algo más?

Yo independizaría la definición de SIF de la arquietectura del software de gestión. Cada usuario o grupo de usuarios con la arquitectura multitenant tiene su espacio de trabajo, por lo tanto y siempre y cuando se use un sólo contador para emitir las facturas, estaríamos hablando de un sólo SIF. Pero puede ocurrir también que tenga Tpv's independientes con sus propios contadores que envíen información a estos sistemas. Estaríamos hablando ahora de varios SIF's. Yo creo que el campo IdSistemaInformatico es el que indica el SIF del que proviene la factura

Por aportar algo más.

Factura "Correcta" (sin errores/avisos):
- Consta como enviada
- No se podrá volver a subir porque Hacienda dirá que está duplicada
- No hay que hacer nada. Guardamos el registro, lo marcamos como "aceptado/enviado", ya tendremos el QR, etc.

Se puede seguir emitiendo subsanaciones a posteriori, por ejemplo, te das cuenta de que el Régimen tributario lo habías enviado mal.

Factura "Parcialmente Correcta":
- Consta como enviada
- No se podrá volver a subir de forma "normal". Hay que subirla como "subsanación".
- Habría que marcarla como "subida pero con errores" para evitar que se vuelva a subir como factura normal y exigir que sea una subsanación
Correcto

Factura "Incorrecta":
- NO consta como enviada
- Habría que marcarla como "Error" para saber que podemos volver a intentarlo
- Podemos arreglar lo que sea que haya dado error y volver a subirla, hasta que devuelva "Correcta" o "Parcialmente correcta"

No puedes volver a subirla, debes emitir una "Subsanación x Rechazo Previo" siempre y cuando te venga un código de error dentro del objeto respuesta (la Aeat la recibió y la rechazó.). Si este objeto viene vacío, indica que la Aeat no la ha recibido y por ende, no la ha rechazado, entonces sí debes de reenviar pero en orden cronológico de generación de registros, o sea, antes un fallo de comunicaciones debes parar los envíos, no puedes permitir mandar un primer registro, te fallan las comunicaciones en el segundo y sigues intentándolo y sí, te entra el tercero.

Para saber si se debe emitir una Rectificativa o una Subsanación, yo estoy agrupando los códigos de error en tres bloques, un bloque donde seguro que es una rectificativa (errores desde el 1162 al 1170 y otros errores donde se referencia el Nif del destinatario), otro en que seguro que es una subsanación (la mayoría) y un tercero donde ambas opciones podrían ser válidas, por ejemplo, Nif no censado se puede arreglar con una rectificativa poniendo bien su Nif o con una subsanación, añadiendo la clave IdOtro con indicación de No Censado.

buenas,

ahi lo has clavado. Ademas ,creo, es lo logico. Hay tantos sif como identificadores de maquinas (1 maquina puede tener varias series). Si envio desde 3 tpvs a un servidor (lo normal, ventas centralizadas) tengo 3 sif pero si ademas a ese servidor se conectan 3 usuarios y siguen la numeracion dada por el servidor independientemente de los tpvs que envian sus ventas eso seria un solo sif

tpvs:

serie numero
tv1 1
tv2 2
tv3 3

3 usuarios trabajan directamente con el servidor y crean 3 facturas de ventas
serie numeracion
tv 1 (usuario1)
tv 2 (usuario2)
tv 3 (usuario3)


nº total de sif= 3(tpvs)+1=4


Siguiendo este esquema cada sif encadena los registros por id de creacion en la bd.

es correcto?

Sí, lo veo correcto.

Rectifico este punto, "Yo creo que el campo IdSistemaInformatico es el que indica el SIF del que proviene la factura" por este otro
Yo creo que el campo "NumeroInstalacion" junto con el campo "IdSistemaInformatico" son los que indican el SIF del que proviene la factura

Al clikar sobre 35609 me lanza al post 1

Seguramente sera referencia. Puedes indicar la correcta

En este último caso, en efecto habría que saber si fue un error "en el envío" o si efectivamente fue rechazada por Hacienda (la recibió pero la rechazó).
Si el error es en el envío, obviamente habría que reintentar el envío. Si fue rechazada por Hacienda (está enviada pero la rechazó por algún error), habría que enviar subsanación.

Correcto?

Hay que hacer muchas pruebas de todo tipo para entender el funcionamiento al 100%, y aún así seguro que algún caso concreto se me escapa...

Creo que es la mejor (o única) forma de hacerlo, y mostrar un mensaje en pantalla al usuario para que sepa lo que tiene que hacer y por qué. Con TicketBAI olvidamos esta parte y no hacían más que llamarnos para preguntar "qué hacemos ahora". Y luego nosotros a rebanarnos el coco, primero intentando averiguar qué hicieron y después para decirles cómo corregir cada caso.

Sin duda lo mejor es dejarlo todo masticadito a los usuarios para evitarnos dolores de cabeza más tarde.

Hola, buenos dias, ya lo he comentado con anterioridad, pero si solucionas la incidencia y reenvias, sin marcar que es reenviada tras rechazo (Subsanacion), ni nada, la acepta ok, sin mas, no se si sera que no lo estan controlando al ser el servidor de prueba, o realmente no lo estan teniendo en cuenta de ninguna forma, no se creo que el servidor tendria que tenerlo en cuenta y responder algo asi como aceeptada la "Reparacion " o parecido, para saber que lo han tenido en cuenta...

Estoy intentado acceder al XSD mostrado abajo y Siempre me lanza ERROR 404. Alguien puede confirmar si han cambiado el acceso. ???

https://www2.agenciatributaria.gob.e...nformacion.xsd


Página web no encontrada o recurso inexistente.

Puede contactar con el servicio de atención al contribuyente indicando el código de error 404.

la página principal tampoco funciona, deben de estar cambiando cosas
https://www.agenciatributaria.es/AEA...ERI_FACTU.html

Esta es la nueva dieccion:

Buff. Si reenvías que encadenamiento sigues si no pones que es subsanacion? Veo lagunas también en la fecha hora de reenvío que puedes tener un aviso de que la has enviado fuera de hora. Si ya han pasado 12p segundos te la acepta con incidencias y si lempones la hora actual no estás enviando wn orden cronológico.

Muchas gracias por la información
Una pregunta, ha desaparecido todo lo referente a SOAP? o no lo encuentro el wsdl

Lo tienes en la pagina, te lo pongo:

Pero antes se podía acceder a SistemaFacturacionVeriFactu.sfSOAP1Client y ahora no (al cliente soap)