Ley antifraude 2021 (VERIFACTU) - Programas informáticos

[ramherfer]

Empezado por Neftali [Germán.Estévez]

A mi los tres ficheros generados con esas opciones me resultan similares.
Completando el código que has puesto, la llamada podría ser similar a esta:

Código Delphi [-]
procedure TForm3.Button1Click(Sender: TObject);
var
  arrayDetalles : array of DetalleType;
  RegistroAltaFacturas: Array_Of_FacturasEmitidasType;
begin
  var alta:AltaFactuSistemaFacturacion := AltaFactuSistemaFacturacion.Create;

  // Cabecera
  var cab := Cabecera.Create;
  cab.IDVersion := VersionType._1_0;

  cab.ObligadoEmision := PersonaFisicaJuridicaESType.Create;
  cab.ObligadoEmision.NombreRazon := 'Empresa pruebas';
  cab.ObligadoEmision.NIF := '11111111H';
  cab.TipoRegistroAEAT := TipoRegistroAEATType.T0;
  cab.FechaFinVeriFactu := '01/01/2026';
  alta.Cabecera := cab;

  // Factura
  var fact:FacturasEmitidasType;
  fact := FacturasEmitidasType.Create;
  fact.RegistroFacturacion := RegistroFacturacionType.Create;
  fact.RegistroFacturacion.IDFactura := IDFacturaExpedidaType.Create;
  fact.RegistroFacturacion.IDFactura.NumSerieFacturaEmisor := '23/123456';
  fact.RegistroFacturacion.IDFactura.FechaExpedicionFacturaEmisor := '31/12/23';
  fact.RegistroFacturacion.IDFactura.IDEmisorFactura := IDEmisorFactura.Create;
  fact.RegistroFacturacion.IDFactura.IDEmisorFactura.NIF := '3333333';
  fact.RegistroFacturacion.DescripcionOperacion := 'venta de mercaderías';

  // Detalle
  var detalle := DetalleType.Create;
  detalle.CuotaRepercutida := '100';
  detalle.TipoImpositivo := '21';
  SetLength(arrayDetalles, 1);
  arrayDetalles[0] := detalle;

  // desglose
  var desglose: DesgloseType := DesgloseType.Create();
  SetLength(Desglose, 1);
  Desglose[0] := detalle;
  fact.RegistroFacturacion.Desglose := Desglose;

  // Lista de facturas del envío
  SetLength(RegistroAltaFacturas, 1);
  RegistroAltaFacturas[0] := fact;

  // Factura 1
  alta.RegistroAltaFacturas := RegistroAltaFacturas;

  // envío
  try
    var res:RespuestaAltaFactuSistemaFacturacion := RespuestaAltaFactuSistemaFacturacion.Create;
    res := GetsfSOAP(False, '', HTTPRIO1).AltaFactuSistemaFacturacion(alta);

    ShowMessage('Se ha realizado el envío; ' + sLineBreak +
                '   CSV: ' + res.CSV  + sLineBreak +
                '   TimeStamp: ' + res.DatosPresentacion.TimestampPresentacion
                );
  except
    on E:Exception do begin
      ShowMessage(Format('Error al realizar el envío; (%s)-%s',[E.ClassName, E.Message]));
    end;
  end;
end;

En este caso genera un fichero como este:

