¿Cuando se empieza un nuevo encadenamiento?

[xevi]

Estandoe n el período de prueba, quiero "cambiar" y empezar un encadenamiento nuevo...
He intentado cambiar
sum1:NombreSistemaInformatico
sum1:IdSistemaInformatico
sum1:Version

Entiendo que la versión NO debería de cambiar el encadenamiento y volver a empezar con registro huella anterior vacía.
PERO... si cambio de NombreSistemaInformatico o de IdSistemaInformatico, lo lógico sería enviar el primer registro con huella anterior vacía y de ahí empezar a encadenar los registros enviados... Pero no, no funciona y devuelve el error de registro duplicado si se trata de un registro que anteriormente el OT ha enviado con un Nombre o IdSistema, sea el que sea.

Habeis probado????

[delphiGar]

Lo que identificas al Registro de Facturacion (RF ) es el IDFactura = IDEmisor + NumSerieFactura + FechaExpedicion, eso seria su indice tanto para Altas como Anuladas, si envias la factura FACT0001 con un OT y despues con un distinto OT no te dara duplicado, a no ser que este la factura en ese nuevo OT.

Lo demas que quieras cambiar no hace diferente al Registro en cuanto a la referencia del Registro de Facturacion.

[xevi]

Igual me cuesta explicar el caso.

Envio la factura 1, 2 y 3, con un OT y NombreSistemaInformatico e IdSistemaInformatico
La factura 1 con huella nterior vacío y las demás encadenadas.

Ahora pongamos el caso que en la factura 4 quiero empezar de nuevo el encadenamiento, por lo que si cambio NombreSistemaInformatico o de IdSistemaInformatico debería de empezar otro encadenamiento, lógico, no???

Imaginemos que este OT tiene mi programa NombreSistemaInformatico o de IdSistemaInformatico y mi serie es la 1, 2, 3, 4...
Puede tener otro SIF qcon otra nuemración de facturas como 90001, 90002, 90003...

Ahí és donde quiero llegar.
Que campo debo cambiar para que entienda que se trata de otro encadenamiento???

[delphiGar]

Si quieres puedes empezar a encadenar desde cero, sin problemas, pero lo de registro duplicado te va a seguir saliendo, que es lo que te estaba diciendo. Aunque cambies el Sistema informatico no implica que empiezes de cero el encadenamiento, al contrario deberias seguir el mismo encadenamiento para ese OT + Serie + FechaExpedicion. Si lo haces con otras serie y con otro sistema informatico distinto puedes empezar de nuevo el encadenamiento.

[sglorka]

Para un mismo OT, el encadenamiento se resetea, comienza desde cero, cuando cambia alguno o todos los valores de los campos, <NombreRazon>, <NIF>,<NombreSistemaInformatico>, <IdSistemaInformatico> y <NumeroInstalacion> dentro del nodo <SistemaInformatico>
Cuando esto ocurre, el sistema admite que envíes el primer registro sin encadenamiento, pero eso no quiere decir que hayan desaparecido las facturas registradas con otros valores para el nodo <SistemaInformatico>, figurarán como cadenas diferentes, como dice DelphiGar, la clave de cada factura para un OT es IDEmisor + NumSerieFactura + FechaExpedicion esté en la cadena que esté.

[seccion_31]

Empezado por delphiGar

Si quieres puedes empezar a encadenar desde cero, sin problemas, pero lo de registro duplicado te va a seguir saliendo, que es lo que te estaba diciendo. Aunque cambies el Sistema informatico no implica que empiezes de cero el encadenamiento, al contrario deberias seguir el mismo encadenamiento para ese OT + Serie + FechaExpedicion. Si lo haces con otras serie y con otro sistema informatico distinto puedes empezar de nuevo el encadenamiento.

si unicamente se cambia la version del sistema informatico, por una actualizacion, entiendo que hay que seguir el encadenamiento.

Saludos !

[espinete]

Me surge una duda ahora con respecto a esto...

Había pensado poner en el campo "NumeroInstalacion" el código de "licencia" del software que tiene el cliente, pero claro, cada PC tiene un código distinto, aunque sea la misma empresa/cliente.

