![]() |
![]() |
| Paypal | FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
|||||||
| Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Buscar | Temas de Hoy | Marcar Foros Como Leídos |
![]() |
|
|
Herramientas | Buscar en Tema | Desplegado |
|
|
|
#1
|
|||
|
|||
|
Cita:
Cita:
|
|
#2
|
|||
|
|||
|
Propongo esta implementación para su discusión, de los casos de emisión de facturas rectificativas agrupados en 5 ítems.
La idea es que el usuario elija la casuística que corresponda y nosotros actuemos en consecuencia, con lo que no queda de la mano de usuario hacer operaciones incorrectas 1. Error en los Datos del Emisor o del Destinatario -> existe el obligado tributario o el Destinatario, pero hay datos incorrectos o faltantes. (Artículos 6 y 7 del reglamento de facturación) a. Factura de Abono – Rectificativa x Sustitución R4 2. Operación que nunca llegó a realizarse -> devolución total de los bienes o Destinatario inexistente a. No es un caso de rectificación contemplado, hay que emitir Factura de Abono 3. Devoluciones y Descuentos a posteriori (artículo 80 de la Ley 37/1992, descuentos y devoluciones) a. Rectificativa x Diferencia R1 4. Correcciones a posteriori de precios, descuentos parciales, tipo de Iva válido pero mal aplicado al producto, descripción del producto a. Rectificativa x Diferencia R4 ó b. Factura de Abono y Rectificativa x Sustitución R4 5. Tipos de impuestos inválidos para el periodo de operación. (Cálculo incorrecto de las cuotas repercutidas https://sede.agenciatributaria.gob.e...ficativas.html) a. Anulación de Factura y Emisión de Rectificativa x Sustitución R4 con bases rectificada = 0 y cuotas rectificadas = 0. (Si emitimos Factura de abono también nos la rechazará por eso propongo anularla primero) 6. Recuperación de Cuotas por impago (artículo 80 de la Ley 37/1992, impagos) a. Factura de Abono y Rectificativa x Diferencia R2 o R3 con las cuotas repercutidas a cero. (No se puede abonar toda la factura) Espero haber contemplado todos los casos, incluidos los que proponían los compañeros |
|
#3
|
|||
|
|||
|
estoy seguro que debe haber una forma de hacerlo todo más fácil y que cumpla la norma, porque casuísticas hay cientos, de hecho es lo que más me preocupa de verifactu.
|
|
#4
|
|||
|
|||
|
Cita:
No estoy totalmente de acuerdo. Si has emitido una factura con los datos del destinatario erróneos (por ejemplo, son los datos de otro cliente), creo que lo más correcto sería anularla. Imagínate que los datos que has puesto del destinatario de la factura son los de un antiguo cliente con el que ya no tienes relación alguna. Creo que sería bastante chungo enviarle una factura normal y otra rectificativa a alguien con quien no tienes ya ninguna relación. Creo que, en estos casos de datos de destinatario erróneos, lo más correcto es anular la factura emitida y hacer una nueva (prestando más atención esta vez) Saludos |
|
#5
|
||||
|
||||
|
Y digo yo..... Con tanta posibilidad de modificaciones/anulaciones/rectificaciones... ¿no es más sano hacer directamente factura de abono por el total y nueva factura con lo correcto?
Saludos.
__________________
Be water my friend. |
|
#6
|
|||
|
|||
|
Cita:
Pues algo de eso hay en la normativa de la Agencia Tributaria: https://sede.agenciatributaria.gob.e...ificacion.html Cita:
Saludos |
|
#7
|
|||
|
|||
|
Cita:
|
|
#8
|
|||
|
|||
|
Cita:
En principio, pienso que no hay por qué ser más restrictivos que lo que dice Agencia Tributaria. Si dejan algo de mano ancha, por poca que sea, hay que aprovecharla. ![]() Saludos |
|
#9
|
|||
|
|||
|
Cita:
(Las facturas rectificativas deben llevar la información de a qué factura rectifican). Y eso no siempre es posible si el cliente no devuelve con el ticket (factura) original. Se pueden dar casos de devoluciones en otro terminal o tienda de la misma empresa donde no se tiene acceso a los datos de la factura original. No creo que en esos casos la Agencia Tributaria pueda poner una objeción a que se haga una factura normal o simplificada de importe negativo y punto pelota. Saludos |
|
#10
|
||||
|
||||
|
Lo digo porque, aparte de otras cosas, creo que al cliente lo mareamos más de la cuenta con tanta posibilidad. No todo el mundo sabe lo que es una factura rectificativa, de abono, por diferencias...etc etc... y es fácil que la líen.
Saludos.
__________________
Be water my friend. |
|
#11
|
|||
|
|||
|
exacto, ese es el principal problema que si dejas al cliente que tenga la posibilidad de hacer muchas cosas con respecto a las rectificativas eso es un problemon para los desarrolladores, el usuario la va a liar si o si y siempre, con lo cual lo suyo sería abreviar todo el tema de rectificativas a lo mínimo y automatizarlo al máximo para que el usuario no manipule, en caso contrario estamos perdidos
|
|
#12
|
|||
|
|||
|
Cita:
|
|
#13
|
|||
|
|||
|
Cita:
Conociéndolo, el comercio no se va a arriesgar a perderlo como cliente por no aceptarle algo que trae con su etiqueta y hasta el recibo de su cargo en tarjeta. El mundo del pequeño comercio (del cual conozco algo) es así. Saludos |
|
#14
|
|||
|
|||
|
Cita:
Si es eso, la obligación de emitir facturas rectificativas nos la pasamos por el forro ?. Nunca habría que emitirlas ? Si lo que quieres decir es que se emite una abono y otro rectificativa con lo correcto, es lo que estamos intentando simplificar e identificar en qué casos, tendríamos que anular o rectificar. |
|
#15
|
|||
|
|||
|
Cita:
|
|
#16
|
|||
|
|||
|
Cita:
La duda que nos surge con la anulación, no sé como lo contempláis vosotros, es si envías un movimiento de Anulación de esa factura, la borramos de la tabla normal de facturas y a continuación la volvemos a crear con el mismo número y lo registramos como un registro de alta con subsanación reemplazando lo que se envió con ese número con la factura correcta que ocupa ese nº, o no es posible reutilizar ese número y toca dejar ese nº ocupado con la anulada en la tabla de facturas y generar la correcta con el siguiente nº que toque? , en el SII es posible la reutilización del nº de la que se envío que no valía, y aquí preguntando al correo de soporte@verifactu nos dijeron que también se permitiría como en el sii, pero mientras no se pueda probar en el servicio web no lo tenemos del todo claro. Como lo planteáis vosotros es esos casos? |
|
#17
|
|||
|
|||
|
Cita:
Efectivamente, en VERIFACTU parece que será como en TICKETBAI: anular una factura impide que pueda volver a utilizarse ese número de factura. La factura existe, aunque ya no tiene valor contable ni fiscal. Saludos |
|
#18
|
||||
|
||||
|
Cita:
Porque me imagino el marron de una persona, que ha pedido explicitamente dejar de tener relacion con nosotros(Caso admitido por la ley de proteccion de datos), pero no hemos anulado la ficha del cliente, por estar en los 5 años que exigen que la mantengamos, y recibe una factura a su nombre, los abogados se ganarian el jornal, seguro. |
|
#19
|
|||
|
|||
|
Cita:
Eso es lo que creo: - Si no se le ha enviado, ya no se le envía porque está anulada. - Si ya se le había pasado la factura al cliente, habría que informarle que la factura está anulada. (Nosotros lo que hacemos, en este caso, es sacar de nuevo el PDF de la factura anulada con el texto cruzado, en letras grandes, "ANULADA") Saludos |
|
#20
|
|||
|
|||
|
Cita:
Del punto de vista del RGPD, no hay problema: hay una ley que te obliga a conservar los datos de este cliente durante estos 4 años enteros más las prolongaciones en caso de investigaciones; y el RGPD no pasa por encima de la LGT; por tanto no hay ninguna falta por tener su nombre en tu sistema; y es posible que aparezcan en una factura emitida por error y debidamente anulada. Si el cliente se queja por qué a él le parece que deberían estar físicamente borrados, lo siento por el cliente pero no tiene la razón legalmente (otra cosa es que comercialmente siga muy poco hábil enviarle tal factura). Lo que si es posible «comercialmente» es avisar al cliente de antemano que al establecer una relación contigo, sus datos personales serán guardados en tu sistema en los términos y plazos que la ley establece; es decir, 5 años después de la última factura. Ahora bien, deben ser estrictamente los datos requeridos por la LGT, nada más, y el plazo se debe cumplir correctamente... pero es otro tema. |
![]() |
| Herramientas | Buscar en Tema |
| Desplegado | |
|
|
Temas Similares
|
||||
| Tema | Autor | Foro | Respuestas | Último mensaje |
| Hijo de Informáticos | gluglu | Humor | 3 | 13-03-2007 11:05:35 |
| Adictos informaticos ... | Trigger | Humor | 2 | 11-10-2004 12:18:32 |
| Nosotros los Informáticos | Trigger | Humor | 1 | 10-10-2004 14:58:09 |
| Patrón de los Informáticos. | obiwuan | Varios | 20 | 10-09-2003 14:44:54 |
| Chistes Informaticos | jhonny | Humor | 2 | 11-08-2003 21:59:09 |
|