<?xml version="1.0"?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://www.w3.org/2003/05/soap-envelope" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:SOAP-ENC="http://www.w3.org/2003/05/soap-encoding">
    <SOAP-ENV:Body xmlns:NS1="https://www2.agenciatributaria.gob.es/static_files/common/internet/dep/aplicaciones/es/aeat/tike/cont/ws/SistemaFacturacion.wsdl" xmlns:NS2="https://www2.agenciatributaria.gob.es/static_files/common/internet/dep/aplicaciones/es/aeat/tike/cont/ws/SuministroLR.xsd" xmlns:NS3="https://www2.agenciatributaria.gob.es/static_files/common/internet/dep/aplicaciones/es/aeat/tike/cont/ws/SuministroInformacion.xsd">
        <NS1:AltaFactuSistemaFacturacion SOAP-ENV:encodingStyle="http://www.w3.org/2003/05/soap-encoding">
            <AltaFactuSistemaFacturacion SOAP-ENC:id="1" xsi:type="NS2:AltaFactuSistemaFacturacion">
                <Cabecera SOAP-ENC:id="2" xsi:type="NS3:Cabecera">
                    <IDVersion xsi:type="NS3:VersionType">1.0</IDVersion>
                    <ObligadoEmision SOAP-ENC:id="3" xsi:type="NS3:PersonaFisicaJuridicaESType">
                        <NombreRazon xsi:type="xsd:string">Empresa pruebas</NombreRazon>
                        <NIF xsi:type="xsd:string">11111111H</NIF>
                    </ObligadoEmision>
                    <TipoRegistroAEAT xsi:type="NS3:TipoRegistroAEATType">T0</TipoRegistroAEAT>
                    <FechaFinVeriFactu xsi:type="xsd:string">01/01/2026</FechaFinVeriFactu>
                </Cabecera>
                <item SOAP-ENC:id="4" xsi:type="NS2:FacturasEmitidasType">
                    <RegistroFacturacion SOAP-ENC:id="5" xsi:type="NS3:RegistroFacturacionType">
                        <IDFactura SOAP-ENC:id="6" xsi:type="NS3:IDFacturaExpedidaType">
                            <IDEmisorFactura SOAP-ENC:id="7" xsi:type="NS3:IDEmisorFactura">
                                <NIF xsi:type="xsd:string">3333333</NIF>
                            </IDEmisorFactura>
                            <NumSerieFacturaEmisor xsi:type="xsd:string">23/123456</NumSerieFacturaEmisor>
                            <FechaExpedicionFacturaEmisor xsi:type="xsd:string">31/12/23</FechaExpedicionFacturaEmisor>
                        </IDFactura>
                        <NombreRazonEmisor xsi:type="xsd:string"/>
                        <TipoRegistroSIF xsi:type="NS3:TipoRegistroSIFType">S0</TipoRegistroSIF>
                        <TipoFactura xsi:type="NS3:ClaveTipoFacturaType">F1</TipoFactura>
                        <DescripcionOperacion xsi:type="xsd:string">venta de mercaderías</DescripcionOperacion>
                        <Desglose xsi:type="SOAP-ENC:Array" SOAP-ENC:itemType="NS3:DetalleType" SOAP-ENC:arraySize="1">
                            <item SOAP-ENC:id="8" xsi:type="NS3:DetalleType">
                                <ClaveRegimen xsi:type="NS3:IdOperacionesTrascendenciaTributariaType">01</ClaveRegimen>
                                <TipoImpositivo xsi:type="xsd:string">21</TipoImpositivo>
                                <BaseImponibleOimporteNoSujeto xsi:type="xsd:string"/>
                                <CuotaRepercutida xsi:type="xsd:string">100</CuotaRepercutida>
                            </item>
                        </Desglose>
                        <ImporteTotal xsi:type="xsd:string"/>
                        <EncadenamientoRegistroAnterior xsi:nil="true"/>
                        <SistemaInformatico xsi:nil="true"/>
                        <FechaGenRegistro xsi:type="xsd:string"/>
                        <HoraGenRegistro xsi:type="xsd:string"/>
                        <HusoHorarioGenRegistro xsi:type="NS3:HusoHorarioGenRegistroType">01</HusoHorarioGenRegistro>
                    </RegistroFacturacion>
                    <DatosControl xsi:nil="true"/>
                </item>
            </AltaFactuSistemaFacturacion>
        </NS1:AltaFactuSistemaFacturacion>
    </SOAP-ENV:Body>
 </SOAP-ENV:Envelope>

Adjunto los 3 ficheros generados al importar el WSDL y el propio fichero WSDL.

Van unas preguntas a ver si me podeis echar una mano

¿Con este código se genera el xml de la(s) factura(s) y se enviaría (si la url es correcta)?.

Lo comento ya que trato de añadir por ejemplo DatosControl y me genera un error de excepción añadiendo estas tres lineas:

fact.RegistroFacturacion.Desglose := Desglose;

  //---------------------------------------Genera un error de excepción
  fact.DatosControl.Huella := 'XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXYYYY';
  fact.datosControl.TipoHash := TipoHashType._01;
  fact.datosControl.Incidencia := IncidenciaType.N;
  //---------------------------------------------------

  // Factura 1
  alta.RegistroAltaFacturas := RegistroAltaFacturas;

Tambien aunque lo he intentado añadir código necesario en distintas partes, ya que la factura me llega con dos tipos de maldito iva, no lo he conseguido, ¿Cómo le afectaría al código si una factura lleva dos o más tipos de iva el 21 y el 10?

¿La huella de la factura, se tiene que generar desde este xml y de cada uno de los nodos <RegistroFacturacion> que contenga?

