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.

Pues mira creo que tienes razón newtron, yo opté por esa opción en un principio, pero al verlo tan sencillo para el usuario, anular y volver a enviar un nuevo alta, "el empecinamiento creo que es mi mayor enemigo" y no me deja ver con claridad. Y creo que así se va a quedar, error -> abono y vuelta a empezar, que se fijen antes de facturar y ya vendrán mejores tiempos, e un mondo difichile!!, que nuestro trabajo no está pagado.

Gracias Darkdudae y Newtron por los aportes.

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.

Hola Germán. Esa segunda tabla podría tener esta estructura, partiendo los envios desde la misma


Esto me ha dejado muerto...
Gracias.

Similar a la que tengo yo, aunque en la mía hay más campos.
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).


Digamos que tenemos una pantalla que muestra todos los registros de facturación dedicada a posibles inspecciones. Desde esa pantalla puedes buscar una fcatura y deberías ver su "historial" y su estado actual (todas sus operacion o registros de facturación); La mayoría aparecerán 1 vez como Alta aceptada, pero también podrás encontrar un Alta + Baja o Alta + Modificacion + Modificación + Baja,...

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.

Con el “registro de facturación” en XML te refieres a la respuesta que devuelve Hacienda o a una suerte de “Factura Electrónica” con los metadatos de la factura?

No se si me he perdido algo, pero si le meto una huella incorrecta en el encadenamiento del registro anterior se lo traga sin error. ¿Es esto normal?.

El registro de facturación es el fichero XML que debemos generar para cada factura (en realidad uno para cada alta, modificación o anulación). Si estamos en Verifactu, ese fichero/XML se envía, si estamos en NO-Verifactu, ese XML se firma y se guarda.
En cualquier momento esos XML se deen poder acceder y descargar.

https://sede.agenciatributaria.gob.e...generales.html

bueno en el caso de verifactu en ese xml de envio no ira solamente 1 factura, pueden ir docenas.

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 !

Es justo como lo estoy planteando yo en mi sistema.

Tengo una tabla llamada: verifactu_logcomunicaciones con la siguiente estructura:

Como al hacer un envío nos devuelve un CSV, y este CSV yo lo guardo en la tabla verifactu_registrofacturas cuando hago un envío, pues simplemente relaciono esos dos campos y ya tengo el XML de envío y de recepción de cada una de las facturas a nivel individual y/o colectivo.

Hola, pero puedes perfectamente guardar solo el XML de la factura, no hace faltya que sea del envio completo, es mas lo que se guarda en el no verifactu es exactamente eso , solo el nodo RegistroAlta, por ejemplo.


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.

Buenos dias,

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 !

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,...

Opcion 1:
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.

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.

Al grabar la factura, la coloco en el objeto de la AEAT y no puedo o no se, recuperar ese XML parcial hasta su envio.

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.

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

Código Delphi [-]
...
 try
   newNode := Factura.RegistroFacturacion.ObjectToSOAP( ARootNode, ARootNode, MOPToSoapDomConvert, 'RegistroFacturacionType',
   Swdsl,'T',[ocoDontPrefixNode,ocoDontPutTypeAttr], RefId  ); //ocoDontPrefixNode

   XML.DocumentElement := ARootNode;
   XML.XML.SaveToFile('RegistroFacturacion.xml',TEncoding.UTF8);
   XML.Active := False;

 Except
   On E : Exception do Begin
    Showmessage(E.Message);
    XML.DocumentElement := ARootNode;
    XML.XML.SaveToFile('RegistroFacturacionError.xml',TEncoding.UTF8);
    XML.Active := False;
 End;
 ...

Perfecto, he visto el ejemplo de Delphier publicado al que agradezco su colaboracion, y ya funciona, a ver ahora como lo implemento en el componente. Pero esto ya esta. gracias !

Yo por lo que he podido ver en algún otro programa, he querido entender que las exenciones pueden incluso ir a nivel de apunte.

Eso sería bueno que nos lo aclarara alguien que estuviera más "ducho" en temas contables/fiscales.

No es lo mismo productos al 0% de IVA que productos "exentos" de IVA, como en su momento creo que eran las mascarillas y cosas de "esas".

en la nueva version DLL hay un array para procesar exenciones, sin la automatizacion del array de ivas, con lo que quedaria solucionado. Eso si, hay que saber de fiscalidad para que el programa lo coloque corectamente. La nueva implementacion supera con creces la anterior.

