|
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 |
Cita:
Gracias sglorka, A mi primer fichero le calculo la huella y es el que tengo que subir a Hacienda, correcto? |
Hola.
Cita:
Muchas Gracias. |
Cita:
|
Cita:
En ella te establece claramente que la huella sale del nodo RegistroFacturacion |
Cita:
Sí, sí...era una manera de hablar ^\||/ |
Cita:
Muchas Gracias. |
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. |
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. |
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. |
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
|
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" :cool::D:D 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" :rolleyes:. 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. |
yo espero que Verifactu sea como ticketbai, como el ejemplo tal cual que ha puesto Neftali
|
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. :o 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? |
Cita:
En el caso de TicketBAI no existe esa posibilidad. Creas una nueva y la subes. |
Cita:
|
Gracias Neftali. Parece que era lo obvio que funcionara así, de lo contrario sería un desastre
|
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á. |
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í.:) |
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. |
Cita:
Reglamento de facturación Artículo 11. Plazo para la expedición de las facturas. 1. Las facturas deberán ser expedidas en el momento de realizarse la operación. No obstante, cuando el destinatario de la operación sea un empresario o profesional que actúe como tal, las facturas deberán expedirse antes del día 16 del mes siguiente a aquél en que se haya producido el devengo del Impuesto correspondiente a la citada operación. O sea, yo puede ir realizando notas de entrega a un cliente empresario durante el mes de marzo y después emitirle una factura resumen de esas operaciones antes del 16 de abril. Como debo respetar la numeración correlativa y las fechas de expedición de forma ascendente, estando a día 16 de abril emito una factura resumen de operaciones con fecha 17 de abril (no tengo facturas emitidas después del 16 de abril ). Le envío la factura al cliente y me responde al día siguiente reclamándome que la fecha de factura es errónea. Ahora ¿Cómo lo soluciono? ¿ Emito una rectificativa con fecha 17 de abril, día en el que estoy ? no debería por que sigo sin resolver el problema. Lo que debo hacer es emitir una rectificativa por sustitución con fecha de emisión 16 de abril, para corregir la factura errónea. En resumen, hay que respetar la cronología NumeroFactura-FechaExpedición pero como pueden haber errores, se debe poder rectificarlos, es lo que subyace en el reglamento cuando crea la factura rectificativa, eso si, sin intentar torcerlo. Si yo sé que no tengo facturas emitidas hoy ni las voy a emitir. ¿ qué problema hay en emitirlas hoy con fecha del día siguiente? Te adjunto link de consulta vinculante realizada a la administración donde se recoge el caso de la emisión de una factura rectificativa por error en fecha de expedición. https://www.iberley.es/resoluciones/...4-2022-1538919 |
Cita:
|
Cita:
fecha de emisión correcta cuando la fecha de emisión fue incorrecta en primera instancia. El apunte que haces respecto de no poder emitir facturas con fecha anterior a una factura ya emitida es cierta ya que debemos mantener una cronología entre número de factura y fecha de emisión. Pero debes tener en cuenta que cuando se trata de una factura rectificativa, herramienta creada para poder solventar errores en las facturas emitidas, no debería extrañarte que existiera la posibilidad de rotura de esta cronología. Además, ten en cuenta que la OM en ningún momento habla del control de las fechas de expedición de facturas, sólo habla de momento en el que se realiza el fechado del registro de facturación f) En cualquier caso, el obligado tributario usuario del sistema informático deberá asegurarse de que la fecha y hora empleadas por dicho sistema informático para fechar los registros de facturación son exactas, con un margen máximo de error admitido de un minuto. 2.º La fecha y hora de generación del último registro de facturación generado no es superior en más de un minuto a la fecha y hora actuales que se utilizarán para fechar el registro de facturación a generar por lo que da a entender que se está refiriendo a los campos FechaGenRegistro, HoraGenRegistro y HusoHorarioGenRegistro del objeto RegistroFacturacion y no del campo FechaExpedicionFacturaEmisor del objeto IDFactura del objeto RegistroFacturacion De todas maneras, todo esto que hablamos lo podremos probar cuando habiliten el endpoint de recepción de facturas. ¿ Que no te permite que la fecha de expedición sea distinta que la fecha actual ?, pues ya sabes a qué atenerte, no puedes dejar libre el campo fecha emisión en tus facturas por que no vas a poder rectificarlas si se equivocan. |
En cuanto al fichero individual de la factura, no el que se subirá luego a Hacienda
Rellenamos el campo HoraGenRegistro con la hora real de creación pero pasará algo si la subida a la AEAT se hace dentro de 10 minutos así lo han requerido? |
Cita:
|
comando curl fecha/hora
Aquí os dejo un comando curl para los que querais asegurar la fecha y hora de sistema esten correctas antes de cada factura, ya que si lo dejais en mano de windows algún listillo puede desactivar la sincronización.
Ya lo habia subido anteriormente pero el anterior ejemplo tenia en cuenta la zona horaria de la ip y me a hecho alguna putada, ésta es la correcta: Código PHP:
|
Cita:
|
Calculo de la Huella
Cita:
¿ Donde puedo hacer la prueba para ver si la huella que genero es correcta ? |
Buenas,
cómo se calcula la huella del registro de facturación actual antes de enviarlo por GetsfSOAP ? Muchas gracias |
Cita:
-No puedes quitar ningún caracter, ni espacios, ni tabuladores, ni saltos de linea ni retornos de carro, ni ningún otro caracter especial que esté incluido entre esas 2 etiquetas. -Para hacer pruebas en alguna web hay que tener en cuenta que los caracteres especiales a veces no se pegan correctamente, con lo cual puedes copiar el nodo en otro fichero para hacer la prueba desde fichero en vez de copiar y pegar, pero recuerda que un salto de línea, por ejemplo después del último caracter, te va a cambiar totalmente el cálculo de la huella (sha256). -La duda quedaría sí después de la etiqueta de cierre del nodo </sum:RegistroFacturacion>, hay un salto de línea o retorno de carro, ¿habría que cogerlos o no para el cálculo?, en este caso lo que algunos hemos hecho es pegar el inicio del siguiente nodo al final de este y quitar todos los caracteres que poudieran haber entre ambos y nos ahorramos esa duda. Cita:
https://hash.online-convert.com/es/generador-sha256 |
Cita:
Perdón por la pregunta, es probable que sea absurda pero solo consigo el XML cuando envío y capturo el evento HTTPRIO1BeforeExecute
|
Muchas gracias ermendalenda
|
Cita:
Por favor, ¿Cómo y de donde me puedo descargar la Orden Ministerial (OM)? |
Cita:
|
Hola a todos.
Vamos a empezar a trabajar en esto de verifactu. Ya hemos desarrollado para TicketBAI, así que el cambio no es tan grande. Lo primero que veo es que hacienda ha lanzado todo esto pero lo tiene un poco verde, al menos la información que tenemos, seguramente hay algunas empresas (las de siempre, ya ha pasado en otros desarollos) que tienen más información. He estado leyendo el foro, y veo que hay un poco de dudas sobre la fecha de factura, según TicketBAI (Hacienda te dice que también según el reglamento de facturación), la fecha de factura tiene que ser igual a la fecha del día que se genera, ni antes ni después. Hemos tenido varias discusiones con clientes y hacienda y eso es lo que te contestan. De hecho los programas que han hecho en hacienda para los que hacen pocas facturas no se puede modificar la fecha de factura, otra cosa es la fecha de operación. Una consulta muy recurrente que hacían los clientes es, Es que yo hago las facturas el viernes con fecha del lunes para así tenerlas preparadas, pues no se puede. Nosotros lo que hacemos es generar una prefacturación y luego el día que quiere hace las facturas, pero siempre con la fecha del día que se genera las facturas. Una diferencia que he encontrado respecto a TicketBAI y el SII es que no hay que indicar si el desglose es a nivel de factura o a nivel de operación. Me imagino que por eso las empresas que hacen el SII no tiene por que hacer todo esto. En las Haciendas forales es al revés, el que entra en TicketBAI ya no tiene que enviar las facturas emitidas al SII. Otra diferencia que veo es que las anulaciones hay que tenerlas en cuenta en el encadenamiento de las facturas, en TicketBAI. Me llama la atención toda la información que hay que enviar del sistema informático. También veo que respecto a TicketBAI el mayor cambio y del cual no hay mucha información es el tema de los eventos. Entiendo que todo esto es por no obligar a todo el mundo a entrar en VErifactu, como han hecho en las forales que todo el mundo (salvo pocos casos) tienen que entrar en TicketBAI. |
Último día de consulta del proyecto de la OM
Hola, me han recomendado enviar una consulta para "quejarse" de las restricciones sobre los certificados de envios. Que va a ser un gran problema.
Por si quereis y os interesa quejaros, hoy es el último día para quejarse: [email protected] |
Cita:
Nosotros tenemos algo hecho, pero más que nada en pruebas. Hay muy poca información, la que hay es muy poco concreta, nada donde se pueda probar,... Yo creo que para hacer algo "es serio" no sirve. Sí para ir probando cosas sueltas. Cita:
|
Cita:
|
Cita:
Gracias por avisarnos, Ermendalenda. Acabamos de enviar email con el texto: Cita:
Saludos |
Cita:
Perfecto. Gracias a tí |
| La franja horaria es GMT +2. Ahora son las 07:29:05. |
Powered by vBulletin® Version 3.6.8
Copyright ©2000 - 2026, Jelsoft Enterprises Ltd.
Traducción al castellano por el equipo de moderadores del Club Delphi