Con el código original funciona perfectamente, genera el xml y realiza el envío, dando error ya que la url no existe. Lo he probado con Delphi 11 Community Edition.

Voy a seguir los consejos de Germán @Neftali y voy a tratar de confeccionar una librería llamada desde delphi 7 y que reciba datos y los procese enviandolos y capturando las respuestas.
Jamás he realizado proyecto que se asemeje a esto, por lo que pido ayuda y comprensión si molesto algo, con alguna pregunta cuyo concepto muchos dareis por sentado.
Si lo consigo, como agradecimiento, colocare en este foro el código completo para que lo utilice cualquiera que lo necesite. Si no lo consigo... para que hablar más.

[Neftali [Germán.Estévez]]

Empezado por ramherfer

Van unas preguntas a ver si me podeis echar una mano
¿Con este código se genera el xml de la(s) factura(s) y se enviaría (si la url es correcta)?.

Con esta línea acabas haciendo el envío y obteniendo la respuesta. Con las anteriores "montas" la factura.

Código Delphi [-]
res := GetsfSOAP(False, '', HTTPRIO1).AltaFactuSistemaFacturacion(alta);

Empezado por ramherfer

Tambien aunque lo he intentado añadir código necesario en distintas partes, ya que la factura me llega con dos tipos de maldito iva, no lo he conseguido, ¿Cómo le afectaría al código si una factura lleva dos o más tipos de iva el 21 y el 10?

¿Has creado el objeto?

Código Delphi [-]
  // Datos de control
  fact.DatosControl := DatosControlType.Create;
  fact.DatosControl.Huella := 'xxxxxxxxxxxxxxxxxxxxxxxxx';
  fact.DatosControl.TipoHash := TipoHashType._01;
  fact.DatosControl.Incidencia := IncidenciaType.N;

Empezado por ramherfer

¿La huella de la factura, se tiene que generar desde este xml y de cada uno de los nodos <RegistroFacturacion> que contenga?

Cada factura que se envía (se pueden enviar N facturas) equivale al tipo RegistroFacturacionType. Y cada uno de estos leva su huella (dentro de DatosControl):

Código Delphi [-]
  FacturasEmitidasType = class(TRemotable)
  private
    FRegistroFacturacion: RegistroFacturacionType;
    FDatosControl: DatosControlType;
  public
    destructor Destroy; override;
  published
    property RegistroFacturacion: RegistroFacturacionType  read FRegistroFacturacion write FRegistroFacturacion;
    property DatosControl:        DatosControlType         read FDatosControl write FDatosControl;
  end;

Por lo tanto, para cada factura habrá que calcular su huella y añadirla al bloque DatosControl que va junto a la factura.
Si se van a enviar N facturas, todas ellas se añaden a un array (Array_Of_FacturasEmitidasType) que finalmente es lo que enviamos en la llamada a SOAP (única propiedad de AltaFactuSistemaFacturacion).

[Neftali [Germán.Estévez]]

Empezado por ramherfer

Tambien aunque lo he intentado añadir código necesario en distintas partes, ya que la factura me llega con dos tipos de maldito iva, no lo he conseguido, ¿Cómo le afectaría al código si una factura lleva dos o más tipos de iva el 21 y el 10?

Para eso debes añadir Tantos DetalleDesglose como necesites.
Según el la documentación entre 1 y 10.

Código Delphi [-]
  DesgloseType = array of DetalleType;

En el código anterior parte hemos creado 1 (1 detalle) y se ha añadido al Array, pero puedes crear varios y añadirlos.

Código Delphi [-]
  // Detalle de IVA 21%
  var detalle1 := DetalleType.Create;
  detalle1.CuotaRepercutida := '100';
  detalle1.TipoImpositivo := '21';
  // detalle IVA al 10%
  var detalle2 := DetalleType.Create;
  detalle2.CuotaRepercutida := '200';
  detalle2.TipoImpositivo := '10';
  // desglose
  var desglose: DesgloseType := DesgloseType.Create();
  SetLength(Desglose, 2);
  Desglose[0] := detalle1;
  Desglose[1] := detalle2;
  fact.RegistroFacturacion.Desglose := Desglose;

Eso te añadirá varios al XML:

[sglorka]

A alguien le ha ocurrido que al serializar el registro individual (no montado dentro de <AltaFactuSistemaFacturacion>) el nodo <RegistroFacturacion> aparece con su namespace

