|
Cita:
No sé cómo piensas orientar el tema de las bajas pero yo lo veo peliagudo. Primero te crea problemas para manejar ese dato en la misma tabla de facturas (como ya estás comprobando) y segundo que no creo que sea muy recomendable anular facturas. Si te sirve de algo yo he optado por no dejar anular facturas y en cambio generar facturas rectificativas. A partir de una factura determinada que se quiera modificar por algún motivo creo en memoria una copia para hacer los cambios que se quieran y si se aceptan muevo la factura original a otra tabla y se queda la rectificada con un nuevo número de otra serie. Si lo que se quiere es directamente eliminar la factura lo que hago es un abono. Este proceso, como tantas cosas, es discutible pero creo que es legal y no me marea mucho el programa. Saludos. |
Esto es como todo, en enviar pregunta y se aparece la iluminación divina....
Tratar el indice principal con un autoincrement y un secundario mantenido con número de factura. Pasa que no soy muy amigo de los autoincrement, pero como no afecta a los datos, me daría igual que este variara en cualquier momento y por cualquier motivo. El problema es que no se a nivel de aplicación como me afectaría, en la busqueda de facturas. J...r estoy encasquillado con el tema. |
Cita:
Gracias Darkdudae y Newtron por los aportes. |
Cita:
Nosotros tenemos en la tabla de facturas un campo de ESTADO, que en un momento dado nos marca si la factura está ANULADA (y otros estados por los que puede pasar). Por otro lado, tenemos una tabla de RegistrosDeFacturación, donde se almacena un registro por cada operación que se le realiza a una factura, y por lo tanto podemos tener varios registros (sobre la misma factura): ALTA MODIFICACION MODIFICACION ANULACION Además, esa segunda tabla se puede consultar, para acceder rápidamente al "historial" de una factura y debe permitir descargar el RegistroDeFacturación de cada factura.  |
Vamos a ver si entendi lo de las bajas, como creo que lo he entendido siempre. bajo la experiencia del SII
Las bajas son una factura mas para la AEAT, tiene su huella: la que tuvo durante el alta y encadenamiento. Cuando das de alta una nueva siguiente a la baja la encadenas con ella y listo. El lugar de la baja no se puede ocupar porque dara error 3000. ¿esto es asi? lo unico que tienes que marcar es un flag en el archivo de facturas que te indique cual es su estado, sin mas. Saludos Nota: gracias a la demo de darkdudae, el componente con total seguridad abandonara el servidor de mensajes, y pasara a funcionar bajo DLL. No hay que modificar nada en el código de los programas que usan el componente. La semana que viene lo publicare. |
Cita:
Código:
Id N.Factura Fec.Factura Operacion NotificadaCita:
Gracias. |
Cita:
Por ejemplo, en cada registro de facturación tengo el HASH, tengo el contenido del registro en formato XML,... En esa tabla me lía un poco las fechas que has puesto. En cuanto al encadenamiento, se va haciendo con el último RegistroDeFacturación generado, digamos de forma conológica (independientemente si lo último ha sido un alta, una subsanación o una anulación). Cita:
Y tal como pone la documentación se debe poder ver o descargar el registro de facturación (XML), por eso lo guardamos tal cual en un campo. |
Cita:
|
Cita:
|
Cita:
En cualquier momento esos XML se deen poder acceder y descargar. https://sede.agenciatributaria.gob.e...generales.html |
Cita:
Pienso que lo ideal a parte de quizas guardarlo en disco en una carpeta, con un nombre serializado, seria incluirlo en una tabla con un codigo y desde la factura(s) enlazarlo, con dos campos binarios, uno para el envio y otro la respuesta. Saludos ! |
Cita:
Tengo una tabla llamada: verifactu_logcomunicaciones con la siguiente estructura: Código:
ID (Autonumérico Entero) |
Cita:
Código:
<sum1:RegistroAlta xmlns:sum1="https://www2.agenciatributaria.gob.es/static_files/common/internet/dep/aplicaciones/es/aeat/tike/cont/ws/SuministroInformacion.xsd">Este es el ejemplo de la aeat. Y de la respuesta lo mismo , puedes deserializar los nodosde la respuesta por separado y almacenar solo el resultado de ese nodo en particular. Seleccionas el nodo correspondiente a tu factura. Código:
<RespuestaLinea> |
Cita:
Tecnicamente me gusta la idea, si x favor, me cedes el código para hacerlo lo incluyo en el componente, y que el usuario seleccione lo que desea archivar. El componente ya no necesita de una aplicacion servidora, funciona bajo DLL, e incorpora bastantes cambios, incluyendo una demo muy mejorada. El fin de semana lo publicare. Las aplicaciones ya desarrolladas usandolo no van a necesitar cambio alguno. Saludos ! |
Cita:
Ojo que son cosas diferentes. RegistroDeFacturación: Nos referimos a la información referente a 1 factura (en formato XML), que va firmada o no dependiendo si estamos en Verifactu o no-verifactu. Otra cosa es el envío (sólo en la modalidad verifactu). en el envío cómo han dicho pueden ir 1..1000 registros de facturación incluídos. El RegistrodeFacturación es el que hay que guardar de forma obligatoria y debe ser accesible y descargable. La información del envío, no es obligatorio guardarla, y cada uno puede decidir cómo y qué guardar (para luego gestionar toda esa lógica desde el programa). Si guardar todo el paquete (con las 1000 fcaturas), si guardar la respuesta en el formato que la da la AEAT, si guardar sólo los códigos,... |
Cita:
Vale, sin intencion de hacerme el pesado, en tu opinion, (porque me acabo de enterar ahora) si guardamos todo el envio, asociado a cada factura, ¿estariamos cumpliendo? porque tecnicamente la informacion del registroDeFacturacion se encuentra alli. Encontrarla es tan facil como hacer una busqueda de texto. Opcion 2: Me gustaria poder sacar esa informacion del XML de envio, a ver si me podeis hacer llegar ese codigo ( bmfranky ) para incorporarlo. ¿Puedes por favor neftali resumir brevemente que es necesario guardar y disponer en un sistema verifactu? porque en el foro la informacion esta muy dispersa, para ver que le falta al componente y como incorporarlo. gracias ! |
Extraído directamente de la documentación de la AEAT (cuestiones generales):
Capacidad de exportar los registros Todos los sistemas informáticos de facturación producidos y comercializados deberán tener capacidad de exportar y transmitir en línea los registros de facturación. Cuando la modalidad elegida sea NO VERI* FACTU, en caso de que se requieran por parte de la Administración Tributaria dichos registros, los mismos podrán ser directamente enviados a través de un procedimiento simplificado y automatizado. La transmisión: Verifactu: La transmisión es inmediata No-verifactu: deben implementar la transmisión de registros bajo requrimiento. Capacidad de exportar. Yo creo que no deja dudas, desde el programa hay que poder exportar un registro de facturación. El cómo lo hagamamos ya es cuestión de cada uno. Digamos que en nuestro programa tenemos FACTURAS, para cada factura sabemos que hay 1..N REGISTROSDEFACTURACION (alta, subsanación, anuulación). Nosotros hemos barajado varias opciones: * Desde la factura exportar todos los registros asociados a esa factura (1..N) * Desde la facttura, acceder a sus registros de facturación (1..N) -es como ver el historial de las operaciones sobre esa factura- y desde ahí poder exportarlos 1 a 1. |
Cita:
Yo creo que es más sencillo enfocarlo a cada registro de facturación que enfocarlo al envío. Al grabar la factura DEBES generar el registro, por lo tanto creo que en ese momento es el punto fácil para guardarlo. También puedes enfocarlo al envío, pero creo que es más complejo a la hora de recuperar los registros. Pienso en que si has hecho varias operaciones sobre una factura (ALTA, SUBSANACION, ANULACION) si queres obtener todo la información de esa factura (y sus registros de facturación) vas a tener que ir navegando por diferentes envíos e ir extrayendo de cada uno de ellos el registro de facturación correspondiente a esa operación. Se puede hacer, pero creo que es más complejo. |
Cita:
El plan desde mi ignorancia es enviar, guardar el XML completo y mediante alguna funcion extraer cada registrodefacturacion procesado para las facturas aceptadas. Si alguien tiene ese codigo para extraer una seccion del XML dado el numSerie de la factura, me evitaria trabajo de investigacion, o que se quedara pendiente. Con Darkduae estamos mejorando la demo y el parseo de la respuesta de la AEAT para cubrir mas casos. |
Cita:
Creo que hay varios mensajes donde está cómo hacerlo. Por ejemplo este, genera el registro con SOAP y en un momento dado extrae el XML del registro de facturación. https://www.clubdelphi.com/foros/sho...postcount=1428
|
| La franja horaria es GMT +2. Ahora son las 06:21:58. |
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