|
Cita:
Pero es bueno saber esto en caso de errores. Un saludo!! |
Cita:
|
Cita:
Hoy durante la mañana he probado y parece que ya funciona. https://pruebas-ticketbai.araba.eus/...&i=2.42&cr=222 |
Cita:
Hasta que no se aclaren no vamos a decidir si enviar de sustitución modificación o lo que sea. Por qué cada día te vienen con una nueva. No se si a vosotros os pasa lo mismo. Un saludo. |
Araba me vuelve a funcionar
Cita:
|
Enviar/Anular
Cita:
Saludos |
Cita:
Cómo lo hacéis? |
Cita:
Ojo, anular una factura no es eliminarla. Le ha llegado a Hacienda Foral la factura original y le llega la anulación, por lo que es legal. Y se puede anular por muchas razones. Hay casos en los que se debe emitir una nueva factura (por ejemplo porque la que se ha anulado contenía errores graves) y hay casos en los que no se debe hacer otra factura (por ejemplo porque el cliente se echó atrás y, al final, la operación no se realizó). Saludos |
Cita:
No se puede anular una factura que no ha sido aceptada. Si lo intentas, creo recordar que el sistema devuelve un error diciendo algo así como "que la factura no está en el sistema". |
Cita:
Legalmente anulación y rectificativa son conceptos diferentes, otra cosa es que dentro de tu programa puedas solventarlo todo con rectificaivas. Imagina que facturas por un servicio que finalmente "nunca se realiza". Ese caso es, en el que se debe anular, porque no puedes rectificar una factura que inicialmente ya no era válida. Ese es un caso claro de anulación (al menos legalmente). Otra cosa es que en tu programa hagas una rectificativa y el resultado a efectos contable sea el mismo. No creo que pase nada y además es una situación que no se va a vdar casi nunca (no debería). Cita:
|
Cita:
|
Cita:
- Si hay que anular el 100% de una factura ordinaria se deberá cursar una rectificativa. - Tampoco pensamos implantar Zuzendu hasta que se normalice la situación y se aclaren, nos están mareando sin compasión... |
Hola a todos.
Anular una factura no supone borrarla, supone que le indicas a hacienda que no vale. La factura sigue existiendo. No se salta la normativa de facturación. Como ha indicado algún compañero hay en ocasiones que una factura no se puede rectificar, como por ejemplo si te has equivocado de cliente. Si haces una rectificación por este motivo, hay que enviar al cliente erroneo dos facturas, la original y rectificativa. Y si el cliente no se había enterado de nada no creo que le haga mucha gracia. Pero Bueno cada uno es su programa hace lo que cree conveniente. ;) |
Cita:
En el caso que comentas, si has hecho una factura a un cliente erróneo que has enviado a TicketBAI, vuelves a hacer otra rectificativa al mismo cliente erróneo en negativo. Ambas se envían a TicketBAI, no al cliente claro... |
Cita:
|
Cita:
Factura de cargo de +100, rectificativa de -100 => cero, la operación no aparecerá a efectos del 303, 390, 347... Cumplimos con el reglamento de facturación, con TicketBAI, con el SII, la contabilidad cuadra y todos somos razonablemente felices :D |
Yo creo que si generas una factura errónea y para corregirla generas una rectificativa, aunque el resultado sea 0 debes enviarla al cliente. Eso es lo "raro" frente a anular como comenta keys.
Pensad que habrá un momento en que todas las facturas, tanto de emisor como de receptor, tendrán que ser enviadas (y es de suponer que la hacienda correspondiente las cruzará). El cliente estará recibiendo una factura errónea, una rectificativa de la factura errónea y además le estará obligando a introducirlas ambas en su sistema (y a enviarlas -en un futuro-) puesto que son facturas que están registradas en la administración por el emisor. No se si me explico... De todas formas son casos muy puntuales, a no ser que alguien se equivoque mucho generando facturas. Cosa que a lo mejor es sospechosa por otros temas... :cool::cool::cool: |
Cita:
Como dice el compañero las anulaciones son casos puntales o el usuario es un cazurro. |
Probar los servicios de TicKetBai con Soap UI
Hola,
Sabéis si se pueden probar los servicios web de ticket bai con el Soap UI?? Yo probaba los servicios web soap a partir de un wsdl, pero en los servicios rest parece que no existe. Y no sé si se puede hacer con el Soap UI para los servicios web. Si tenéis algún enlace de cómo hacerlo os lo agradezco. Gracias |
Cita:
Desde mi humilde punto de vista, es más transparente y trazable las facturas de cargo y abono, aunque quede "raro" no enviarlas al cliente. Pero hay que admitir que también es "raro" y sospechoso la existencia de huecos o "facturas marcadas como anuladas" :rolleyes: ... Hoy en día, con la normativa vigente, ante una inspección tributaria, prefiero no tener que justificar huecos en la numeración de facturas de venta... |
Cita:
|
Hola,
Ya se ha abierto el plazo de presentación de observaciones al proyecto de RD del Reglamento de Digitalización Facturación por parte de la Agencia Tributaria. Podéis ver el texto en https://www.hacienda.gob.es/Document...talizacion.pdf La cosa va a traer cola ... para nosotros. Saludos |
Cita:
¡Hala!, aquí está la solución de toda la vida: Oiga, que yo no sé usar un aparato de esos tan modernos y eso de interné qué es:  |
Cita:
Voy a copiar este mensaje al hilo sobre la ley antifraude para programas informáticos, que creo que es más adecuado. |
Muchas gracias.
Esto parece que es como el TicketBAI que han sacado en las forales. Cita:
Cita:
Pero habrá que seguir esperando a que desarrollen la ley. |
Por lo que he leído es replica de ticketbai y le añaden más movidas sobre todo el Registro de instalación, actualizaciones y eventos con garantía de inalterabilidad y trazabilidad así que a currar un poco más no nos vayamos a quedar dormidos.
|
Cita:
¿Lo solucionaste al final? Es que me acaba de pasar lo mismo con sus certificados, no he tocado nada en le firma y he comprobado que la codificación es UTF-8. De todos modos les he enviado correo, cualquier cosa os digo. Gracias de antemano como siempre. |
Responsabilidad del desarrollador y baja de un cliente
Últimamente la Hacienda de Gipuzkoa nos está enviando correos avisándonos de fallos en el envío de ficheros realizados con nuestra aplicación (no nos dice si son envíos de pruebas o de producción, o nuestros o de algún cliente).
El caso es que nos hemos planteado la siguiente cuestión y me gustaría saber vuestra opinión: ¿qué ocurre cuando un cliente se da de baja? Nuestro modelo de negocio es tipo 'renting': el cliente paga por el uso de la aplicación, soporte técnico, actualizaciones, etc. pero cuando se da de baja no le cortamos el uso de la aplicación: se queda sin soporte ni actualizaciones. En estos casos, cuando por ejemplo TicketBAI implemente nuevas validaciones o cambie la versión del XSD, ¿nos seguirán comunicando errores en los envíos? ¿seguimos siendo responsables del (mal) uso de la aplicación que pueda hacer el cliente? Lanzo esta reflexión a las ondas... |
Hola,
Pregunta sencilla, más fiscal que de programación. Las facturas simplificadas deben de ir obligatoriamente en una serie de facturas especifica para ellas, o basta con marcar una opción en la factura y que vaya a la serie normal? Gracias |
Cita:
Saludos |
Cita:
Es como si decide no comprar ninguna aplicación y no enviar facturas, es problema suyo. La parte buena de incluir en las aplicaciones tema "legales" (SII, Modelos de hacienda, TicketBA, ley antifraude,...) es que de alguna manera tenemos "cogidos" a nuestros clientes con las actualizaciones. Si se diseña bien el modelo de negocio, puede ser una forma de fidelizar a los clientyes, aunque en contrapartida tenemos cambios continuos y hay que lidiar con las administraciones. |
Cita:
Debido a labores de mantenimiento, desde ayer a la tarde la validación de la firma estaba fallando y se ha decido deshabilitar temporalmente (a las 10:50) dicha validación, por lo que ahora ya no os debería dar error en la firma. La que nos espera. |
Cita:
|
Cita:
En principio, leyendo detenidamente el Reglamento de Facturación no parece que deban ir, obligatoriamente, en series diferentes. Pero hubo una Resolución Vinculante de la Dirección General de Tributos que interpretó que sí debían ir en series diferentes: https://www.iberley.es/resoluciones/...6-2016-1439218 Aparte, si es simplificada, debe llevar en el XML del TicketBAI marcada la correspondiente opción: Código:
<FacturaSimplificada>S</FacturaSimplificada> |
Cita:
Si por motivos de falta de pago se deja al cliente sin mantenimiento de la aplicación, creo que es muy importante comunicárselo al cliente, por escrito, para que quede constancia. El cliente es responsable del uso que haga de la aplicación. Pero el desarrollador del software garante se hace responsable de que la aplicación cumpla la normativa, de que se corrijan los errores que vayan apareciendo en la misma y de que se actualice cuando la normativa vaya cambiando. En todos los ficheros TicketBAI aparece el NIF del desarrollador del software garante y su licencia. Así que mejor cubrirse las espaldas. Saludos |
Cita:
Pero si en esa web en vez de subir los archivos pego el contenido de XML y XSD me indica que si cumple el esquema. ¿Podrias por favor indicarme como solucionaste tu problema? |
Cita:
A la único que "obliga" el reglamento de facturación es a diferenciar la serie de rectificativas. Y lo pongo entrecomillado porque el 90% de las empresas que me he encontrado lo meten todo a saco a una sola serie, y no me consta que se les haya multado en inspecciones tributarias por este motivo, aunque se trata de una falta. |
Cita:
|
Cita:
En el fichero la primera línea está así: <T:TicketBai xmlns:T="urn:ticketbai:emision" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.w3.org/TR/xmldsig-core/xmldsig-core-schema.xsd"> Y debería ser así: <T:TicketBai xmlns:T="urn:ticketbai:emision" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:ticketbai:emision ticketBaiV12.xsd"> Es decir, la última parte es lo que veo diferente de los envíos que hago yo, y que en mi caso son aceptados. Espero que te sirva de ayuda. |
Hola a todos.
¿Alguien esta haciendo el modelo 140 entero? Hay una serie de capitulos que no estan funcionando aún. Como el 6 de provisiones y suplidos y el 7 Otra información con transcendencia tributaría. El 7 no importa tanto ya que es para final de año, ¿pero el 6?, que estais hadiendo en este caso. Un Saludo. |
| La franja horaria es GMT +2. Ahora son las 16:52:32. |
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