<?xml version="1.0" encoding="utf-8"?>
<FacturasEmitidasType xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<RegistroFacturacion xmlns="https://www2.agenciatributaria.gob.es/static_files/common/internet/dep/aplicaciones/es/aeat/tike/cont/ws/SuministroLR.xsd">
<IDFactura xmlns="https://www2.agenciatributaria.gob.es/static_files/common/internet/dep/aplicaciones/es/aeat/tike/cont/ws/SuministroInformacion.xsd">
<IDEmisorFactura>
<NIF>xxxxxxxxx</NIF>
</IDEmisorFactura> ........

pero al incorporarlo al nodo <AltaFactuSistemaFacturacion> para ser enviado la serialización elimina el namespace de dicho nodo

<AltaFactuSistemaFacturacion xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<Cabecera xmlns="https://www2.agenciatributaria.gob.es/static_files/common/internet/dep/aplicaciones/es/aeat/tike/cont/ws/SuministroInformacion.xsd">
<IDVersion>1.0</IDVersion>
<ObligadoEmision>
<NombreRazon>xxxxx</NombreRazon>
<NIF>xxxxx</NIF>
</ObligadoEmision>
<TipoRegistroAEAT>T0</TipoRegistroAEAT>
</Cabecera>
<RegistroAltaFacturas xmlns="https://www2.agenciatributaria.gob.es/static_files/common/internet/dep/aplicaciones/es/aeat/tike/cont/ws/SuministroLR.xsd">
<RegistroFacturacion>
<IDFactura xmlns="https://www2.agenciatributaria.gob.es/static_files/common/internet/dep/aplicaciones/es/aeat/tike/cont/ws/SuministroInformacion.xsd">
<IDEmisorFactura> ....

Esto tiene la implicación de que el hash que calcularán en la aeat del nodo RegistroFacturacion no incluirá los carácteres relativos al namespace y por tanto, no coincidirá

¿ Alguien está en este caso ?

[ramherfer]

Buenas noches.
A ver por favor estamos trabajando con 3 ficheros que subio German (Neftali):

SistemaFacturacionSOAPv11.pas
SistemaFacturacionSOAPv12.pas
SistemaFacturacionSOAPvRec.pas

Alguien podría indicar el proceso, los pasos para obtenerlos.
Gracias.

[Neftali [Germán.Estévez]]

Empezado por ramherfer

Alguien podría indicar el proceso, los pasos para obtenerlos.

Desde el IDE de Delphi:

1. Crear un proyecto nuevo
2. File/New/Other/Web/WSDL Importer
3. Location: https://prewww2.aeat.es/static_files...cturacion.wsdl
4. Siguente, Siguiente, Finish,...

Desde una ventana de MS-DOS:

c:\Program Files (x86)\Borland\Delphi7\Bin>WSDLImp.exe -p -Dc:\temp -soap12 https://prewww2.aeat.es/static_files/common/internet/dep/aplicaciones/es/aeat/tikeV1.0/cont/ws/SistemaFacturacion.wsdl

[antoine0]

Empezado por sglorka

A alguien le ha ocurrido que al serializar el registro individual (no montado dentro de <AltaFactuSistemaFacturacion>) el nodo <RegistroFacturacion> aparece con su namespace

<?xml version="1.0" encoding="utf-8"?>
<FacturasEmitidasType xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<RegistroFacturacion xmlns="https://www2.agenciatributaria.gob.es/static_files/common/internet/dep/aplicaciones/es/aeat/tike/cont/ws/SuministroLR.xsd">
<IDFactura xmlns="https://www2.agenciatributaria.gob.es/static_files/common/internet/dep/aplicaciones/es/aeat/tike/cont/ws/SuministroInformacion.xsd">
<IDEmisorFactura>
<NIF>xxxxxxxxx</NIF>
</IDEmisorFactura> ........

pero al incorporarlo al nodo <AltaFactuSistemaFacturacion> para ser enviado la serialización elimina el namespace de dicho nodo

<AltaFactuSistemaFacturacion xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<Cabecera xmlns="https://www2.agenciatributaria.gob.es/static_files/common/internet/dep/aplicaciones/es/aeat/tike/cont/ws/SuministroInformacion.xsd">
<IDVersion>1.0</IDVersion>
<ObligadoEmision>
<NombreRazon>xxxxx</NombreRazon>
<NIF>xxxxx</NIF>
</ObligadoEmision>
<TipoRegistroAEAT>T0</TipoRegistroAEAT>
</Cabecera>
<RegistroAltaFacturas xmlns="https://www2.agenciatributaria.gob.es/static_files/common/internet/dep/aplicaciones/es/aeat/tike/cont/ws/SuministroLR.xsd">
<RegistroFacturacion>
<IDFactura xmlns="https://www2.agenciatributaria.gob.es/static_files/common/internet/dep/aplicaciones/es/aeat/tike/cont/ws/SuministroInformacion.xsd">
<IDEmisorFactura> ....

