![]() |
Cita:
Saludos |
Cita:
Cita:
Correcto. Son los mismo que hay en el primer hilo. |
Política de firma y digest
Respuesta Batuz a pregunta ya publicada:
Kaixo, "Efectivamente falta notificar la huella digital y el algoritmo a utilizar correspondiente al PDF de la política de firma. La huella digital correspondiente al fichero de política de firma TicketBAI_Política_firma_v_1_0.pdf (http://ticketbai.eus/politicafirma/) con el algoritmoSHA256 es: 3LuO0ZhTfZWEDgrMYqknfgtYBbi++7pfrmcuoChOexU=. El algoritmo que le corresponde es el:http://www.w3.org/2001/04/xmlenc#sha256." Agur bat. Saludos |
Cita:
Un Saludo. |
Si te refieres a los documentos que hay al final de la página que las colocado:
https://www.gipuzkoa.eus/es/web/ogas...e-fiscal/t-bai ![]() Son los mismos que tenemos en el hilo inicial: ![]() Si los descargas y los comparas por fecha, tamaño y contenido, verás que son iguales. Si te estás refiriendo a otros, pon los links, por favor. |
Cita:
Un Saludo. |
Perdón no había visto la parte de Definitivo.
Mi culpa me fustigo. :D |
Últimas Preguntas/Respuestas que me han contestado desde (bizcaia):
===================================================== PREGUNTA 1: Una vez guardada una factura, generado y firmado el XML, ¿puedo modificar la factura para cambiar un dato que no sea relevante para el XML. Por ejemplo, el PISO de la dirección postal, el campo TELÉFONO,... (cualquier campo que no esté incluído en el XML)? ¿Si es que si, si vuelvo a imprimir esa factura, debe aparecer la palabra DUPLICADO? Remitimos esta pregunta al departamento de dudas fiscales ===================================================== PREGUNTA 2: SITUACIÓN: Pérdida de datos en un cliente. En este caso puede ser que la única solución sea restaurar copias de seguridad de la Base de Datos. Imagiunemos que restauro uina copia de seguridad y la última que tengo es de hace 2 días o una semana. Es decir, he perdido la información de varios días. PREGUNTA: ¿Qué pasa con las facturas que ya he generado y subido a TicketBAI? Si vuelvo a introducir estas facturas "manualmente" en el sistema, el XML generado será diferente al que he subido a ticketBAI. ¿Cómo resuelvo esta situación? ¿Deben llevar encadenamiento? ¿Cual? El caso, por ejemplo, de rotura de un dispositivo es una circunstancia justificada en la cual se producen dos consecuencias: Si no pueden recuperarse los ficheros xml TicketBAI expedidos por el dispositivo estropeado, la información correspondiente a esas operaciones debe remitirse a la Administración foral correspondiente de acuerdo con los canales que, para estas situaciones, se habiliten al efecto. Por otro lado, la rotura de un dispositivo es una circunstancia justificada para que la primera factura del nuevo dispositivo no cumpla el requisito de informar de la factura anterior ya que esta no existe. Es decir, en este caso se justifica el incumplimiento del requisito de encadenamiento. ===================================================== PREGUNTA 3: ¿La primera factura de una nueva serie cómo se "emite"? ¿Cómo se encadena? ¿O la primera factura de una nueva serie que acabo de crear no lleva encadenamiento con la anterior? En TicketBAI cada factura debe de identificar la factura anterior. El cumplimiento del requisito de encadenamiento depende de la forma de funcionamiento del sistema de facturación. Si un mismo dispositivo emite facturas de diferentes series, el requisito de encadenamiento debe identificar la factura anterior expedida, con independencia de la serie (por ejemplo, a una factura de una serie ordinaria le puede preceder una factura rectificativa de otra serie). No obstante, si existen diferentes dispositivos de facturación, los cuales sólo expiden facturas dentro de una serie específica para cada dispositivo, el encadenamiento se produce dentro de cada serie, ya que el sistema de facturación funciona de este modo. En cuanto a la primera factura que se expida cada año, esta sí que tiene que encadenarse con la última factura expedida en el año anterior. Es cierto que la normativa permite que un empresario, al inicio de un año, inicie series nuevas de numeración de sus facturas, teniendo en cuenta además que muchas empresas utilizan como elemento numerador de las facturas el año en que éstas se expiden. No obstante, este hecho no debe impedir el encadenamiento de la primera factura de un año con la última del año anterior, aunque sean de diferentes series por haberse utilizado el año como serie de la factura, si, por ejemplo, el dispositivo que emite las facturas en un año y en el otro es el mismo. Es decir, debe existir otra circunstancia que justifique la falta de identificación de la factura anterior en este caso (por ejemplo, primera factura de un dispositivo nuevo, rotura y sustitución de un dispositivo, etc.). ===================================================== |
Neftali [Germán.Estévez] gracias por compartirlo. ^\||/
Por cierto, ¿dónde comprobáis que los ficheros generados y firmados son correctos? Por ejemplo para facturae , para hacer pruebas, uso la herramienta web que tienen para ello. ¿Pero para esto de ticket bai? El último email me dijeron que no había aún ningún sistema de pruebas aún....Veo todo muy lento para las fechas que dan para ponerlo en marcha :rolleyes: |
Cita:
Se supone que en algún momento cada una de las administraciones publicará sus servicios, sean para pruebas o definitivos. |
Hola a todos Gipuzkoa ha publicado el calendario de implantación.
https://www.gipuzkoa.eus/es/web/ogas...generated-id-3 Por si fuera poco, hacienda de Bizkaia acaba de mandar un mensaje que a partir de año que viene va a implantar un nuevo modelo 240 y el 140 lo va a cambiar a servicios web, en los cuales hay que enviar estos ficheros generados en TICKET BAI. Un Saludo |
Cita:
Saludos |
Más que un 140 para emrpresas es un SII para todas las empresas, tiene los mismos libros y casi el mismo diseño. Y el 140 hacen que se parezca mas al SII.
|
Cita:
Y ya no será necesario enviar modelos puntuales de IVA ni de IS. Hacienda enviará el borrador para aceptarlo. Saludos. |
Cita:
¿ Hay que mandar la información que ya tienen ? En la reforma de la ley de Régimen Jurídico de las Administraciones Públicas y del Procedimiento Administrativo Común de Ley 30/1992 de ¡ 1992 ! ya se decía que la admón. no puede solicitar la información que ya posee. |
Cita:
|
Cita:
Ley 30/1992, de 26 de noviembre, de Régimen Jurídico de las Administraciones Públicas y del Procedimiento Administrativo Común. En su artículo 35.f, entre los derechos de los ciudadanos apunta el de "no presentar documentos no exigidos por las normas aplicables al procedimiento de que se trate, o que ya se encuentren en poder de la administración actuante". Ley 11/2007, de 22 de junio, de acceso electrónico de los ciudadanos a los servicios públicos. En su artículo 6, destinado al derechos de los ciudadanos, recoge el de "no aportar los datos y documentos que obren en poder de las administraciones públicas, las cuales utilizarán medios electrónicos para recabar dicha información", salvaguardando siempre la protección de datos del ciudadano en cuestión. Real Decreto 1671/2009, de 6 de noviembre, por el que se desarrolla parcialmente la ley 11/2007. En su artículo 2.1 recoge las reglas que deben cumplirse "cuando los ciudadanos ejerzan el derecho a no aportar datos y documentos que obren en poder de las Administraciones Públicas establecido en el artículo 6.2.b) de la Ley 11/2007". Fuente: http://www.legaltoday.com/blogs/tran...r-al-ciudadano |
Pues habrá que mandarlo a hacienda, pero ya sabemos quien manda.
|
Hola
No se esta mandando dos veces, es a través del 140 y 240 cuando realmente se comunica a la hacienda las facturas emitidas y con las reglas del TicketBai, además del resto de ingresos. También se comunican los gastos, de esta forma ellos pueden realizar una propuesta de liquidación de IVA, IRPF e impuesto de sociedades. |
Cita:
O eso creo. |
Hola
Efectivamente, en ese registro se manda el fichero TBAI, pero no tengo constancia de que se envíe en otro momento. Cuando se crea, para generar el QR, entiendo que se genera y queda en espera para su envío. Envío que se realiza en el 140 o 240. De todas formas ya se verá, ya que Gipuzkoa, quiere que sea el envío inmediato, es decir nada más generar el QR, y Bizkaia, no lo ha definido si va ha ser como el SII, mensual o trimestralmente. Ya nos enteraremos hacia el 30 de junio de 2019. |
Cita:
Un Saludo. |
Hola
Quisiera saber, que sistema estáis usando para firmar los documentos XML. Es un tema que desconozco, nunca he tenido que firmar documentos desde Delphi. De momento estoy usando la "Autofirma", para salir del paso, pero ya sé con toda seguridad que no va a ser válida. He mirado SecureBlackBox, pero el precio me parece astronómico, sobre todo si el software no puede costar más de 100 a 150€, según algún iluminado de hacienda. Agradecido si podéis orientarme. |
Cita:
|
Especificaciones tecnicas en Ingles
Buenas tardes,
Trabajo en una empresa extranjera que tiene clientes en el Pais Vasco, necesitamos la documentacion de las especificaciones tecnicas en Ingles para nuestro departamento de desarrollo, he mandado un email a las 3 Haciendas y me han contestado 2 de ellas que por ahora no tienen la documentacion en Inglés. Alguno la tendría traducida al ingles? Muchas Gracias. |
Buenas tardes, nosotros hemos hecho la misma consulta y no nos han contestado, también agradecería la traducción en inglés
|
Nueva respuesta de TicketBAI sobre el tema de la identificación de dispositivo en sistemas web:
La problemática de la identificación del dispositivo en arquitecturas web ha sido analizada por las Diputaciones y el Gobierno Vasco. Se ha llegado a la conclusión de modificar los apartados “4.1”, “5”, “8” y “9” del documento de especificaciones TicketBAI. Se informará del cambio a todas las empresas dadas de alta en el buzón de BATUZ, pero os lo adelantamos: Generación del fichero TBAI. Identificación del dispositivo. De forma transitoria, se considera opcional. Su obligatoriedad se evaluará en el futuro en la medida de que sea posible automatizar su obtención en todas las arquitecturas. Especificaciones técnicas de la fase de verificación presencial. Número de serie del dispositivo. De forma transitoria, mostrar este número de serie se considera opcional. Su obligatoriedad se evaluará en el futuro en la medida de que sea posible automatizar su obtención en todas las arquitecturas. Anexos 1 y 2. El número de serie del dispositivo de facturación aparecerá como opcional. Por fín, un poco de lógica en ese tema. Saludos |
Infografía SAGE
Adjunto infografía de SAGE sobre plazos en las distintas haciendas forales
Me fastidia un poco enterarme de este tema por la prensa o por terceros y no directamente por TBAI |
Empresas Extranjeras
Cita:
|
mas información
Por si alguién tiene las mismas dudas que yo .
Buenos días , Tenemos una duda sobre la futura transmisión de los tickets firmados a Hacienda . *¿Cómo se realiza el envío “ Alta y Bajas “ de Facturas Emitidas firmadas con Ticket Bai ? La web de Batuz se habilitará a mediados de Marzo y la documentación técnica se incorporará en el mes de Marzo. ¿Existirá un servicio Web distinto al de los modelos 240 y 140 ¿ Los libros registro de operaciones económicas (es decir, 140 para personas físicas y 240 para personas jurídicas) en realidad suponen la llevanza en la sede electrónica de la Diputación de los libros de las empresas, mediante servicio web o mediante la cumplimentación manual de formularios electrónicos, de modo similar a como en la actualidad funciona el SII. Los servicios web de las personas físicas serán diferentes a los de las personas jurídicas, dada su especial naturaleza. *Cada cuando tiempo tendrán que transmitirse ? En Bizkaia, el envío del fichero dentro de los esquemas de BATUZ dependerá del tipo de empresa o régimen elegido a efectos de IVA. • Si está en Régimen de Devolución Mensual, es una gran empresa o pertenece a un grupo de entidades, deberán enviarse los datos en el plazo de 4 días (plazos del SII). • En otro caso, el actual proyecto normativo establece que la remisión deberá ser al menos trimestralmente, en los plazos que se establezcan en el reglamento de obligaciones formales. *Existe un apartado en Batuz , tanto en el modelo 240 y 140 que menciona PJ_240_Facturas emitidas_SinTBAI? ¿En qué casos ha de rellenarse está información ? Este subcapítulo está previsto para dos casos en principio: 1º. Para aquellos supuestos en que, de acuerdo con la normativa y por excepción, se permita la emisión de una factura sin cumplimiento del sistema TicketBAI. 2º Y para los casos en que, por imposibilidad técnica, se tenga que remitir la información al libro de facturas emitidas pero no se haya podido cumplir con el sistema TicketBAI (p. ej. rotura del dispositivo de facturación). Gracias , |
Hola a todos.
Hay alguna forma en delphi de cargar un fichero ya generado con formato TicketBai en la clase que se genera al importar el fichero xsd proporcionado por hacienda, para luego recorrer las propiedades de los ficheros directamente. Sin tener que recorrer lo nodos de un objeto IXMLDocument que es ahora como lo estamos haciendo. Gracias |
Cita:
Puedes usar el XML Data Binding que viene con delphi que lo recupera sin problemas. NOTAS: 1) Debes eliminar del fichero ticketBai V1-0.xsd la línea del <import namespace="... 2) Luego puedes abrirlo seleccionando el fichero de esquena XSD. Yo lo He probado y funciona bien hasta con Delphi 7. NOTA: Ni caso, creo que leí rápido y no te he entendido. |
Duda Rapida
¿Ya esta activado el registro para empresas desarrolladoras de software para el ticketbai, o solo abrieron para el piloto?
|
Cita:
Yo lo hago así:
|
Cita:
Un Saludo. |
Agradecimiento
Cita:
Acabo de llamar a hacienda para solicitar la misma información, me dicen que esa información no tiene de como dar de alta empresas, que escriba un correo a [email protected] solicitando dicha información...muy poco serio no?, o tal vez hay que empezar a pensar en manos negras que quieren que no se sepa "toda la información" para que algunas empresas hagan negocio. |
Hola a todos, ya he descubierto por que no me carga un fichero TicketBai en la estructura IXMLTicketBai que me crea el xsd.
Al hacer que el XML DATA BINDING importe el xml, al generar el fichero con la clase que crea, lo crea con el siguiente formato
Pero los ficheros de ejemplo que mandaron son de la siguiente manera
En la fase de pruebas me dijeron que hay que ponerlo de la segunda manera y lo que hago es cambiar eso una vez generado el fichero TBAI y luego lo firmo. Por eso no me lo carga al hacer el LoadTicketBai( Fichero ); Si no lo cambio me funciona correctamente. La pregunta es. ¿Hay alguna forma de hacer que te ponga esa estructura directamente al importar el xsd o hay que hacer algo despues que se me escapa? |
(2020-03-16) Actualización de documentación Gipuzkoa
Han añadido a la documentación que ya habían enviado, la descripción de los servicios REST.
Además de en los links, añado la documentación al FTP del Club y actualizao el mensaje inicial del hilo. Documentación
|
Parece ser que existen algunos negocios que están exentos de realizar el TicketBai, pero no de presentar el 140 o 240, es decir los diarios de ingresos y gastos.
La presentación en Bizkaia será trimestral, salvo en los casos en que ya estén obligados a envíos mensuales, (Registro Devoluciones Mensuales). Y en el caso del 240 se completará con un envío de los diarios de contabilidad. |
Hola
Me gustaría saber si alguien, realiza las firmas del TicketBai, con las herramientas facilitadas por Izenpe. Se supone que hay unas librerías en JavaScript, para la firma de documentos. ¿Alguien ha usado este método para firmar los documentos? Gracias |
| La franja horaria es GMT +2. Ahora son las 06:08:57. |
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