FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Temas de Hoy |
|
Herramientas | Buscar en Tema | Desplegado |
|
#1
|
|||
|
|||
Cita:
|
#2
|
|||
|
|||
Cita:
Las facturas deben ser consecutivas en número, fecha y hora. Yo considero 2 estados: - Recopilación de datos para la factura (no considero aún emitida la factura) - Emisión de la factura: asignación de nº de factura (siguiente a la última emitida), fecha y hora y creación y firma del XML Si la asignación de nº de factura, fecha y hora y creación del XML y firma lo haces en servidor, te olvidas del problema de que haya varios puestos diferentes creando facturas y no sean consecutivas. Saludos |
#3
|
|||
|
|||
Buenos días a todos,
Ando redactando la memoria para Gipuzkoa, y repasando en mi código el tema del encadenamiento, a la hora de redactar cómo funciona, me han entrado algunas dudas sobre si lo que tengo montado se puede considerar correcto. En la documentación mencionan que en Gipuzkoa la comunicación debe ser "inmediata". Pero claro, no estoy seguro qué consideran ellos inmediato... El sistema que tengo montado (todavía en fase de pruebas) funciona así: Infraestructura: - Servidor con un API propio, que viene a ser un "proxy" entre las personas que crean las facturas, y Hacienda. - Tiendas físicas con software Windows para venta y emisión de tickets. Servidor: - Se recibe un JSON con una factura. - Se crea un registro en la BBDD con todos los datos. - Se firma y se guarda todo. - Si es nueva factura queda marcada como "pendiente de enviar", y si es una corregida se guarda como "a reenviar" Cronjob que se está ejecutando constantemente en el servidor: - Cada 10 segundos, y en orden de creación de factura, se lee una factura de la tabla anterior y se envía. - Si es una factura sin intento de envío previo, obtengo el XML ya firmado que estaba guardado. - Si es una factura a corregir, genero de nuevo el XML a partir de los datos de la factura, que no va firmado. Con esto me aseguro de que el encadenamiento esté siempre bien. Es decir, aunque una factura sea rechazada, ya se considera como "factura anterior" para el encadenamiento. Y al haber solo un hilo del sistema dedicado al envío de facturas, con los 10 segundos de margen se evitan situaciones donde dos envíos se pisan entre ellos, si el primero por ejemplo tarda varios segundos. Otro de los motivos de tener esto así, es poder emitir el ticket con el QR incluso aunque todavía no hayamos comunicado con Hacienda. Es decir: - Un cliente compra un producto en la tienda. - El software del ordenador envía los datos a nuestro API, y le entrega el QR y TBAI. - La factura todavía no sabemos si tiene el XML incorrecto, si va a ser rechazada o aceptada, pero entiendo que me da igual. - El cliente se va con su ticket. - En los segundos siguientes a haberse guardado la factura, ya se va a enviar a Hacienda mediante el cronjob. ¿Mi preocupación? Que por lo que sea, se generen muchas facturas en algún momento, y en lugar de tardar de 1 a 9 segundos en estar funcional el QR, tarde 50 segundos por ejemplo... o más. ¿Debe ser inmediato.... inmediato? ¿Sabéis algo de si el inspector que hace verificaciones presenciales crea una factura e intenta leer el QR en el mismísimo instante? Gracias! Saludos. |
#4
|
|||
|
|||
Cita:
Parece correcto. Aunque tienes que tener en cuenta algunos matices: - Cuando dices "Se recibe un JSON con una factura", no es del todo correcto. Deberías decir "Se recibe un JSON con los datos para emitir la factura", ya que la factura no existe hasta que no se emite, que es en el momento que se crea y firma el XML. Y, por supuesto, es totalmente correcto que, a partir del tener el XML firmado obtengas el código TBAI y el código QR y los imprimas en el documento de la factura (independientemente de que aún no se haya enviado a Hacienda) El término "envío inmediato" no supone ir a la velocidad de la luz. Al igual que tú, yo lanzo un cronjob (yo lo hago cada minuto). Y se encarga de enviar cada una de los XML firmados que aún no se han enviado. Yo entiendo que 1 minuto es inmediato. Respecto al tema de la Verificación Presencial, entiendo que si un inspector se persona en el domicilio desde el que se emiten las facturas, puede solicitar ver el resultado que muestra el botón de "Verificación Presencial" (o como se quiera llamar en la aplicación), pero no creo que un inspector pueda tocar nada y, menos aún, emitir una factura. Entiendo que podría solicitar ver una factura y escanear, con su smartphone el código QR para comprobar el estado y datos en la web de Hacienda Foral. Saludos |
#5
|
||||
|
||||
Buenas Sistel,
Muchas gracias por la respuesta. Vamos respondiendo: Cita:
Tenemos por un lado un servidor con un SQLServer, y por otro lado un Access VBA en Windows que es el punto de venta de las tiendas físicas. Para poder realizar cualquier venta hace falta conexión a Internet ya que todo el tema de stock, pedidos, etc. se visualizan en la tienda, pero se sincroniza con la central, donde está el servidor. Hasta ahora sólo se generaban pedidos con sus líneas. Ahora, en el momento de realizar una venta, es el propio SQL Server el que obtiene el "próximo número de factura", y guarda una nueva factura con sus líneas en la base de datos central. Después de esto, se envía a este API nuestro el JSON con todo. Ten en cuenta que tenemos dos CIF, y la intención es que toda la facturación esté centralizada (antes iba con tablas separadas), de forma que cada vez que se genera una nueva factura, con su numeración correspondiente, se envíe a nuestro API para obtener TBAI, QR.... Cita:
Cita:
De todas formas, sobre esto he preguntado hace un rato a Hacienda, porque tenemos varias tiendas físicas (sin oficina ni responsables), y no sé exactamente cómo puede ser una visita de un inspector... como si entra al Fnac y le pide a una de las cajeras ficheros TBAI... De todas formas tiene pinta que será como dices, irán a la dirección que sea el domicilio fiscal. Y aquí de nuevo me quedo bloqueado, porque es una de las tiendas.. aunque creo que una de las jefas suele andar por allá, así que ya pensaremos algo En cualquier caso, con lo que me respondan informo aquí, por si le sirve a alguien. Cita:
Saludos! |
#6
|
||||
|
||||
Certificados de firma de código
Buenos días, alguno de vosotros ha utilizado o utiliza Comodo Code Signing, para firmar los ejecutables i/o instaladores de una aplicación de escritorio Windows, para ticketbai ?
Tengo una cotización de LeaderSSL de certificado de organización a 196€ por tres años. Que os parece, alguna alternativa ? Gracias de antemano. |
#7
|
|||
|
|||
Cita:
Me parece que en Bizkaia si es obligatorio firmar los ejecutables, pero en Álava me parece que no. |
#8
|
|||
|
|||
Zuzendu Guipuzkoa
Hola a todos!
Estoy pegandome con el servicio Zuzendu tanto de modificación (modificar/Subsanar) como la baja de Zuzendu, y siempre me lo rechazan con el error "Fichero no cumple el esquema XSD. El elemento principal debe ser SubsanacionModificacionTicketBAI." y "Fichero no cumple el esquema XSD. El elemento principal debe ser AnulaTicketBai.", ¿alguien ha tenido este problema? He revisado el XML con el XSD y lo veo todo correcto... Código:
<?xml version="1.0" encoding="UTF-8"?> <T:AnulaTicketBai xmlns:T="urn:ticketbai:zuzendu-baja"> <Cabecera> <IDVersion>1.2</IDVersion> </Cabecera> <IDFactura> <Emisor> <NIF>XXXXXXXXXX</NIF> <ApellidosNombreRazonSocial>XXXXXXXXXXXXXXXX</ApellidosNombreRazonSocial> </Emisor> <CabeceraFactura> <SerieFactura>V-FAC1</SerieFactura> <NumFactura>XXXXXX</NumFactura> <FechaExpedicionFactura>12/01/22</FechaExpedicionFactura> </CabeceraFactura> </IDFactura> <HuellaTBAI> <Software> <LicenciaTBAI>TBAIGIPRE00000000XXX</LicenciaTBAI> <EntidadDesarrolladora> <NIF>XXXXXXXXX</NIF> </EntidadDesarrolladora> <Nombre>XXXXXXXXX</Nombre> <Version>1.0</Version> </Software> </HuellaTBAI> <SignatureValueFirmaAnulacion>yWMDh71bZ+4ZU9XXXe28HqrJY9QEUB3qsVwJrmxXYQUeKFBAFygZrO0RnPc7WUvQxTXSUi1+n6BAXotZsXGf5rgHxIq84JK0tPgs</SignatureValueFirmaAnulacion> </T:AnulaTicketBai> Última edición por dec fecha: 06-09-2022 a las 18:56:06. Razón: Añadir etiqueta CODE |
#9
|
|||
|
|||
@amontes:
T:AnulaTicketBai es el servicio de anulación. Si miras el XML de ejemplo de Hacienda, el servicio Zuzendu para bajas es así: T:SubsanacionAnulacionTicketBAI A ver si con eso se te soluciona... Por otro lado, la fecha en este formato creo que no es correcta: 12/01/22 Debería ser 12-01-2022. Saludos. |
#10
|
|||
|
|||
Termina de surgirme algo que la verdad no pensé...
Un cliente empezó en Julio, y ha intentado anular una factura que realizó en Febrero (Vamos, no esta subida y no hay datos de ella) Que pongo en: Código:
<CabeceraFactura> <SerieFactura>XXX</SerieFactura> <NumFactura>XXX</NumFactura> <FechaExpedicionFactura>XXX</FechaExpedicionFactura> </CabeceraFactura> Alguna idea? |
#11
|
||||
|
||||
Cita:
|
#12
|
||||
|
||||
Cita:
Digamos que tu sistema sólo debe entrar en el circuito de TicketBAI, para aquellas facturas posteriores a la fecha de alta de tu cliente en TBAI.
__________________
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. |
#13
|
|||
|
|||
Cita:
La tecnica normal es jugar con el bloqueo del numerador ir generando la factura temporalmente y cuando aceptes coger el nuevo número por orden correlativo, si esta bloqueado el numerador dejarlo en bucle reintentado el tiempo que consideres lógico y que bloquee el primero que pueda. |
#14
|
|||
|
|||
Cita:
Lo que he hecho ahora ha sido configurar el programa para que se pueda crear un número temporal. Este número es un número negativo correlativo en la serie y el ejercicio de forma que puedo tener varios documentos temporales. Luego, he creado un procedimiento en la base de datos que busca en el ejercicio y la serie el último número positivo creado más 1. De esta forma, evito los problemas del uso de un numerador. Cuando vaya a imprimir, crear xml, etc., ejecuto el procedimiento que le cambiará el número negativo por el nuevo positivo correlativo y sustituirá la fecha y hora por la del sistema. Ahora crearé un registro con los datos de la factura firmada que se usará para el encadenamiento de la próxima. Muchas gracias a los dos, poco a poco voy resolviendo las dudas. |
#15
|
|||
|
|||
Cita:
Lo que he hecho ahora ha sido configurar el programa para que se pueda crear un número temporal. Este número es un número negativo correlativo en la serie y el ejercicio de forma que puedo tener varios documentos temporales. Luego, he creado un procedimiento en la base de datos que busca en el ejercicio y la serie el último número positivo creado más 1. De esta forma, evito los problemas del uso de un numerador. Cuando vaya a imprimir, crear xml, etc., ejecuto el procedimiento que le cambiará el número negativo por el nuevo positivo correlativo y sustituirá la fecha y hora por la del sistema. Ahora crearé un registro con los datos de la factura firmada que se usará para el encadenamiento de la próxima. Otra duda: Cuando se imprime la factura se imprimen los vencimientos con su fecha. Una vez firmada, si el cliente desea cambiar la fecha de los vencimientos, dividirlos en varios, etc. Puede hacerlo pero, si sacamos un duplicado de la factura ¿los vencimientos nuevos (fechas e importes) que se imprimen deben ser los originales o pueden ser los nuevos? Si son los originales, habrá que buscar el fichero (pdf, o lo que sea) que se creó en su día e imprimirlo en vez de usar el metodo de impresión habitual... Muchas gracias a los dos, poco a poco voy resolviendo las dudas. |
#16
|
|||
|
|||
Cita:
|
#17
|
|||
|
|||
Cita:
|
#18
|
|||
|
|||
Cita:
|
#19
|
|||
|
|||
Cita:
Por lo que veo, diferencias entre emitir la factura (supongo que en tu programa) y firmar el xml. En realidad, tu programa no debería considerar que se ha emitido una factura si no se ha generado el XML y firmado. En mi software, tras grabar la factura físicamente en la bbdd, por así decirlo, se genera el XML y se firma y si no se puede por alguna razón (fallo de certificado, ...), se cancela la transacción y la factura deja de existir internamente. Es la manera de asegurar un encadenamiento correcto. Luego ya esos XML firmados tienes que hacerlos llegar a Hacienda, en mi caso con un servicio de cola de envío independiente al software principal. |
#20
|
|||
|
|||
Cita:
Creo que desde el principio tenía confusión sobre crear, emitir, imprimir, expedir... Ahora todo es lo mismo. |
|
|
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 | 3557 | Hace 1 Semana 17:42:47 |
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 |
|