Yo lo haría de una forma un poco distinta:

<AltaFactuSistemaFacturacion xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<Cabecera xmlns="https://www2.agenciatributaria.gob.es/static_files/common/internet/dep/aplicaciones/es/aeat/tike/cont/ws/SuministroInformacion.xsd"> ... </Cabecera>
<Alta:RegistroAltaFacturas xmlns:Alta="https://www2.agenciatributaria.gob.es/static_files/common/internet/dep/aplicaciones/es/aeat/tike/cont/ws/SuministroLR.xsd">
<LR:RegistroFacturacion xmlns:LR="https://www2.agenciatributaria.gob.es/static_files/common/internet/dep/aplicaciones/es/aeat/tike/cont/ws/SuministroLR.xsd">
<IDFactura xmlns="https://www2.agenciatributaria.gob.es/static_files/common/internet/dep/aplicaciones/es/aeat/tike/cont/ws/SuministroInformacion.xsd">
<IDEmisorFactura> ....

La idea es que los espacios de nombres Alta y LR aparecen distintos dentro del documento pero en realidad son el mismo esquema. Habrá que probar con la herramienta de Hacienda pero creo que en XML es válido.
Lo he hecho con dos espacios de nombres explícitos para que se entiende mejor, pero supongo que el segundo puede ser el espacio por defecto. Evidentemente hay que ponerlo para que al final lo que aparece en lo que se está enviando a Hacienda siga exactamente lo mismo que lo que se ha usado para calcular la huella y eventualmente firmar.

[sglorka]

Empezado por antoine0

Yo lo haría de una forma un poco distinta:

<AltaFactuSistemaFacturacion xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<Cabecera xmlns="https://www2.agenciatributaria.gob.es/static_files/common/internet/dep/aplicaciones/es/aeat/tike/cont/ws/SuministroInformacion.xsd"> ... </Cabecera>
<Alta:RegistroAltaFacturas xmlns:Alta="https://www2.agenciatributaria.gob.es/static_files/common/internet/dep/aplicaciones/es/aeat/tike/cont/ws/SuministroLR.xsd">
<LR:RegistroFacturacion xmlns:LR="https://www2.agenciatributaria.gob.es/static_files/common/internet/dep/aplicaciones/es/aeat/tike/cont/ws/SuministroLR.xsd">
<IDFactura xmlns="https://www2.agenciatributaria.gob.es/static_files/common/internet/dep/aplicaciones/es/aeat/tike/cont/ws/SuministroInformacion.xsd">
<IDEmisorFactura> ....

La idea es que los espacios de nombres Alta y LR aparecen distintos dentro del documento pero en realidad son el mismo esquema. Habrá que probar con la herramienta de Hacienda pero creo que en XML es válido.
Lo he hecho con dos espacios de nombres explícitos para que se entiende mejor, pero supongo que el segundo puede ser el espacio por defecto. Evidentemente hay que ponerlo para que al final lo que aparece en lo que se está enviando a Hacienda siga exactamente lo mismo que lo que se ha usado para calcular la huella y eventualmente firmar.

Se te ocurre cómo incluir esos espacios de nombres con el objeto serialiazer

Dim AltaRegistro as ServicioVeriFactu.AltaFactuSistemaFacturacion
Dim serializer As New System.Xml.Serialization.XmlSerializer(GetType(ServicioVeriFactu.AltaFactuSistemaFacturacion))
Dim writer As New System.IO.StreamWriter("RegistroAltaFactura.Xml")

serializer.Serialize(writer, AltaRegistro)
writer.Close()

[antoine0]

Empezado por sglorka

Se te ocurre cómo incluir esos espacios de nombres con el objeto serialiazer

Dim AltaRegistro as ServicioVeriFactu.AltaFactuSistemaFacturacion
Dim serializer As New System.Xml.Serialization.XmlSerializer(GetType(ServicioVeriFactu.AltaFactuSistemaFacturacion))
Dim writer As New System.IO.StreamWriter("RegistroAltaFactura.Xml")

serializer.Serialize(writer, AltaRegistro)
writer.Close()

