FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Temas de Hoy |
|
Herramientas | Buscar en Tema | Desplegado |
|
#1
|
|||
|
|||
Certificados de dispositivo
Buenas,
Hacienda foral de Álava tiene lo siguiente publicado https://web.araba.eus/documents/1050...=1644833076809 Cambios en Certificado de dispositivo En breve se va a publicar la nueva política de firma. Que incluye el cambio de certificado de dispositivo. Cambios en el certificado de dispositivo: • Se podrá solicitar identificando un punto de facturación en lugar del número de serie del dispositivo. • Es posible la solicitud de certificados en bloque (hasta 100 certificados). Si desea solicitar certificados de dispositivo en bloque puede recurrir al buzón de contacto TicketBAI de IZENPE. • Se podrá solicitar antes de disponer del dispositivo concreto donde irá instalado. • Se podrá usar en arquitecturas en servidor (excepto Tercero/Destinatario) ➢ El código que identifique un punto de facturación (a indicar en el campo “Número de serie (CN)”) deberá ser único y no haber sido utilizado con anterioridad por ningún otro dispositivo. ➢ Indicar en Fabricante y modelo información significativa que permita al contribuyente reconocer el “origen” del dispositivo que se le propone aceptar. En izenpe no saben nada . Entiendo que van a cambiar la manera de solicitarlos y no tengo claro si habrá solicitar otra vez los que ya tenemos. |
#2
|
|||
|
|||
Perdonar mi ignorancia... Estoy teniendo algunos problemas y no sé por donde van los tiros.
Estoy revisando el tema de las rectificativas, vendo 3 productos y al final me devuelve uno. Envío una rectificativa añadiendo algunos campos: Código:
<FacturaRectificativa> <Codigo>R5</Codigo> <Tipo>I</Tipo> </FacturaRectificativa> <FacturasRectificadasSustituidas> <IDFacturaRectificadaSustituida> <SerieFactura>002024</SerieFactura> <NumFactura>57463</NumFactura> <FechaExpedicionFactura>23-01-2024</FechaExpedicionFactura> </IDFacturaRectificadaSustituida> </FacturasRectificadasSustituidas> |
#3
|
||||
|
||||
Cita:
|
#4
|
|||
|
|||
Buenas!
Tengo un problema con los envíos a Araba. Al parecer han detectado que se han hecho envíos de facturas con una fecha de emisión distinta a la de la firma/envío. Por lo general, nuestro software realiza la firma + envío en el momento de emitir la factura, pero eso no siempre es posible, por muchos motivos: - Factura que no se pudo enviar porque, yo qué sé, se fue la luz en ese momento, o internet, o se bloqueó el PC... - Cliente que lleva tiempo enviando las facturas al entorno de PRUEBAS sin darse cuenta y luego quiere reenviarlas al entorno de producción - Factura creada a partir de varios albaranes y la fecha de la factura es indicada manualmente, que no tiene por qué ser la de hoy. Hasta ahora, Araba (y cualquier otra diputación) aceptada estas facturas con fecha de emisión distinta a la del envío, siempre y cuando no hubiera problemas de encadenamiento. Pero ahora han puesto un aviso/error cuando se detecta una fecha de emisión distinta a la del envío. Y me parece bien. Si no se puede, no se puede. Ese aviso/error debería haber estado activado desde el día 1, pero bueno. La duda es... ¿Cómo hacéis vosotros en estos casos? ¿Permitís a los clientes enviar manualmente facturas "antiguas"? Lo digo porque, según ellos: Cita:
|
#5
|
|||
|
|||
Cita:
Nuestro programa también lo permitía, y recibimos carta de la diputación para que dejara de permitirlo. Lo permitiamos en la facturación de albaranes, por si por error se había hecho la facturación mal, que se pudiera echar para atrás sin tener que crear 200 facturas rectificativas o 200 anulaciones. Sólo las enviábamos a la hora de imprimirlas. Claro, que el cliente, lo mismo no las imprimía y enviaba hasta días después, lo que antes era permitido, y ahora no. La solución que hemos puesto es que según se factura se envía, y si se equivoca, que ande con cuidado o tendrá que repetir la facturación entera. Y enviamos como fecha de expedición, la fecha del momento en que se crea, y fecha de operación, la fecha que el cliente le quiera poner a la factura. |
#6
|
|||
|
|||
Cita:
Pero es verdad que al facturar albaranes, convertir presupuestos en factura, etc. damos la opción al usuario de elegir la fecha de la factura resultante, y quizás ese sea el problema. En cualquier caso, nosotros por ahora sí permitíamos a los usuarios enviar las facturas más adelante. Hay muchísimos casos en los que debería ser permitido, o necesario, para evitar problemas mayores. Pero vamos, que si Araba no lo permite, les remitiré a ellos cuando los clientes se quejen (que lo harán). Mucho va a tener que cambiar España para que se adapte todo el mundo a Veri*Factu cuando entre en vigor, me temo. |
#7
|
|||
|
|||
Cita:
A mí también me está saltando este error y hasta ahora teníamos siempre una sola fecha. A raíz de tener que añadir la fecha operación al xml me salta alguna duda: Esa fecha de operación hay que guardarla también por separado en contabilidad? Tengo que tener en cuenta en los libros de iva esa fecha de alguna forma? Hay que imprimirla en la factura? Gracias |
#8
|
|||
|
|||
Sabéis si también detecta si he hecho la factura a las 23.59 y las envío 2 minutos después? O lo tienen controlado por nunero de horas?
|
#9
|
||||
|
||||
Cita:
En resumen, de cara al IVA, la fecha de operación es la determinante en una factura. |
#10
|
||||
|
||||
Cita:
¿Pero que ocurre si hay un problema a la hora de enviar?, como por ejemplo no funciona internet o hay algún problema con el servidor de hacienda (que ya ha pasado), en ese caso no creo que tenga que generar todas las facturas otra vez, digo yo!. Ya nos ha pasado con varios clientes, enviaré la consulta a hacienda. |
#11
|
|||
|
|||
Cita:
Nosotros tenemos este problema con la opción de nuestro software que permite "facturar/agrupar albaranes". Se genera la factura, pero el usuario puede elegir qué fecha tendrá esa factura. ¿Por qué? Pues porque a lo mejor la empresa solo realiza la facturación 2 o 3 veces al mes, cada 10 días, porque durante todo el mes lo que hace son albaranes. Nuestro fallo es que no tenemos en cuenta la "fecha de operación", sino únicamente la de "expedición". En fin, problemas del siglo XXI... A mi se me ocurren muchos motivos por los que un usuario necesitaría poder enviar manualmente una factura (o 20, o 500) que en su momento no pudieron ser enviadas por el motivo que sea. Dile tu ahora a ese cliente que no puede, que va a tener que presentar un escrito y enviarlas de otra manera... |
#12
|
||||
|
||||
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 | 3557 | Hace 2 Semanas 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 |
|