![]() |
Yo tengo otra consulta similar...
¿Cómo hacéis para evitar que un cliente utilice una versión del software "antigua"? Me refiero al software de escritorio (instalable, no en la nube). ¿Cómo evitáis que un usuario pueda enviar facturas a TicketBAI usando una versión del software de hace 9 meses y no la más reciente? Sé que hay formas de hacerlo, y nosotros lo hacemos con otros servicios, addons, etc. pero tengo curiosidad por saber cómo exigir siempre la última versión disponible y bloquear las (muy) antiguas. |
Cita:
Nosotros tenemos una validación al intentar salvar la venta (antes que se haga el fichero ticketbai) que comprueba que sea un tipo impositivo válido. Estas validaciones solo se hacen en el caso que el usuario tenga ticketbai. Las validaciones las hacemos consultando unas fechas de vigencia/validez de cada tipo impositivo. Estas fechas son configurables en el mantenimiento de IVAs. El problema es que si los usuarios no se encargan de ajustar bien esas fechas, pueden pasar dos cosas: 1 que no les permita vender con un tipo impositivo que realmente si que es válido y nos llamen para configurarlo bien. 2 que les permita vender con un tipo impositivo no válido y que al enviar a TicketBAI la factura sea rechazada y nos llamen para ver que pueden hacer. La idea seria que todos los usuarios tengan bien configurados los tipos de IVA con sus fechas de entrada en vigor y finalización pero con tantos cambios normativos... No creo que en cada empresa haya alguien mirando la normativa cada día y configurando lo que toque:( Por eso preguntaba, para ver si informáis a cada cliente cada vez o no :o Vamos a ver que hacemos ... Saludos! |
Cualquiera de las opciones va a provocar que el cliente nos llame por teléfono o nos envíe un email, y eso puede ser una locura teniendo en cuenta el volumen de clientes que se puedan tener en esas tres provincias.
A eso súmale que puede que haya clientes que no tengan contratado el servicio técnico, etc. Quizás lo mejor en estos casos es, si la factura es rechazada, mostrar "posibles causas y cómo solucionarlas" en pantalla, o algo así. Al menos más de uno se dará cuenta y evitas que llamen todos. Pero vamos, que nos quieran convertir a los desarrolladores en asesores fiscales, pues va a ser que no... |
Cita:
Cita:
Nosotros más o menos igual. El cliente puede configurar sus tipos de IVA nuevos y utilizarlo de forma correcta. Lo que sí, desde la empresa, se emite un comunicado con tiempo para que lo sepan y con las instrucciones. |
Cita:
Muchas gracias Neftali, en esta ocasión la idea de enviar el comunicado "con tiempo" se ha complicado:p |
Cita:
Nosotros no manejamos el software de facturación de nuestros clientes (cada uno tiene el suyo). Tenemos una API en la nube, a donde se conecta cada software de nuestros clientes para enviar los datos de la factura a emitir. La API le devuelve el código TBAI, el QR y los datos de la factura y se encarga del envío del XML firmado a Hacienda Foral. Nuestra API tiene la tabla de IVAs válidos en cada momento. Si alguna línea de detalle de uan propuesta de factura que envía un cliente, desde su software de facturación, contiene un tipo de IVA no válido en ese momento, se le devuelve indicándole el error. Es quien factura quien debe conocer la normativa de IVA válido en cada momento (y aplicarlo). Nosotros con no admitir la propuesta de factura que nos envía, lo solucionamos. Aparte, nosotros sí somos, también, asesoría contable y fiscal ... pero eso es otro departamento. Saludos |
Cita:
Muchas gracias Sistel. En vuestro caso entiendo que solo cambiando los datos en la tabla de ivas válidos el programa ya lo hace correctamente, y al estar en la nube no tenéis que cambiarlo para cada usuario del programa. buena idea. |
Hola!!
Necesitaba hacer unas pruebas y me esta dando este error: No hay definido un servicio al que llamar para el modelo:140, ejercicio:2024, período: y apartado: 1,1 para el interesado enviado: 99980022B Sabéis que puede ser? Veo que periodo esta en blanco pero nunca he rellenado nada de periodo ni sé donde va... |
Zuzendu
Buenas,
Una pregunta en Zuzendu, ¿el encadenamiento de que factura es? para explicarme Mi factura: 135 encadenada con la 134 No se si tengo que copiarla tal cual a la factura original : 134 De la propia factura original: 135 De la ultima factura : XXX el SignatureValueFirmaFactura: ya se que es de la 135 |
Buenos dias, alguien ha probado a sincronizar a Bizkaia con los IVAs nuevos.
A nosotros no esta dando error "Valor del Tipo impositivo no admitido" |
Cita:
|
Cita:
|
Parece ser que ya lo han arreglado...
|
Como siempre nosotros lo tenemos que tener preparado para el día 1. Ellos cuando quieran sin prisa,
|
Cita:
Buenas. El encadenamiento es el que tuviera en un principio el fichero de alta. Es decir, de la 134, para abreviar. |
Buenas,
Hay ha subido a Alava facturas con el 2% en real? Me deuelve un error de <Descripcion>72-AVISO: Error validación de negocio [Importe total no coincide con el sumatorio de los detalles]</Descripcion> Y no sé si es problema mío o de ellos? Gracias |
En producción no se. Pero en el entorno de pruebas funciona correctamente.
|
Ya que estamos. Alguien esta teniendo problemas con los certificados en el entorno de producción. Nos han llamado varios clientes que al enviar a Bizkaia les da un error de certificado y hasta hoy enviaban correctamente.
|
Autofactura
Buenos días, Tenemos un cliente de Vizcaya que nos envía autofactura. De forma que nosotros enviamos la factura de venta a Batuz y el cliente también envía esta factura a Batuz, por lo que en Batuz y en el modelo 303 esta duplicada.
En el fichero que enviamos a Batuz, ponemos sobre el campo <EmitidaPorTercerosODestinatario> una "D" de "Factura emitida por el destinatario o la destinataria de la operación". Alguien sabe si este tipo de facturas tienen que enviarlas tanto el cliente, como nosotros; solo el cliente o solo nosotros? Gracias |
Nuevos tipos de IVA
Una duda que seguro que se ha comentado tropecientas veces, pero de la que no encuentro la respuesta:
Factura emitida con tipo de IVA 2%. Se ha de emitir ahora factura rectificativa de esa factura, pero actualmente el tipo está al 7,5%. ¿Qué tipo se ha de usar para esta rectificativa teniendo en cuenta que la operación se produjo cuando estaba en vigor el tipo del 2%? Muchas gracias. |
Cita:
La lógica me dice que el que usaste en la factura original. Si cuando creaste la original no existía el 7,5%, ahora no puedes usarlo en la rectificativa. Pero legalmente no tengo ni idea... :o:o |
Cita:
Tienes que usar el tipo de iva de la factura que estas rectificando. Esos si en la fecha de operación tienes que poner la fecha de la factura rectificada, ya que sino no te va a dejar usar esos tipos de iva que no existen. Un Saludo. |
Buenas...
Tengo un problema con un cliente de Bizkaia que lo tiene todo: persona física, productos con distintos epígrafes, recargo de equivalencia... Maldita la hora que Bizkaia decidió hacer lo de los dichosos epígrafes. Con Gipuzkoa y Araba esto no pasa. Su asesor fiscal dice lo siguiente: 1. Las facturas de servicios: - Van al epígrafe X (el que sea) - Clave Regimen 01 (régimen general IVA) - En el LROE el campo "ImporteIngresoIRPF" debe coincidir con la base imp. de la factura y "IngresoAComputarIRPFDiferenteBaseImpoIVA" indicado con "N" 2. Facturas con productos: - Otro epígrafe distinto - Factura acogida a Recargo de Equivalencia, así que en Clave Regimen supongo que se debe indicar la de Recargo Equiv.???? - Base imponible de IVA es diferente a base imponible de IRPF. En el LROE tiene que aparecer IngresoAComputarIRPFDiferenteBaseImpoIVA = "S" 3. Facturas con ambas cosas: productos y servicios - Aquí ya me dolía la cabeza Vamos a ver. Lo que yo hago es, separar las bases imponibles de cada Epígrafe que haya en la factura, según los conceptos/productos que tenga. Es decir, si una factura tiene conceptos de un epígrafe y conceptos de otro, los "agrupo" y así obtengo la base imp. para cada epígrafe. Luego al generar el LROE, indico el epígrafe y su base imp. correspondiente. Entiendo que tendría que saber de antemano si la base imponible de cada epígrafe es distinta al importe de la factura, para poder indicar si IngresoAComputarIRPFDiferenteBaseImpoIVA es "S" o "N". ¿No? ¿O no es eso lo que hay que hacer y me estoy liando más de la cuenta? |
¿Alguien puede probar a enviar a PREPRODUCCION de Guipúzcoa y Vizcaya?
Ambos me están fallando ahora (15:51) Álava parece que bien |
a mi me da error desde esta mañana, Guipúzcoa , 404 not found (sigue igual ahora)
|
Cita:
Gracias [pablo]. Está devolviendo un HTML, ni siquiera error en formato correcto. SRVE0255E: A WebGroup/Virtual Host to handle /WAS/HACI/HTBRecepcionFacturasWEB/rest/recepcionFacturas/alta has not been defined. SRVE0255E: A WebGroup/Virtual Host to handle tbai-prep.egoitza.gipuzkoa.eus:443 has not been defined. |
Vizcaya ha sido algo puntual, ya vuelve a funcionar.
|
Entorno de pruebas cambiando
La url del entorno de pruebas de Gipuzkoa está cambiada según la documentación actual https://www.gipuzkoa.eus/documents/2...1-fcf7a631a948
ha cambiado de https://tbai-prep.egoitza.gipuzkoa.e...nFacturas/alta a https://tbai-z.prep.gipuzkoa.eus/sarrerak/alta Pero a mí me sigue saltando también error similar con el nuevo Error: SRVE0255E: A WebGroup/Virtual Host to handle /WAS/HACI/HTBRecepcionFacturasWEB/rest/recepcionFacturas/alta has not been defined. SRVE0255E: A WebGroup/Virtual Host to handle tbai-z.prep.gipuzkoa.eus:443 has not been defined. |
https://tbai-z.prep.gipuzkoa.eus/sarrerak/alta
ahora mismo ya no da error 404 not found , ahora da 503 Service Unavailable v\||/ |
Cita:
Actualizo el mensaje#1 donde está el recopilatorio de información. |
Buenas, tengo una duda para Vizcaya.
En este caso es en las facturas recibidas rectificativas. ¿Cómo es la estructura para cuando en la misma factura estás rectificando más de una factura? Si alguien me puede dejar un XML o algo para verlo me podría ser de gran ayuda. Un saludo y gracias |
Cita:
De todas formas, para que quede avisada la gente, parece que aunque en la documentación oficial publicada esté la url de pruebas https://tbai-z.prep.gipuzkoa.eus/sarrerak/alta sigue sin funcionar debidamente y parece que han re-establecido la anterior https://tbai-prep.egoitza.gipuzkoa.e...nFacturas/alta ahora mismo, que si está procesando las entradas otra vez |
Buenas tardes. Tengo un (pequeño) problema. Mis programas transmiten a ticket Bai a través de las librerías Chilkat y el certificado digital en .pfx de la FNMT (persona física en caso de autónomos o representación) . Hasta ahí todo bien. Cualquier empresa ha podido solicitarlo sin más problema, aunque para su día a día utilicen el certificado de Izenpe
Ahora bien, tengo un cliente que es un Colegio Oficial, y que no tiene tan fácil hacer una acreditación presencial para obtener dicho certificado . ¿Hay alguna manera de exportar el certificado de Izenpe a un archivo .p12 o .pfx sin que haga falta tener la tarjeta para su utilización? |
Cita:
Perdón pero no he acabado de entender la cuestión. Tanto los certificados digitales de FNMT como los de IZENPE se pueden obtener en formato físico (tarjeta para lector digital) o en formato digital (fichero). Si se tiene en formato fichero instalado en un navegador web se puede exportar para instalarlo en cualquier otro. Eso sí, al solicitar el fichero hay que tener claro si se quiere en formato físico o en fichero. Los de formato físico no pueden pasarse después a fichero y siempre se va a necesitar un lector digital. Yo recomiendo, siempre, obtenerlos en formato fichero. Saludos |
Cita:
|
Cita:
|
Cita:
|
Cita:
|
Cita:
|
Hola a todos.
Llevo enviando las facturas a TicketBAI desde siempre con el componente TNEtHTTPClient de delphi desde el principio sin ningún problema. Envío con los certificados instalados en windows, a través del evento OnneedClienteCertificate. Hasta ahora no he tenido ningún problema. Pero llevo un par de meses que a algunos clientes no les funciona con los dichosos certificados de izenpe que estan en una tarjeta y piden contraseña. Hasta ahora cuando utilizaban esos certificados a la hora de enviar les salía una ventanita pidiendo la clave del certificado (esa ventana salía sola al hacer el envío con AResponse := componente.Post(Dirección,RequestBody)), ahora cuando hago el post no sale la ventana para pedir la clave y el programa se queda frito, ya que se queda esperando a que termine el proceso. Esto no me pasa con todos los clientes que tienen ese certificado, solo con algunos. Y en usuarios donde me pasa si seleccionan otro certificado, por ejemplo de la FNMT, funciona correctamente. Es como si algo no estuviera dejando salir esa ventana de la clabe. He probado a quitar antivirus, cortafuegos, etc y sigo igual. A estos clientes que ahora no les funcionaba les ha empezado a pasar de repente, sin hacer ninguna actualización del programa, hasta ahora les funcionaba. No se si a alguien le ha pasado lo mismo o tiene alguna pista. Gracias.:mad: |
| La franja horaria es GMT +2. Ahora son las 04:51:53. |
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