¿Has intentado crear dos objetos del mismo tipo ServicioVeriFactu.AltaFactuSistemaFacturacion?
Algo como

Dim ServicioAltaRegistro as ServicioVeriFactu.AltaFactuSistemaFacturacion
Dim RegistroEnSi as ServicioVeriFactu.AltaFactuSistemaFacturacion

... y luego pasar por dos objetos XmlSerializer, uno que escribe dentro del segundo (si se ve mucho que no tengo práctica, concretamente nula con dotNet, es que es así ).

La idea subyacente es que hay que separar las dos partes, de una parte la generación del registro (y su posterior almacenamiento) del envío a Hacienda con el servicio web. El segundo se debe alimentar del resultado del primero, no se debería volver a crear el XML entero porqué, como bien has dicho antes, es problemático volver a generar el mismo contenido que él con cual se calculó la huella.

[sglorka]

Empezado por antoine0

¿Has intentado crear dos objetos del mismo tipo ServicioVeriFactu.AltaFactuSistemaFacturacion?
Algo como

Dim ServicioAltaRegistro as ServicioVeriFactu.AltaFactuSistemaFacturacion
Dim RegistroEnSi as ServicioVeriFactu.AltaFactuSistemaFacturacion

... y luego pasar por dos objetos XmlSerializer, uno que escribe dentro del segundo (si se ve mucho que no tengo práctica, concretamente nula con dotNet, es que es así ).

La idea subyacente es que hay que separar las dos partes, de una parte la generación del registro (y su posterior almacenamiento) del envío a Hacienda con el servicio web. El segundo se debe alimentar del resultado del primero, no se debería volver a crear el XML entero porqué, como bien has dicho antes, es problemático volver a generar el mismo contenido que él con cual se calculó la huella.

Se podría crear el registro inicial que se va a almacenar del tipo ServicioVeriFactu.AltaFactuSistemaFacturacion, luego no hay problema al crear el mensaje de envío con todos los registros pendientes ya que se puede extraer de cada registro individual el objeto <Registrofacturación> y añadirlos al mensaje de envío para enviar varios a la vez. Este método si funciona pero lo que me echa para atrás es que en el diseño que proponen DR_Alta CE, que se supone que es para almacenar los registros individuales, exigen que el objeto sea del tipo <FacturaExpedidaType> y no sé si eso puede crear problemas.
En resumen, entiendo que los registros de facturación generados deben almacenarse en Xml bajo la estructura <FacturaExpedidaType> y una vez que los vas a comunicar construyes el objeto ServicioVeriFactu.AltaFactuSistemaFacturacion

[[newtron]]

Empezado por ramherfer

Voy a seguir los consejos de Germán @Neftali y voy a tratar de confeccionar una librería llamada desde delphi 7 y que reciba datos y los procese enviandolos y capturando las respuestas.
Jamás he realizado proyecto que se asemeje a esto, por lo que pido ayuda y comprensión si molesto algo, con alguna pregunta cuyo concepto muchos dareis por sentado.
Si lo consigo, como agradecimiento, colocare en este foro el código completo para que lo utilice cualquiera que lo necesite. Si no lo consigo... para que hablar más.

De una forma o de otra yo creo que habrá que plantear crear un programa aparte que se encargue de recopilar las facturas según se vayan produciendo e ir enviándolas porque en ambientes de red ese trabajo tendrá que hacerlo un único terminal que tenga el certificado digital correspondiente instalado, o si a alguien se le ocurre otra forma mejor puede comentarlo.



Saludos.

[Neftali [Germán.Estévez]]

Empezado por newtron

De una forma o de otra yo creo que habrá que plantear crear un programa aparte que se encargue de recopilar las facturas según se vayan produciendo e ir enviándolas porque en ambientes de red ese trabajo tendrá que hacerlo un único terminal que tenga el certificado digital correspondiente instalado, o si a alguien se le ocurre otra forma mejor puede comentarlo.

Bueno es una opción bastante lógica para algunos entornos, estoy pensando en empresas grandes con un ERP. En esos casos es bastante lógico pensar en un servicio que implemente una cola de envío.


Pero en otros casos, por ejemplo en una tienda con 3 puestos de venta, tal vez es más sencillo que cada TPV/puesto genere sus facturas y las envíe. En el caso de TicketBAI, por ejemplo, ya está pensado y admiten certificados de dispositivo. Cada máquina tiene un certificado de dispositivo y simplifica todo el proceso (instalación, envío,...).

[[newtron]]

Empezado por Neftali [Germán.Estévez]

