FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Temas de Hoy |
|
Herramientas | Buscar en Tema | Desplegado |
#2361
|
|||
|
|||
Cita:
|
#2362
|
|||
|
|||
Cita:
Utilicé el código anterior, pero no puedo completar la firma y no hay cambios en el archivo XML. ¿Hay algo que me haya perdido? |
#2363
|
|||
|
|||
Esta es una función que me he montado en una DLL externa para firmar los XML con las Chilkat, por si te sirve de ayuda. Me base en los posts de Galaxian, aunque haciendo ciertas modificaciones porque tampoco me iban, aparte de que hay que retocar direcciones por vienen, por ejemplo, con h_t_t_p y no http.
Código PHP:
|
#2364
|
|||
|
|||
Aunque pone que es PHP, es Delphi; con el código DELPHI pone emoticonos en ciertas partes del código que lo hacen ilegible, y no permite más de 10 y no se puede subir.
|
#2365
|
|||
|
|||
Pues parece que mi problema con Bizkaia es algo de ellos...
Esta fué su respuesta: Estamos analizando qué ocurre con el certificado de autónomo e intentaremos responderle lo antes posible. ¿Puede utilizar por favor otro certificado para la realización de las pruebas? |
#2366
|
|||
|
|||
Una duda que tengo, cuando analizais el XML comaprado contra el esquema, lo haceis despues de firmarlo ?? si es así y hay un fallo, entiendo que no se puede subir, y que hay que paralizar la facturación o la subida de ficheros hasta que se subsane manualmente entiendo, el error en el xml ?
|
#2367
|
|||
|
|||
Buenas,
Me está ocurriendo lo mismo con un cliente que está en RE y me dice que factura con un 26,2% (21 + 5,2) esto es posible? o simplemente en la factura hay que informar del 21% porque ya les estás diciendo en el campo "OperacionEnRecargoDeEquivalenciaORegimenSimplificado =’S’ " que tiene recargo de equivalencia no? |
#2368
|
|||
|
|||
Lroe 140
Cita:
Muchísimas gracias por compartir tu código. Me gustaría saber si habéis conseguido desarrollar para el modelo 140? Gracias |
#2369
|
|||
|
|||
Envío a Bizkaia
Hola,
Estamos intentando integrarnos con el servicio de envío de facturas de Ingreso TicketBai de Bizkaia. Pero no conseguimos hacerlo con éxito ni con los datos que generamos nosotros ni con los datos de ejemplo que proporciona la diputación. Hacemos un post a pruesarrerak . bizkaia .eus / N3B4000M / aurkezpena Los certificados que usamos son los adjuntos que proporcionan de IZENPE. Los headers de la petición son: Accept-Encoding : gzip Content-Encoding : gzip Content-Length : 412 Content-Type : application/octet-stream eus-bizkaia-n3-version : 1.0 eus-bizkaia-n3-content-type : application/xml eus-bizkaia-n3-data : {"con": "LROE", "apa": "1.1", "inte": {"nif": "B00000034","nrs":"HOTEL ADIBIDEZ"},"drs": {"mode": "240","ejer": "2022"}} ¿Alguna idea de lo que nos puede estar pasando? Muchas gracias |
#2370
|
||||
|
||||
Cita:
El content-Length normalmente no hace falta ponerlo porque se calcula automáticamente, aunque no creo que eso sea el problema. En el ejercicio estás colocando 2022, cuando deberías estar mandando 2021. Por lo demás no veo nada raro. ¿Qué error te está dando?
__________________
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. |
#2371
|
|||
|
|||
Buenos dias, me ha surgido una duda
Nosotros tenemos un programa en el que el cliente puede venir y reservar algo que pagará a plazos. Entonces en el caso de ticketbai, que habría que enviar? Los distintos pagos que hace o el total en el momento de la reserva? No he conseguido ver por ningun sitio como habria que proceder para estos casos |
#2372
|
||||||
|
||||||
Cita:
Gipuzkoa (han copiado y pegado lo que dice Hacienda): Cita:
Es decir, sigo con la misma duda. ¿Se emite o no se emite rectificativa? A mí es que cuando se ponen a hablar de "devolución de mercancías o envases/embalajes" me da la sensación de que no se refiere a ventas minoristas al público, sino más bien a la devolución de mercancía a un proveedor, pero bueno, así son las leyes, ambiguas. Más adelante aclaran lo siguiente: Cita:
Y también dicen esto: Cita:
Esto me dicen desde Araba: Cita:
Cita:
Por no hablar de lo que nos supone a nosotros adaptar los programas para que los cambios y devoluciones vayan en otra serie de facturación distinta. No todos los programas de TPV permiten series de facturación. Además hay que tener en cuenta que cuando hagamos "la rectificativa de una rectificativa", el usuario tendrá que buscar la venta anterior en dos historiales distintos. Y todo esto porque así lo requieren solo 3 provincias. Pero bueno, supongo que estoy un poco cansado de todo esto y quien habla en realidad es el estrés |
#2373
|
|||
|
|||
Cita:
Puedes crear presupuestos, facturas proforma (que no son realmente facturas sino presupuestos), pedidos, albaranes de entrega, recibos, cobros por anticipado, pagos a plazos, pagos en diferido ... o cualquier otro documento. Pero ninguno de ellos tiene nada que ver con TicketBAI. Son temas de contabilidad, pero no de facturación. TicketBAI se aplica sólo a facturas (documentos con nombre factura o factura simplificada y con número de factura y fecha) Saludos |
#2374
|
|||
|
|||
Cita:
Muchas gracias por el esfuerzo y por compartir las respuestas. Pero ya me suponía que no se iban a mojar en el tema. Se remiten siempre a las normativas sobre facturación y les trae sin cuidado cómo lo haga uno (siempre que se envíe el fichero TicketBAI, que es lo que les preocupa a ellos). Creo que no nos queda más opción que seguir haciéndolo como siempre lo hayamos hecho: Si en un programa de facturación se hacían facturas negativas, pues a seguir con el mismo sistema. Si un programa de facturación ya tiene la opción de facturas rectificativas por sustitución o por diferencias (o por las dos) y no implica tener que añadir nada nuevo, pues facturas rectificativas. Pero está claro que TicketBAI no se va a meter nunca con ese tema. Puede ser tema de inspección de Hacienda (aunque un tema menor, como otros muchos de las normativas absurdas de facturación) Saludos |
#2375
|
||||
|
||||
Vizcaya
Hola buenos dias,
enviando "Facturas Emitidas" a Vizcaya (LROE) me da el siguiente error: Código:
<DescripcionErrorRegistroES>La firma no cumple los requisitos de la política de firma TicketBAI.(EPES: S ALGORITMO: rsa-sha256:2048 POLITICA: N CERTIFICADO_ADMITIDO: S )</DescripcionErrorRegistroES> <DescripcionErrorRegistroEU>Sinadurak ez ditu betetzen TicketBAI sinaduraren politikaren baldintzak.(EPES: S ALGORITMO: rsa-sha256:2048 POLITICA: N CERTIFICADO_ADMITIDO: S )</DescripcionErrorRegistroEU> Les he preguntado a servicio tecnico de Vizcaya y su respuesta es la siguiente: Código:
En la firma del fichero TicketBAI no se está especificando el id y el Hash correctamente.En los ejemplos de las especificaciones podéis encontrar cómo indicarlo: <xades:SignaturePolicyIdentifier> <xades:SignaturePolicyId> <xades:SigPolicyId> <xades:Identifier>https://www.batuz.eus/fitxategiak/batuz/ticketbai/sinadura_elektronikoaren_zehaztapenak_especificaciones_de_la_firma_electronica_v1_0.pdf</xades:Identifier> <xades:Description /> </xades:SigPolicyId> <xades:SigPolicyHash> <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256" /> <ds:DigestValue>Quzn98x3PMbSHwbUzaj5f5KOpiH0u8bvmwbbbNkO9Es=</ds:DigestValue> </xades:SigPolicyHash> <xades:SigPolicyQualifiers> <xades:SigPolicyQualifier> <xades:SPURI>https://www.batuz.eus/fitxategiak/batuz/ticketbai/sinadura_elektronikoaren_zehaztapenak_especificaciones_de_la_firma_electronica_v1_0.pdf</xades:SPURI> </xades:SigPolicyQualifier> </xades:SigPolicyQualifiers> </xades:SignaturePolicyId> </xades:SignaturePolicyIdentifier> ¿Alguien sabría indicarme cual es el problema? |
#2376
|
|||
|
|||
Cita:
Es que nosotros generamos ticket (con su numero y fecha) tanto para el momento de la reserva como para los siguientes pagos que se hacen. Entonces eso si que habria que enviarlo, no? |
#2377
|
|||
|
|||
Cita:
Es una currada para los que programamos y para los operadores pero quiero dormir tranquilo. |
#2378
|
|||
|
|||
Cita:
Lo que antiguamente se llamaban "tickets", con el actual Reglamento de Facturación pasaron a llamarse "facturas simplificadas". Las únicas diferencias de una factura simplificada respecto a una factura completa (la normal) son: - En el título del documento debe aparecer "FACTURA SIMPLIFICADA" en lugar de "FACTURA". - No son obligatorios los datos del destinatario (nombre, NIF y domicilio), aunque puede llevarlos - Deben llevar, obligatoriamente, una serie diferente a la de las facturas normales (con su propia numeración) y fecha - Su importe total no puede ser mayor de 3.000 € (y en algunos casos específicos no puede ser mayor de 400 €) - Puede no desglosar base imponible y cuota de IVA en el caso de un solo tipo de IVA y, en ese caso debe incluir la frase "IVA INCLUÍDO" Tienes un resumen de la normativa aquí Saludos |
#2379
|
|||
|
|||
Cita:
a) Cuando el emisor está en RE, al menos normalmente, se informa doblemente este hecho. OperacionEnRecargoDeEquivalenciaORegimenSimplificado=S y ClaveRegimenIvaOpTrascendencia=51. En esta circunstancia no puede facturarse al cliente una cuota de RE y, por tanto, no cabe indicar un 26,2% de impuesto. b) Si el emisor no está en RE: Entoces sí se puede cargar ese 5,2% adicional de RE al cliente que esté incluido en el ámbito de RE pero OperacionEnRecargoDeEquivalenciaORegimenSimplificado=N y ClaveRegimenIvaOpTrascendencia=01 (o lo que sea, pero no 51). Al menos, con carácter general. Ten en cuenta que no tengo ni idea de temas fiscales :-( |
#2380
|
|||
|
|||
Cita:
|
|
|
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 |
|