Pero ese es el problema, yo al menos no se tanto de fiscalidad como asegurar que se estan generando bien los xml.

seria necesario y esto es una llamada de auxilio XD

un juego de XMLs para los casos principales, automatizados por el componente para verificar.


y otro despues para los menos comunes.

Pero sin eso aunque tecnicamente el componente funcione, estamos vendidos.

Hola buenas tardes.
Al procesar la respuesta resultado.facturas[j].tipoOperacion me está devolviendo "SistemaFac" cuando la factura contiene algún error y es rechazada.
Si la factura es correcta y es admitida resultado.facturas[j].tipoOperacion devuelve "Alta".
Solo proceso una factura y utilizo este dato para identificar en el registroFacturación la operación de la factura a la que se refiere y actualizar su estado, movimiento.

En operaciones Baja declaradas en el registroFacturación obtengo un Access Violation en el módulo msgVerifactu.exe. He probado como fecha de factura la fecha actual y la propia fecha de la factura que se da de baja, pero no se, obtengo el mismo resultado. Voy a darle un vistazo a ver si soy capaz de encontrar el problema.

Al final creo que entiendo el sistema y tengo todo el tema de comunicaciones en una tabla independiente llamada RegistroSIF con las operaciones de cada una de las facturas (Alta, baja, modificacion, etc) que se relaciona con la tabla de cabeceras de facturas. Si genero una baja entra en RegistroSIF como baja y la cabecera de factura tambien la pone como baja. De esta forma puede tener una factura distintos movimientos o estados FR250056 ALTA y FR250056 BAJA. Gracias a los que me aclarasteis mi monumental lio mental.

Un saludo,

Esta pendiente el cambio a la version DLL, asi a bote pronto recuerdo que la baja daba error.

En cuanto lo publiquen en el FTP, que ya tienen el enlace, lo readaptas y vuelves a probar

Estos son los cambios de la nueva version , donde tambien ha colaborado el usuario darkdudae, a quien agradezco su trabajo.
(Algunos de ellos estan sin comprobar).


Saludos !

Aun asi puedes (y deberias) procesar la factura con

resultado.facturas[j].OK
y una vez OK entonces mirar tambien: resultado.facturas[j].aceptadoConErrores

tipoOperacion: Probablemente cuando es procesada la factura delphi interpretara ese valor dentro de los enum de tipo de operacion, muy probablemente en el campo XML no venga indicado si quiera. Si quieres postea el XML de resultado cuando ocurre eso. Ya adeverti que hace cosas raras cuando no hay valor un campo enum. quizas sea el caso.

Ver ejemplo en la demo:

En el FTP del clubdelphi ya está la última versión del proyecto con códo el código fuente incluído y todo lo que necesita.
De nuevo, desde aquí agradecer a [seccion_31] la aportación y la colaboración y aportes de [darkdudae].

Este es el XML del que intento localizar el tipoOperación de la factura para con ese dato y el numero de serie actualizar el RegistroSif para que indique que hay algo con error actualizando el codigo y la descripción del mismo para información del usuario (devuelve SistemaFac). Ojo los datos fiscales los he alterado en el nodo ObligadoEmision

en uVeriFactuFuncs

asi rapido

linea 1829 -31 aproximadamente, pone:

Código Delphi [-]
sesiones[sesion].resultado.facturas[n].tipoOperacion   :=getEnumName( TypeInfo(TipoOperacionType), ord(res.RespuestaLinea[ j ].EstadoRegistro ) );

y deberia poner:

Código Delphi [-]
            sesiones[sesion].resultado.facturas[n].tipoOperacion   :=getEnumName( TypeInfo(TipoOperacionType), ord(res.RespuestaLinea[ j ].Operacion.TipoOperacion ) );

Recompila la DLL y ya

Nota: no lo he probado. Cuando este confirmado que funciona, y haya pasado algo mas de tiempo volvere a publicar otra version.

Saludos !

He encontrado un bug en el componente si el evento OnRegFac no está asignado antes de hacer un envío (lo cual causa una excepción).
En la demo este error no se muestra debido a que creamos el componente VeriFactuD7 en runtime, así como le asignamos dicha propiedad.

Para solucionarlo, debemos cambiar el código del componente (uVerifacu):

Debemos cambiar este código:

Código Delphi [-]
procedure _callbackRF(filehandleMap:longint);   stdcall;
var
  callback_RF_info:TFileHandledRecordCall;
