|
Cita:
Fué al enviar una Alta de factura. El nif es correcto pero se nos pasó y venía un un guión. Y la factura se rechaza, código de error 002 Fichero no cumple el esquema XSD. Detalle del error: cvc-pattern-valid: Value 'NIFOKAQI-R' is not facet-valid with respect to pattern '(([a-z|A-Z]{1}\d{7}[a-z|A-Z]{1})|(\d{8}[a-z|A-Z]{1})|([a-z|A-Z]{1}\d{8}))' for type 'NIFType'. En nuestro caso el estado es 01 Rechazada Gracias |
bloqueado con el xml
Buenas a tod@s, estoy migrando un programa de D6 a D10 con todo lo que supone d incompatibilidades (componentes bde, informes qr, ...) y ahora encima esto del ticketbai; estoy leyendo el foro d ticketbai (voy x la página 60) y me imagino las horas y roturas d cabeza que llevais, la cantidad d errores que habeis solucionado entre todos, así que os felicito.
Yo necesitaría algo d ayuda, así que pondré varias cosas x si alguno tiene tiempo o ganas d ayudarme, d todas formas gracias x anticipado. Estoy montando el xml insertando datos d las tablas del tpv y al hacer el bucle para recorrer las líneas d la venta actual añadiendolas como iddetalleventa sólo me carga la última línea. Os pego el código x si me podeis ayudar.
|
Cita:
Veo por un lado asignaciones a Cantidad, Descuento, etc... Y por otro lado veo que a cada vuelta entras en "IDDetalleFactura" con un With. Si en Delphi con ese "with" inicial ya estás creando una nueva línea, entonces no me hagas caso, pero si ese lenguaje es parecido a otros que he usado, diría que estás asignando los valores todo el rato a la misma fila. |
Cita:
|
Cita:
si, lo siento, el modelo es una iguual TP8002 compatible con ESC/POS |
Cita:
pero obtengo esta salida: Cita:
intento poner el formato d código delphi y en previsualizar se ve bien pero luego sale todo sin formato, sorry. Puede ser x este aviso??? 'Aún no tienes permitido poner enlaces ni imágenes' |
Much@s a lo mejor os estareis partiendo la caja flipando conmigo, que no soy capaz d mandar un post en condiciones, no es mi intención dar curro al admin editando mis post, pero intento hacerlo bien.
Desarrollé una aplicación en los años 90, D1, D2... d unas 89.000 líneas de código, además dl schema d la bbdd que entre sp y triggers andará x las 2.500. Pero todo esto me supera, en todos los grupos hay un amigo patoso, tener paciencia conmigo. Si alguien necesita código de lectura d cod d barras, facturación, etc..... estoy encantado d aportar mi granito d arena. Un saludo a tod@s y gracias x la comprensión |
Cita:
Prueba a no usar la previsualización. |
Cita:
Te pongo algo de código para trabajar en las facturas de TBAI, simplemente para que veas. Un código como este (revisa sobre todo la parte del Add para las líneas):
Genera una salida como esta (con 2 detalles de líneas): Código:
<?xml version="1.0"?> |
Hash
Hola. El Hash te lo dan ellos. El que pones es el actual que lo cambiaron en mayo. Yo lo dejo modificable por si lo vuelven a cambiar.
|
NIF Emisor incorrecto
Hola,
hoy he realizado mi primer envío de pruebas a la hacienda alavesa y he recibido lo siguiente: Código PHP:
¿Tengo que registrarme en algún otro lado para corregir este aviso? En el entorno de PRO de Gipuzkoa estoy funcionando bien con el mismo NIF Emisor. No se si se me esta escapando algo para Alava... |
NIF Emisor incorrecto
Revisando la Guía del entorno de pruebas veo:
Cita:
Cuando pase al entorno de PRO, ¿me volverá a aparecer el AVISO? Yo siempre realizo envíos de clientes: Código PHP:
|
NIF Emisor incorrecto
Me respondo a mi mismo por si a alguien le viene bien.
Me han contestado esto: Cita:
|
Buenas,
Estaba repasando algunos envíos de facturas de hoy, y me he encontrado esto:  La numeración de facturas ya me dijeron los de Hacienda que "da igual" el orden en que se les envíen (aunque se recomienda que sean correlativos). Lo que no me queda claro es si les va a gustar la hora.... ¿Tenéis alguna experiencia con este tema? Es decir, si os haya pasado enviar alguna factura así y que no os hayan dicho nada. Por el momento están como OK, y tampoco han llegado avisos de "posible error de encadenamiento". Gracias. |
Hacieenda Alava - Facturas a bares de chinos
Buenos días,
Tengo un problema con los típicos bares chinos En la parte del IDOTRO ll grabo el código de país CN que lo saco de la lista de países de la Hacienda nacional ( https://sede.agenciatributaria.gob.e...rritorios.html ) porque de la de Alava no llegué a ella y me devuevlve 54-AVISO: Error en factura: Error en país del destinatario no nacional Luego tengo un error 79-AVISO: Error validación de negocio [Importe total no coincide con el sumatorio de desglose Le pongo causa de la exención E2 y en la base imponible pues eso. Gracias de antemano |
Cita:
No cuadra con el orden del primer ID de la tabla, pero sí cn la fecha/hora (no se si me explico). |
Cita:
1713 -> 1712 -> 1711 En nuestro caso por un lado tenemos una aplicación de Windows que está en los puntos de venta, que es la que genera una factura, asigna la fecha, etc.. y luego la envía a un API intermedio (PHP) que está en un servidor. Este API simplemente recibe facturas, las encola, y las envía, poniendo el encadenamiento según van entrando en cola. La factura 1713 ha tardado 3 minutos en enviarse a la cola (desde Windows), y creo que es porque es una factura completa. Me da que la aplicación de Windows está generando la factura, con su fecha y todo, y después en tienda se han puesto a introducir datos de cliente. El tema es que (aparte del API) en esta aplicación yo solo me he encargado de hacer una función que envía los datos al API (esta función recopila los datos de la factura, genera un objeto JSON, etc. y lo envía al API). Pero el resto de funcionalidades ya existentes, más relacionadas con clientes/pedidos etc. están fuera de mi "jurisdicción". Les voy a pedir que entren en la Sede Electrónica a ver si hay alguna alarma. En cualquier caso, les voy a pedir que la fecha de expedición se guarde justo antes de llamar a mi función. De todas formas, preguntaba por saber si alguien más envía facturas así y no pasa nada. La numeración entiendo que da igual mientras haya encadenamiento correcto (1600 -> 1607 -> 1606...), pero que la fecha de emisión no siga el orden de la numeración ya lo veo más raro... |
Cita:
El TPV1 encola la factura 1711 y, mientras el TPV2 prepara la factura 1712 (ya enlazada con la 1711), el TPV1 (o el 3) encola la factura 1713. Por último, el TPV2 encola la 1712. ¿no se puede enlazar y firmar la factura 1712 al final del proceso para evitar ese retraso? Igual digo una chorrada, pero otra opción que puede que no sea viable sería asignar a cada TPV una serie diferente (por ej. T1, T2...). Entonces al servidor le llegarían las facturas T1-1711, T1-1712 (la 1713 anterior) y T2-17xx (la 1712 anterior). |
Cita:
Antes de nada, por ampliar información: Las TPV llaman a una función "EmitirFactura(Codigo)". Aquí es donde entro yo: A partir del identificador interno (Código) obtengo serie, número factura, fecha, así como las cabeceras, líneas, etc... Una vez hecho esto, envío el JSON al API. Es decir, esta función es lo último que se llama cuando en la base de datos de la oficina central ya está la factura creada, de cara a obtener el QR. En el lado del API, en servidor, tengo unas bases de datos ya 100% relacionadas con TicketBAI, donde guardo las facturas recibidas, logs de envíos, etc... Cuando me llega el JSON de una factura, agrego el registro como "Pendiente", la encadeno a la anterior, firmo, y devuelvo el QR. Un tercer proceso que se ejecuta cada 10 segundos, enviará la factura después, pero la TPV ya ha recibido su QR. Es decir, en el momento que se llama a "EmitirFactura" ya está asignada la fecha y numeración. Ahora, al lío: Primero, es la factura 1713 la que han tardado en enviar, al ser completa. Viendo los números, lo que creo que ha pasado es esto: - TPV-1 emite la factura 1711 a las 17:56 (el API la pone en cola, encadena 1710) - TPV-2 genera (NO emite) la factura a las 17:57 con los datos del pedido, pero no le asigna numeración (asumo que están rellenando datos de cliente) (no se envía al API ni encola nada) - TPV-3 emite la factura 1712 a las 18:00 (el API la pone en cola, encadena 1711) - TPV-2 termina de meter los datos del cliente, y al emitir la factura le asigna la numeración 1713 (el API la pone en cola, encadena 1712) Lo voy a confirmar con la persona que se ha encargado de implementar esto en las TPV. De todas formas la fecha se debería asignar en el momento de pulsar el botón de cerrar el pedido para emitir el ticket. De este modo, la factura 1713 habría sido por ejemplo a las 18:01 Y justo ahora según escribo esto, estoy viendo que la factura 1714 está marcada como emitida a las 17:59. Así que no me extrañaría si los de Hacienda nos den algún tirón de orejas... |
Cita:
Yo lo hago de la siguiente manera:
|
Buenas...
Tengo un problema con un cliente que decidió enviar a Hacienda facturas reales al entorno de pruebas (por ejemplo, de la 1 a la 10), luego siguió enviando facturas al entorno real/producción (de la 11 a la 20) y ahora quiere enviar, al entorno real, esas primeras 10 facturas que solo se enviaron al de pruebas. Obviamente da error de encadenamiento, pero el cliente dice que Hacienda le dice que sí debería poder enviarlas. Yo le he dicho que, si ya envió al entorno real, las facturas 11 a la 20, si quiere enviar ahora de la 1 a la 10 me temo que no queda otra que anular o hacer rectificativas de todas, lo cual es un coñazo. ¿Hay alguna otra opción? |
Cita:
Yo he hecho cosas raras con números y fechas de emisión, y por el momento no he obtenido errores de encadenamiento (de hecho justo unos mensajes atrás pregunto sobre ese tema). Yo por ahora estoy haciendo lo que dicen ellos: "encadenar con la última factura emitida por el dispositivo", independientemente de qué fechas o números tenga. (Eso sí, en mi caso todavía tengo que confirmar en la Sede que el lío de fechas y números que he montado está "correcto", independientemente de que la respuesta suya haya sido "OK") |
Tengo un cliente en gipuzkoa en producción que esta teniendo problemas para subir las facturas.
Os funciona? |
Cita:
|
gracias, voy a ver que sucede pues.
|
Cita:
|
No puede Anular las facturas, porque la anulación es para temas muy concretos según la ley de facturación.
No puede hacer una rectificativa, porque para hacienda las facturas originales no existen y el cliente tiene una factura correcta. Yo creo que puede enviarlas. La 1 y la 21 darán error de encadenamiento pero serán aceptadas (Aceptadas con errores). Si hacienda pide más datos (por los saltos en los Números/Fechas no correlativos y los encadenamientos) pues tendrá que justificarlo explicando lo que ha pasado (no creo que lo pidan). Cita:
|
Gracias a tod@s.
Entiendo que sí que podrá enviar las facturas de la 1 a la 10 sin problema (enviadas pero con avisos, pero enviadas). Luego si hay que explicar o justificar algo, que lo justifique. De hecho yo he hecho pruebas de envío no correlativos y el envío se realiza, pero con el aviso de "posible error de encadenamiento". En su momento debí haber preparado la aplicación para que separara lo que consta como enviado a pruebas y lo que consta como enviado al entorno real, pero no caí en eso y ahora voy a tener que pensar cómo conseguirlo para evitar errores similares en el futuro. |
Ejemplo factura negocio de extranjeros
Estoy con los negocios de chinos, pakistanís...y no consigo subirla a la Hacienda de Alava (y me quedan 15 días para solucionarlo)
Cita:
Me devuelve el error Cita:
Antes la Hacienda Alavesa tenía un buzón con un mail donde les podías mandar ejemplos ahora lo han sustituido por un fomulario web a la que es imposible adjuntar archivos por temas de seguridad...los odio. Alguien me puede ayudar Gracias de antemano |
algo está mal ahí, en el nodo de detalle, si multiplicas la cantidad (10) por el importe unitario, da 145.1
si es exenta, no lleva iva entonces , como es que da 175.57 el importe total, si no lleva descuento? Yo también me estuve peleando con eso, el como quieren que presentes el importe unitario, es un jaleo, y espérate que no tengas descuentos, que ya es una fiesta |
Parto de la base que no tengo claro si lo tengo que poner como "exenta" o "no exenta"...he empezado poniendo exenta porque así lo tenía programado en su día con el SII...
|
a lo que me refiero es que siempre te tiene que coincidir la cantidad * importe unitario con el importe total (todo hablado del nodo IDDetalleFactura). Si eso no te coincide, siempre te van a decir que está mal, independientemente que sea exenta, no exenta, sujeta o no sujeta
sacado de las faqs: 12.10 ¿Qué se debe informar en el campo “Importe total” del bloque “Detalles factura”? El campo “Importe total” del bloque "Detalles factura" será el resultado de multiplicar los importes informados en los campos “cantidad” por los informados en los campos “importe unitario”, restándole en su caso los descuentos aplicados e incluyendo el IVA y el recargo de equivalencia. Este campo incluye el IVA que en su caso se repercuta en la operación y el recargo de equivalencia. |
La misma factura subida a un bar nacional sube perfecta
|
Cita:
Es que no me cuadra porque veo un destinatario con código postal de aquí, ClaveIVA "02", factura exenta... |
Cita:
No. Igual la estoy planteando mal.... Es simplemente una factura absolutamente normal a un bar que es su dueño es una persona extranejera. Esa es la problemática que necesito. Me encuentro en la documentación con para los clientes no nacionales hay que llenar le etiqueta DesgloseTipoOperacion y ahí me pierdo. ahí no sé porqué opción tirar. La factura, es idéntica a cuaquiera de un cliente nacional. Sin exportación. Lo de las naranjas son por mis pruebas de datos. El caso real sería vender a un bar un barril de cerveza, una caja de coca cola... |
Cita:
- Factura no simplificada a nombre de un particular extranjero: Idéntica a nacional, con la diferencia que en Destinatario pones sus datos. - No simplificada a nombre de empresa extranjera: Factura igual que las demás, pero con sus datos en Destinatario. Si la empresa es de fuera de Europa, TipoDocumento 04 o 06. Además, al ser empresa, sería Exenta, pero con motivos que no sean Exportación excepto que hagas esa operación... en nuestro caso para empresas NO-nacionales es "E5", para Entregas Intracomunitarias "E6" (cuando envías fuera), y exportaciones fuera EU "E2". Es decir en tu caso si es simplemente emitir la factura a nombre de esa empresa china pero todo queda aquí, una factura normal y corriente con destinatario China, TipoDocumento 04/06.. Entiendo también que se podría poner exenta, pero aquí me pierdo ya, porque no sé si al ser una empresa que opera aquí, las normas cambian... es decir, no sé si están afectados por el IVA al comprar/vender igual que cualquier empresa de aquí, etc... eso se lo dejo a vuestro asesor/contable :rolleyes: |
Mi caso es este
Cita:
El problema que tengo es que no puedo (o no sé) hacer solo la factura idéntica a la de uno nacional porque al poner el IDOTRO ya necesito rellenar algo en las etiquetas que cuelga de "DesgoseTipoOperacion" para que no me de error de valdación en el XML y ahí es donde me pierdo. |
Cita:
No sé si te ayuda, pero te paso un fragmento de una factura a nombre de una empresa polaca, que ha sido aceptada OK: <Destinatarios> <IDDestinatario> <IDOtro> <CodigoPais>PL</CodigoPais> <IDType>02</IDType> <ID>PL52XXXXXXXX</ID> </IDOtro> <ApellidosNombreRazonSocial>XXXX XXXX</ApellidosNombreRazonSocial> <CodigoPostal>02-XXX</CodigoPostal> <Direccion>XXX XXX XXX</Direccion> </IDDestinatario> </Destinatarios> (...) <DetallesFactura> <IDDetalleFactura> <DescripcionDetalle>Anticipo de pedido nº XXXXXX</DescripcionDetalle> <Cantidad>1.00</Cantidad> <ImporteUnitario>50.00</ImporteUnitario> <Descuento>0.00</Descuento> <ImporteTotal>50.00</ImporteTotal> </IDDetalleFactura> </DetallesFactura> <ImporteTotalFactura>50.00</ImporteTotalFactura> <Claves> <IDClave> <ClaveRegimenIvaOpTrascendencia>01</ClaveRegimenIvaOpTrascendencia> </IDClave> </Claves> (...) <TipoDesglose> <DesgloseTipoOperacion> <Entrega> <Sujeta> <Exenta> <DetalleExenta> <CausaExencion>E5</CausaExencion> <BaseImponible>50.00</BaseImponible> </DetalleExenta> </Exenta> </Sujeta> </Entrega> </DesgloseTipoOperacion> </TipoDesglose> (...) |
Cita:
Me sirve para coger alguna idea pero no creo que una empresa fiscal polaca tenga la misma exención que una persona china Gracias de todas formas |
Cita:
Hasta donde yo sé, si un estadounidense va al fnac de Madrid y se compra el iPhone 17 ProMegaMoloXQSoyDeApple, pagará 2.500€ igual que el resto, haga factura a su nombre o no. |
| La franja horaria es GMT +2. Ahora son las 11:45:00. |
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