FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Temas de Hoy |
|
Herramientas | Buscar en Tema | Desplegado |
#3481
|
|||
|
|||
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 |
#3482
|
|||
|
|||
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.
Última edición por Neftali [Germán.Estévez] fecha: 09-11-2022 a las 13:22:58. Razón: Formatear código correctamente |
#3483
|
|||
|
|||
De DELPHI no tengo ni idea, pero mirando ese bucle, no veo ningún código que me sugiera que estás agregando líneas de factura.
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. |
#3484
|
||||
|
||||
Cita:
__________________
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. |
#3485
|
|||
|
|||
Cita:
si, lo siento, el modelo es una iguual TP8002 compatible con ESC/POS |
#3486
|
|||
|
|||
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' Última edición por Neftali [Germán.Estévez] fecha: 09-11-2022 a las 15:14:41. |
#3487
|
|||
|
|||
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 Última edición por Neftali [Germán.Estévez] fecha: 09-11-2022 a las 15:12:38. |
#3488
|
||||
|
||||
Cita:
Prueba a no usar la previsualización.
__________________
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. |
#3489
|
||||
|
||||
Sí que funciona el Add.
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"?> <T:TicketBai xmlns:T="urn:ticketbai:emision"> <Cabecera> <IDVersionTBAI>1.2</IDVersionTBAI> </Cabecera> <Sujetos/> <Factura> <DatosFactura> <DetallesFactura> <IDDetalleFactura> <DescripcionDetalle>10</DescripcionDetalle> <Cantidad>1</Cantidad> <ImporteUnitario>100</ImporteUnitario> <ImporteTotal>90</ImporteTotal> </IDDetalleFactura> <IDDetalleFactura> <DescripcionDetalle>10</DescripcionDetalle> <Cantidad>2</Cantidad> <ImporteUnitario>200</ImporteUnitario> <ImporteTotal>180</ImporteTotal> </IDDetalleFactura> </DetallesFactura> </DatosFactura> </Factura> <HuellaTBAI/> </T:TicketBai>
__________________
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. |
#3490
|
|||
|
|||
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.
|
#3491
|
|||
|
|||
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... |
#3492
|
|||
|
|||
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:
|
#3493
|
|||
|
|||
NIF Emisor incorrecto
Me respondo a mi mismo por si a alguien le viene bien.
Me han contestado esto: Cita:
|
#3494
|
|||
|
|||
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. |
#3495
|
|||
|
|||
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 |
#3496
|
||||
|
||||
Cita:
No cuadra con el orden del primer ID de la tabla, pero sí cn la fecha/hora (no se si me explico).
__________________
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. |
#3497
|
|||
|
|||
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... |
#3498
|
||||
|
||||
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). |
#3499
|
|||
|
|||
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... |
#3500
|
|||
|
|||
Cita:
Yo lo hago de la siguiente manera:
|
|
|
Temas Similares | ||||
Tema | Autor | Foro | Respuestas | Último mensaje |
SII -Nuevo sistema de la Agencia Tributaria española de envío de datos vía Webservice | newtron | Internet | 3587 | 20-08-2024 14:11:07 |
Como utilizar la ayuda del nuevo Sistema Operativo | gluglu | Humor | 3 | 24-09-2007 09:39:05 |
Aplicacion Agencia De Viajes | ArdiIIa | Varios | 9 | 20-01-2007 16:49:53 |
El Vasco Aguirre | Al González | La Taberna | 5 | 26-05-2006 09:22:28 |
Microsoft ha lanzado su nuevo sistema operativo | DarkByte | Humor | 0 | 25-01-2004 09:21:14 |
|