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)