Si lo dejo así, significa que cada PC del mismo cliente tendrá su propio encadenamiento, y no es lo correcto.
Más bien el NumeroInstalacion debería ser un identificativo que identifique a cada cliente/empresa, no a cada PC? independientemente del número de PCs que tenga registrando ventas.

Es así, o me he liado?

[bmfranky]

Empezado por espinete

Me surge una duda ahora con respecto a esto...

Había pensado poner en el campo "NumeroInstalacion" el código de "licencia" del software que tiene el cliente, pero claro, cada PC tiene un código distinto, aunque sea la misma empresa/cliente.

Si lo dejo así, significa que cada PC del mismo cliente tendrá su propio encadenamiento, y no es lo correcto.
Más bien el NumeroInstalacion debería ser un identificativo que identifique a cada cliente/empresa, no a cada PC? independientemente del número de PCs que tenga registrando ventas.

Es así, o me he liado?

Hola, depende de la forma en que encadena los registros.


Si cada pc, es el que emite las facturas y encadena, tiene que tener su propio numero de instalacion independiente y cadena propia, para diferenciar cada una de las instancias


Pero, si el que encadena, es un gestor unificado,( por ejemplo cajas que piden el numero de factura/ticket a un servidor central y este es el que encadena y envia los registro), te da lo mismo, puesto que el que encadena y asigna todo es el servidor.


Lo que hay que tener claro, es que cada SIF, que envia a la aeat, tiene que tener una identificacion unica, basandose en los datos del Sistema informatico.


Asi que analizando.


<NombreRazon> Sera el mismo para todos los sif de un mismo O.T.


<NIF> Es el mismo, tambien.


<NombreSistemaInformatico> Podria variar , pero asumiremos que todos son el mismo.


<IdSistemaInformatico> Lo mismo, si actualizamos los programas del cliente, todos deverian ser el mismo.


Entonces solo nos queda 2 formas para distinguir los registros de facturacion.


1 -> La Serie de facturacion + el numero de factura, que deverian ser diferentes, aunque no es necesario, por ejemplo cada sede podrian emitir FV250000xxx. Sin problemas, puesto que cada SIF encadena independiente, aunque yo veo mas logico , diferenciar la caja/programa/etc a la hora de hacer alguna rectificacion., abono y demas, ademas que emitir un mismo cif varias facturas, con el mismo numero/serie,no creo que sea muy legal.
Ademas que en el encadenamiento aparte de las facturas, tambien se encadenan los abonos, rectificativas, anulaciones, etc...


2 -> El <NumeroInstalacion> que deve ser , si os si, diferente para cada encadenamiento de un mismo tributario/CIF/NIF, porque es la forma que tendria la AEAT, de identificar unequivocamente , que instancia /parte/usuario(Decidlo como querais), en una empresa, es la que ha cometido , el fallo o demas, por ejemplo se me ocurre el ipotetico caso que en una inspeccion se encuentre alguna anomalia en la facturacion y el inspector quiera hablar directamente con el usuario que uso ese numero de instalacion, para crear ese registro, si, lo se es muy rebuscado, pero podria pasar...

[espinete]

Voy a tener que analizar esto con calma, porque nuestro software de escritorio admite varias configuraciones.

Ejemplo 1: comercio con 3 ordenadores:
- Base de datos unificada (un servidor y 2 clientes).
- Los 3 equipos facturan al mismo tiempo, obviamente con facturas correlativas.
- Cada PC emite facturas. Cada PC hace el envío de las facturas que se hagan en él, pero se guardan todas en el servidor, que es donde está la única base de datos a la que se conectan los demás.

Ejemplo 2: franquicia con 3 tiendas y 3 ordenadores cada una.
- Cada tienda usa su propia facturación, independiente de las otras dos tiendas
- Cada tienda, por separado, funcionaría como el Ejemplo 1

Cada tienda debería usar la misma enumeración correlativa de las facturas, así que NumeroInstalacion debería ser algo como "ClienteXTiendaX".
Es decir, donde haya un encadenamiento (o enumeración de facturas) propio, debe ser un NumeroInstalacion propio.

A ver como lo implemento en el software, porque ahora mismo no tenemos nada que identifique a cada tienda. Solo a cada Cliente/Empresa y cada PC.
Como cada tienda tiene su "servidor", supongo que usaremos algo que identifique a ese servidor.