begin
    try
      loadFileMappingData(@callback_RF_info, sizeof(callback_RF_info), filehandleMap);
      callBacksVeriFactus[callback_RF_info.sesion].FOnRegFac(callBacksVeriFactus[callback_RF_info.sesion]  ,callback_RF_info.numSerieFactura, callback_RF_info.streamXML );
   except
    ON E:Exception do
    begin
      ShowMessage('Error excepcion: '+E.Message);
    end;
   end;
end;

Por este otro en el que nos aseguramos que el evento esté asignado:

Código Delphi [-]
procedure _callbackRF(filehandleMap: longint); stdcall;
var
  callback_RF_info: TFileHandledRecordCall;
  callbackObj: TVeriFactu;
begin
  try
    loadFileMappingData(@callback_RF_info, sizeof(callback_RF_info), filehandleMap);
    
    callbackObj := callBacksVeriFactus[callback_RF_info.sesion];

    if Assigned(callbackObj) then
    begin
      // Verificar si el evento FOnRegFac está asignado antes de llamarlo
      if Assigned(callbackObj.FOnRegFac) then
        callbackObj.FOnRegFac(callbackObj, callback_RF_info.numSerieFactura, callback_RF_info.streamXML)
      else
        OutputDebugString(PAnsiChar('Advertencia: El evento FOnRegFac no está asignado.'));
    end
    else
      OutputDebugString(PAnsiChar('Error: callBacksVeriFactus[' + IntToStr(callback_RF_info.sesion) + '] es nil.'));
    
  except
    on E: Exception do
      ShowMessage('Error excepción en _callbackRF: ' + E.Message);
  end;
end;

Es posible que tengáis que desinstalar y volver a instalar el componente tras el cambio.

Un saludo

La modificación funciona perfectamente. Las Bajas o Anulaciones que tambien tenía problemas funcionan tambien. Gracias seccion_31.

Actualizada la última versión en el FTP del club.
Gracias a todos.

lo que falta por probar y creo que NO funciona, son las anulaciones de facturas que no tiene verifactu.

Saludos !

Y es una lastima que falten colaboraciones para depurar, ofrecer ideas, validar los XML y mejorar el codigo, este componente podria solucionar implantaciones "habituales" de verifactu sin mucho problema, en uno o tres dias de trabajo, puedes tener una instalacion verifactu funcional.

agradecer a darkdudae por su colaboracion.

Muchas gracias por los aportes,

Si me indicas en qué parte focalizar y puedo ayudar lo hago.

Yo trabajo con Delphi 12 y tengo problemas con los WDSL que vienen y necesito regenerarlos de nuevo con SOAP 1.2

Personalmente lo que estoy haciendo es modificar el código para quitar el componente y la DLL, dejando el sistema en solo código "plano" para poder usarlo en modo web y no en Windows

Buenas compañero. Es posible que una factura rechazada no puedas anularla porque no exista en sus registros.


Saludos.

hola carlos_mz

habria que tratar de subir una baja de factura, que no se encuentre en verifactu, y ver que pasa. en teoria puedes anular facturas que verifactu no ha almacenado. A mi no me funciono y lo deje aparcado.

verificar que en consulta, los datos que devuelve si son correctos para cada tipo de factura. en especial desgloses de iva, y exenciones.

por otro lado

generar un XML de cada tipo de factura, incluida canarias, quitas tus datos y vemos aqui en el foro si estan OK.

Eso se me ocurre como lo mas inmediato, si tienes tiempo miras lo que puedas.

Saludos !

hola !

no es una factura rechazada, es una factura anterior a la implantacion de verifactu, digamos de unos dias antes de su entrada en vigor. que yo recuerde en la documentacion dice que se puede.

: )

Os adjunto cómo sería el registro enviado. Y que posteriormente me lo han aceptado.


Pueden ser facturas antiguas, que modificas o borras (anteriorres a la activación). También una factura que se ha rechazado por algún motivo y que luego borras.


Creo que pueden ser ambos casos; Se marca el registro de anulación como SinRegistroPrevio.

gracias Neftali

viendo el codigo me doy cuenta de que "creo" que lo tenia mal planteado el sinRegistroPrevio

hay un "if" por medio que creo no estaba bien situado lo he movido. No lo he probado todavia.

Quedara para la 1.2

Saludos !

Buenas, no sé si era esto lo que me pediste:

Respuesta envío factura normal con 21%
Respuesta envío Canarias