|
|
 |
 |
|
FTP | |
|
CCD | |
|
Buscar | |
|
Trucos | |
|
Trabajo | |
|
Foros | |
|
|||||||
| Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Temas de Hoy |
 |
|
|
Herramientas | Buscar en Tema | Desplegado |
|
#1161
17-01-2024
|
|||
|
|||
|
Cita:
este fichero Xml <?xml version="1.0" ?> <AltaFactuSistemaFacturacion xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema"> <Cabecera xmlns="https://www2.agenciatributaria.gob.es/static_files/common/internet/dep/aplicaciones/es/aeat/tike/cont/ws/SuministroInformacion.xsd"> <IDVersion>1.0</IDVersion> <ObligadoEmision> <NombreRazon>EMPRESA SL</NombreRazon> <NIF>NIF</NIF> </ObligadoEmision> <TipoRegistroAEAT>T0</TipoRegistroAEAT> </Cabecera> <RegistroAltaFacturas xmlns="https://www2.agenciatributaria.gob.es/static_files/common/internet/dep/aplicaciones/es/aeat/tike/cont/ws/SuministroLR.xsd"> <RegistroFacturacion> <IDFactura xmlns="https://www2.agenciatributaria.gob.es/static_files/common/internet/dep/aplicaciones/es/aeat/tike/cont/ws/SuministroInformacion.xsd"> <IDEmisorFactura> <NIF>NIF</NIF> </IDEmisorFactura> <NumSerieFacturaEmisor>3</NumSerieFacturaEmisor> <FechaExpedicionFacturaEmisor>16-01-2024</FechaExpedicionFacturaEmisor> </IDFactura> <NombreRazonEmisor xmlns="https://www2.agenciatributaria.gob.es/static_files/common/internet/dep/aplicaciones/es/aeat/tike/cont/ws/SuministroInformacion.xsd">EMPRESA SL</NombreRazonEmisor> <TipoRegistroSIF xmlns="https://www2.agenciatributaria.gob.es/static_files/common/internet/dep/aplicaciones/es/aeat/tike/cont/ws/SuministroInformacion.xsd">S0</TipoRegistroSIF> <TipoFactura xmlns="https://www2.agenciatributaria.gob.es/static_files/common/internet/dep/aplicaciones/es/aeat/tike/cont/ws/SuministroInformacion.xsd">F1</TipoFactura> <DescripcionOperacion xmlns="https://www2.agenciatributaria.gob.es/static_files/common/internet/dep/aplicaciones/es/aeat/tike/cont/ws/SuministroInformacion.xsd">VENTAS</DescripcionOperacion> <Destinatarios xmlns="https://www2.agenciatributaria.gob.es/static_files/common/internet/dep/aplicaciones/es/aeat/tike/cont/ws/SuministroInformacion.xsd"> <IDDestinatario> ... es el que tienes que construir sacando la huella del nodo <RegistroFacturacion> <IDFactura xmlns="https://www2.agenciatributaria.gob.es/static_files/common/internet/dep/aplicaciones/es/aeat/tike/cont/ws/SuministroInformacion.xsd"> <IDEmisorFactura> <NIF>NIF</NIF> </IDEmisorFactura> <NumSerieFacturaEmisor>3</NumSerieFacturaEmisor> <FechaExpedicionFacturaEmisor>16-01-2024</FechaExpedicionFacturaEmisor> </IDFactura> <NombreRazonEmisor xmlns="https://www2.agenciatributaria.gob.es/static_files/common/internet/dep/aplicaciones/es/aeat/tike/cont/ws/SuministroInformacion.xsd">EMPRESA SL</NombreRazonEmisor> <TipoRegistroSIF xmlns="https://www2.agenciatributaria.gob.es/static_files/common/internet/dep/aplicaciones/es/aeat/tike/cont/ws/SuministroInformacion.xsd">S0</TipoRegistroSIF> <TipoFactura xmlns="https://www2.agenciatributaria.gob.es/static_files/common/internet/dep/aplicaciones/es/aeat/tike/cont/ws/SuministroInformacion.xsd">F1</TipoFactura> <DescripcionOperacion xmlns="https://www2.agenciatributaria.gob.es/static_files/common/internet/dep/aplicaciones/es/aeat/tike/cont/ws/SuministroInformacion.xsd">VENTAS</DescripcionOperacion> <Destinatarios xmlns="https://www2.agenciatributaria.gob.es/static_files/common/internet/dep/aplicaciones/es/aeat/tike/cont/ws/SuministroInformacion.xsd"> <IDDestinatario> ... </RegistroFacturacion> el otro código que has puesto Código PHP:
es el archivo xml que has creado envuelto en el protocolo soap para que "viaje" hasta el servidor de aeat 
|
|
#1162
17-01-2024
|
|||
|
|||
|
Cita:
Gracias sglorka, A mi primer fichero le calculo la huella y es el que tengo que subir a Hacienda, correcto?
|
|
#1164
17-01-2024
|
|||
|
|||
|
Cita:
|
|
#1165
17-01-2024
|
|||
|
|||
|
Cita:
En ella te establece claramente que la huella sale del nodo RegistroFacturacion
|
|
#1166
17-01-2024
|
|||
|
|||
|
Cita:
Sí, sí...era una manera de hablar 
|
|
#1168
17-01-2024
|
|||
|
|||
|
Cita:
Cuando creas una factura, la encadenas. Este registro tiene código S0 en el campo TipoRegistroSIF Si hay un problema de NIF o de IVA o cosa similar con esta factura, y se debe modificar algo, creas otro registro con la misma identificación (número de factura y fecha) pero código S1 en el campo TipoRegistroSIF. Dado que es un registro distinto, tiene otra huella y está encadenado en su sitio (orden temporal), independientemente del primero registro. Este segundo registro se debe subir independientemente a la AEAT. Si luego tienes que anular la factura, será otro registro, esta vez de tipo S2 y con un contenido diferente en el XML, registro que se debe subir por un webservice diferente. Y para cerrar el circulo, teóricamente también puedes modificar el registro de anulación, será otro registro esta vez con tipo S3, que también sube por el segundo webservice. Al final, cada vez que con una factura se hace una operación (crear, modificar, «borrar»), se crea un nuevo registro de facturación; este registro debe ser encadenado en su sitio, con las informaciones relevantes de la factura en este momento. Y luego no se toca nunca más.
|
|
#1169
17-01-2024
|
|||
|
|||
|
Cita:
Estás suponiendo que el primer registro S0 te lo ha aceptado, y la suposición (creo que es así... ya veremos ) es que no te lo va a aceptar por un error en el NIF (mal informado) o por un tipo de IVA inexistente. Entonces ocurre que el siguiente registro que quieres enviar está encadenado con el registro rechazado y al enviarlo te va a dar error de encadenamiento ya que el servidor no tiene ese registro anterior en su sistema. El registro S1 sólo se debe crear si el/los dato(s) a corregir no implican la creación de una factura rectificativa. Si el error es de un tipo de iva inexistente, o un nif mal informado, entonces hay que emitir una factura rectificativa por sustitución, o sea, otro registro S0. El registro S1 corrige un registro S0 aceptado pero que tiene algún dato mal (como por ejemplo el régimen de tributación ). En definitiva, la duda es cómo debemos resolver el encadenamiento de los registros de facturación posteriores al rechazo de un registro anterior.
|
|
#1170
17-01-2024
|
|||
|
|||
|
Cita:
Si te sigo bien, tenemos lo siguiente:
Lo único que podemos esperar es que los controles para pasar R2 al estado "AcceptadaConErrores", que sí permite reconocer el encadenamiento (creo), sigan lo más básico posible; es decir, poco más que controlar que el XML es descifrable y luego que la huella anterior es la esperada dado el SistemaInformatico indicado (o parte de). Y desde luego que se publiquen normas claras al respecto.
|
|
#1171
18-01-2024
|
|||
|
|||
|
Perdonad la ignorancia pero este tema que comentáis antoine0 y sglorka no está resuelto en Ticketbai?, pensaba que se habían basado en este sistema y entiendo en la experiencia que ya hay sobre él para la implantación y todos estos problemas de encadenamiento por ejemplo ya estaban más que pensados por Hacienda. En el momento que salga el Reglamento Técnico creo que es cuando van a desvelarse muchas dudas. Saludos
|
|
#1172
18-01-2024
|
||||
|
||||
|
Cita:
Cita:
Lo primero es que una factura en la cual falla el encadenamiento es "ACEPTADA CON ERRORES"; Es decir, una factura que lleva el encadenamiento mal no se rechaza. Hay situaciones en las que se puede dar esta situación. Algunas son correctas (por ejemplo, cambio de serie al final del año) y otras por situaciones inesperadas (backup/restore después de un error). Lo que es posible que hacienda te pida explicaciones de porqué se ha roto ese encadenamiento y tengas que justificarlo. Seguramente si tienes 3 errores de encadenamiento en un año no se molesten, pero si cada semana estás enviando "roturas" de encadenamiento te llamarán para saber "qué estás haciendo"   Por otro lado, que una factura sea RECHAZADA, no significa que hacienda no se quede con información de ella. Por ejemplo, yo he creado estas 3 facturas:  Las tres van encadenadas de forma consecutiva y de esta forma: viz 2 --> viz 3 err --> viz 4 La primera ACEPTADA (viz 2), la segunda está RECHAZADA (viz 3 err) encadenada con la anterior y la tercera al enviarla está ACEPTADA (y está encadenada con la segunda, que está RECHAZADA). No hay error de encadenamiento, porque yo las he encadenado bien. Como la segunda está RECHAZADA, tendré que corregirla o realizar una rectificativa y volver a enviarla por los cauces que me digan (en el caso de TicketBAI hay diferentes formas según la tribitación). Lo que quiero decir es, que aunque la segunda esté rechazada (eso es a posteriori), sí que entra en el encadenamiento. Ahora mismo la factura no es válida (por el error que sea), pero hacienda sí que se ha quedado con información se esa factura (como debe ser). Porque lo que no vale ahora es decir, "como está RECHAZADA, la borro en mi sistema y la creo nueva"  . Hay arreglar esa que ya has enviado.Hay situaciones en las que sí se puede BORRAR una factura (ANULACION) pero son casos especiales. Una factura, aunque esté RECHAZADA no se puede BORRAR. Hay que corregirla y enviarla de nuevo o rectificarla, según el caso. Espero haber aclarado algo.
__________________
Germán Estévez => Web/Blog Guía de estilo, Guía alternativa Utiliza TAG's en tus mensajes. Contactar con el Clubdelphi  P.D: Más tiempo dedicado a la pregunta=Mejores respuestas. Última edición por Neftali [Germán.Estévez] fecha: 18-01-2024 a las 08:49:47.
|
|
#1174
18-01-2024
|
|||
|
|||
|
Cita:
Una pregunta (relacionada pero distinta) me queda, sobre estos casos especiales. En el caso que una factura siga enviada (estado S0 en SIF) y luego anulada (estado S2 en SIF), ¿es posible «resucitarla»? Es decir, cancelar la anulación y recuperar esta factura como legítima y válida. El caso más habitual es el caso de una factura anulada por algún bug en el programa.  En el SII, funciona enviando una transacción A1 sobre la factura dada de baja; así que por paralela, sería encadenar y enviar un registro de rectificación (estado S1 en SIF) con todos los datos sobre la factura que era últimamente marcada borrada. ¿Este caso existe en TicketBAI?
|
|
#1175
18-01-2024
|
||||
|
||||
|
Cita:
En el caso de TicketBAI no existe esa posibilidad. Creas una nueva y la subes.
__________________
Germán Estévez => Web/Blog Guía de estilo, Guía alternativa Utiliza TAG's en tus mensajes. Contactar con el Clubdelphi P.D: Más tiempo dedicado a la pregunta=Mejores respuestas.
|
|
#1178
18-01-2024
|
||||
|
||||
|
Cita:
Factura nueva, número distinto. Pero creo que eso no tiene que ver con TicketBAI sino con la ley de facturación. La ley de facturación especifica unos casos muy concretos para poder ANULAR una factura. Lo habitual y lo correcto es RECTFICARLA si hay errores. Pero si en algún caso DEBES anularla, entiendo que no puedes repetir en número. En ese caso deje un "hueco" y si es necesario justificas la anulación (con las razones pertinentes). NOTA IMPORTANTE: No soy experto en temas legales así que por favor si alguien ve que esto es incorrecto que lo comente. A mi personalmente no se me ocurriría repetir y menos si esa factura debe subir luego a algún sitio (SII, TBAI, VERI*FACTU,...). Crep que va a generar más posibles problemas, que no justificar la anulación y el "hueco". Nosotros en TBAI lo hacemos así: 1) Creo la factura con numero 3000 2) Creo la factura con número 3001 3) Anulo la factura con número 3001 4) La siguiente que creo coge el número 3002 ... Eso en TBAI no da ningún problema. Si te piden el porqué de la anulación se justifica y ya está.
__________________
Germán Estévez => Web/Blog Guía de estilo, Guía alternativa Utiliza TAG's en tus mensajes. Contactar con el Clubdelphi P.D: Más tiempo dedicado a la pregunta=Mejores respuestas. Última edición por Neftali [Germán.Estévez] fecha: 18-01-2024 a las 12:08:33.
|
|
#1179
18-01-2024
|
|||
|
|||
|
Cita:
En el S.I.I. estamos apañando la subida de un número grande de facturas hasta Hacienda. Por tanto el sistema debe gestionar casos complejos de comunicación de sistemas; y si me han pasado unos casos de facturas que he tenido que anular en el S.I.I., han sido por causas relacionadas con bien el sistema de facturación bien la aplicación SII; y cuando hay un bug en una de los dos, pues resulta ser un problema. En los SIF, igualmente que en TicketBAI, no debe ocurrir «tantos» problemas de anulación por qué debe haber muy pocos casos de anulación y todos tienen que ver con el sistema de facturación. La subida a Hacienda no puede generar problemas dado que lo que se sube es lo que hay en la cadena dentro del SIF, no es una elaboración hecha a posteriori (como sí es el caso del SII en todos los casos donde el SII se ha añadido a un sistema existente; aquí está a mi juicio la razón). Dónde tienes razón es que los casos de anulación (registros tipo S2+S3 en el SIF, uso del webservice BajaFactuSistemaFacturacion) deben ser estrictamente los enunciados en las normas de aplicación del reglamento de facturación (el reglamento en sí no contempla esta oportunidad). Cita:
Y pasa que cuando descubren una función de anulación, les parece puede apañar problemas que han tenido, digamos que el ratón se ha ido al mal sitio o el ordenador ha presionado la mala tecla o el café se ha vertido o cualquier razón me inventen (son muy ricos en eso), y resulta que les parece bien anular la factura sin pensar en cosas «informáticas» que les parecen chino austral. Y luego vendrán a pedir que se les arregle el programa de [censurado] que no funciona bien porqué no saber pasar la factura que se ha entregado al cliente. ¿Os suena de algo? Y no me digáis que la función tiene que ser reservada al administrador o al supervisor: los supervisores también pueden tener ideas parecidas (o solo para dar la razón a los usuarios) si les parece razonable hacerlo, sin tener en cuenta las dichosas razones informáticas... Entonces sí debe ser reservada y/o tener doble validación, por supuesto que sí, pero esto no resultará ser una protección suficiente. Dicho esto, si anulan una factura, la factura quedará como anulada en el SIF y no se podrá «rescatar» o «resucitar» el número. Un problema menos para mí. 
|
|
#1180
18-01-2024
|
|||
|
|||
|
Cita:
Entiendo que si has expedido una factura con una fecha incorrecta, puedes emitir una rectificativa por sustitución para subsanar el error. Pero creo qué la fecha de expedición de esta rectificativa será la fecha efectiva que se realice la rectificación, no la fecha que debería haber sido puesta en la factura inicial. Concretamente en el reglamento, el artículo 15.5 dice que la factura rectificativa deberá cumplir los mismos requisitos que cualquier factura; y no he visto nada que hable de fechas de expedición distinta de la fecha en la cual se expide una factura. (Otras cosas distintas son la fecha de devengo del IVA, o sea la fecha o el periodo de liquidación; y evidentemente está también la fecha de operación, que es un campo distinto y va por sus propias normas, y en el caso de la rectificativa aquí pondría la fecha de la operación inicial; pero estas fechas no son parte de los identificadores de una factura). Por tanto no veo como una factura en un SIF puede llevar una fecha de expedición que difiere de la fecha del registro S0. NOTA IMPORTANTE: Igual que Neftali tampoco soy experto en temas legales así que por favor si alguien ve que esto, o el anterior, es incorrecto que lo comente.
|
|
|
|
Temas Similares
|
||||
| Tema | Autor | Foro | Respuestas | Último mensaje |
| Hijo de Informáticos | gluglu | Humor | 3 | 13-03-2007 11:05:35 |
| Adictos informaticos ... | Trigger | Humor | 2 | 11-10-2004 12:18:32 |
| Nosotros los Informáticos | Trigger | Humor | 1 | 10-10-2004 14:58:09 |
| Patrón de los Informáticos. | obiwuan | Varios | 20 | 10-09-2003 14:44:54 |
| Chistes Informaticos | jhonny | Humor | 2 | 11-08-2003 21:59:09 |
 |
|
![Avatar de Neftali [Germán.Estévez]](image.php?s=545198e21d58400c91ec1025a7f7f659&u=3561&dateline=1185205509)
Mode Lineal