Bueno es una opción bastante lógica para algunos entornos, estoy pensando en empresas grandes con un ERP. En esos casos es bastante lógico pensar en un servicio que implemente una cola de envío.


Pero en otros casos, por ejemplo en una tienda con 3 puestos de venta, tal vez es más sencillo que cada TPV/puesto genere sus facturas y las envíe. En el caso de TicketBAI, por ejemplo, ya está pensado y admiten certificados de dispositivo. Cada máquina tiene un certificado de dispositivo y simplifica todo el proceso (instalación, envío,...).

Pues si te digo la verdad no tengo ni idea de lo que es un certificado de dispositivo pero en mi caso me resulta más fácil de mantener un único programa instalado en el servidor que andar peleando con los terminales que se averían y los reinstalan, cambian o quien sabe qué y todo eso hay que ir luego detrás configurando así que seguramente iré por esa vía.



Saludos.

[Neftali [Germán.Estévez]]

Empezado por newtron

Pues si te digo la verdad no tengo ni idea de lo que es un certificado de dispositivo pero en mi caso me resulta más fácil de mantener un único programa instalado en el servidor que andar peleando con los terminales que se averían y los reinstalan, cambian o quien sabe qué y todo eso hay que ir luego detrás configurando así que seguramente iré por esa vía.

Bueno yo creo que las 2 pueden ser buenas. Cada uno deberá decidir para su programa cual es mejor.
Creo que ambas tienen ventajas/inconvenientes.

[nincillo]

Empezado por Neftali [Germán.Estévez]

Bueno yo creo que las 2 pueden ser buenas. Cada uno deberá decidir para su programa cual es mejor.
Creo que ambas tienen ventajas/inconvenientes.

Hasta donde yo entiendo (y quizás lo entienda mal). Por un lado está la generación del xml correspondiente a la factura, con su hash y demás, y por otro lado está el envío de dichos xml a hacienda.

Si estoy en lo correcto, quizás la generación del xml sería por parte del equipo que genera la factura y que la dejaría en una carpeta "común" y por otro lado está el programa dedicado al envío de dichos ficheros xml a Hacienda, que no tiene por que hacerlo en tiempo real, ya que según he leído por ahí, la propia hacienda puede marcar el ritmo de envío y el número de facturas a enviar en cada envío.

Per la verdad es que cuando te pones a pensar que puede haber varios equipos a la vez facturando con la misma serie, buff, la posibilidad de combinaciones es grande. Si se da el caso de que estén facturando simultáneamente, quizás el primer equipo aún no generó del todo el xml, y el segundo equipo está intentando leer información del xml que aún no se generó o no del todo... En fin...

La otra opción que he pensado es con algún sistema de flags, que cada vez que algún equipo equipo genere una factura, un programa en el servidor genere todos los xml de las facturas que se hayan generado desde la última vez o algo así...

Y la facturación en bloque de fin de mes, que se pueden generar cientos de facturas en un momento... En fin... Poco a poco...

[Neftali [Germán.Estévez]]

Empezado por nincillo

Per la verdad es que cuando te pones a pensar que puede haber varios equipos a la vez facturando con la misma serie, buff, la posibilidad de combinaciones es grande. Si se da el caso de que estén facturando simultáneamente,
...
Y la facturación en bloque de fin de mes, que se pueden generar cientos de facturas en un momento... En fin...

Bueno, pero de eso no le podemos "echar la culpa" a VERI*FACTU, esos problemas ya los tenemos ahora...

[ermendalenda]

Empezado por nincillo

Hasta donde yo entiendo (y quizás lo entienda mal). Por un lado está la generación del xml correspondiente a la factura, con su hash y demás, y por otro lado está el envío de dichos xml a hacienda.

Si estoy en lo correcto, quizás la generación del xml sería por parte del equipo que genera la factura y que la dejaría en una carpeta "común" y por otro lado está el programa dedicado al envío de dichos ficheros xml a Hacienda, que no tiene por que hacerlo en tiempo real, ya que según he leído por ahí, la propia hacienda puede marcar el ritmo de envío y el número de facturas a enviar en cada envío.

Per la verdad es que cuando te pones a pensar que puede haber varios equipos a la vez facturando con la misma serie, buff, la posibilidad de combinaciones es grande. Si se da el caso de que estén facturando simultáneamente, quizás el primer equipo aún no generó del todo el xml, y el segundo equipo está intentando leer información del xml que aún no se generó o no del todo... En fin...

La otra opción que he pensado es con algún sistema de flags, que cada vez que algún equipo equipo genere una factura, un programa en el servidor genere todos los xml de las facturas que se hayan generado desde la última vez o algo así...

Y la facturación en bloque de fin de mes, que se pueden generar cientos de facturas en un momento... En fin... Poco a poco...

Hay que hacerlo en fifo, 2 equipos con la misma serie, inevitablemente leen el siguiente njnero de factura en orden cronológico, por tanto da igual quien lo genere que tendrá un orden cronológico, lo que sí se ve es que el envío tiene que ser común para la misma serie.
Yo por ejemplo eso no voy a tener problemas por qur para distintos tpvs tengo números de serie diferente y si hay algún dispositivo más enganchado al tpv(una.pda por ejemplo o un cajón de cobro automatico, o incluso otro tpv satelite) leen y escriben en el mismo sitio, controlando bien los índices únicos no existe problemas.

[antoine0]

Empezado por nincillo

Per la verdad es que cuando te pones a pensar que puede haber varios equipos a la vez facturando con la misma serie, buff, la posibilidad de combinaciones es grande. Si se da el caso de que estén facturando simultáneamente, quizás el primer equipo aún no generó del todo el xml, y el segundo equipo está intentando leer información del xml que aún no se generó o no del todo... En fin...

Es un problema clásico de cola, con un recurso único. Cuando cualquier programa (de varios) está listo para encadenar (es decir, XML del registro generado hasta la parte EncadenamientoRegistroAnterior), se pone en cola para obtener esta información. Él que está en cabeza de la cola entra en sección crítica (mútex), recupera la información del último registro (ID, huella y hora de generación), recupera la hora actual, acaba de completar el XML, calcula su huella, graba el registro ya completado con su DatosControl (la firma se podrá actualizar más tarde, y evidentemente las incidencias también), este registro pasa a ser el último, y puede salir de la sección crítica, liberando para el siguiente en la cola.

El tema de los números de nueva factura pueden gestionarse de la misma manera, es decir atribulándose dentro de la sección crítica; pero no tengo claro si es un requisito imprescindible de los sistemas de facturación que los registros de factura tipo S0 sigan encadenados en orden estrictamente ascendente de número de factura en cada serie (muy posible que me he perdido algo aquí). Obviamente es muy preferible, pero creo que se puede haber circunstancias como las que describes que hacen que los números pueden resultar desordenados a veces, en caso de incidencia en la generación del registro después de haber obtenido un número de futura factura. Y desde luego, dado que el número de factura está mezclado con el número de serie en el campo IDFactura, no veo como Hacienda puede automatizar un control de este requisito.

[ermendalenda]

Empezado por Neftali [Germán.Estévez]

Bueno es una opción bastante lógica para algunos entornos, estoy pensando en empresas grandes con un ERP. En esos casos es bastante lógico pensar en un servicio que implemente una cola de envío.


Pero en otros casos, por ejemplo en una tienda con 3 puestos de venta, tal vez es más sencillo que cada TPV/puesto genere sus facturas y las envíe. En el caso de TicketBAI, por ejemplo, ya está pensado y admiten certificados de dispositivo. Cada máquina tiene un certificado de dispositivo y simplifica todo el proceso (instalación, envío,...).

Estoy de acuerdo, en una empresa con muchos terminales es un poco locura que cada terminal envie los datos, es mejor establecer servicios de envio para que se centralice y si hay una incidencia sea un poco más facil de gestionar, sobre todo en los sistemas cuya base son softwares de escritorio. Por otro lado tenemos los distribuidores de software, en ese caso veo 2 posibllidades, ya que pueden hacer ellos el envio (también centralizado), o contratar el servicio de envio. Ya hay empresas para ello en tickebai y van a desarrollar para Verifactu, por si os quereis ahorraros el trabajo y entra dentro de vuestras posiublidades de gestión y economicas...
Las empresas que se dedican a hacer el envio tienen una cosa buena, es que con que le envies el tique/factura en un formato por ejemplo json, te devuelven el Qr y se encargan de todo lo demás. Algunas te dan el servico en tu misma red local y otras a través de servicios Rest.

Os lo cuento para los que veais la cosa muy complicada sepais que opciones hay.

[antoine0]

Empezado por Neftali [Germán.Estévez]

Bueno es una opción bastante lógica para algunos entornos, estoy pensando en empresas grandes con un ERP.

Mmmm.... Empresa grande y ERP, pero no en el S.I.I.... ¿Habrá muchas?