No sé si tu caso se podría considerar como dos aplicaciones distintas. Yo se lo plantearía directamente a ellos...

Hola elcharlie,

Yo lo hago con PHP

Saludos

Hola espinete,

No es un dato de la empresa sino de la factura.
Aunque en general, para la mayor parte de emisores será la que le corresponda por su régimen de IVA ante Hacienda:
- 01 Operación de régimen general y cualquier otro supuesto que no esté recogido en los siguientes valores
- 51 Operaciones en recargo de equivalencia
- 52 Operaciones en régimen simplificado

Pero se puede dar el caso de que por el tipo de operación sea, por ejemplo:
- 02 Exportación
- 11 Operaciones de arrendamiento de local de negocio sujetas a retención.
- 12 Operaciones de arrendamiento de local de negocio no sujetas a retención.
- 13 Operaciones de arrendamiento de local de negocio sujetas y no sujetas a retención.

Pero si te fijas, verás que se permiten hasta 3 claves para una misma factura.
Con ello creo que se pueden cubrir la mayoría de casos.

Saludos

Gracias esto va a venir genial

Lo lógico es una sola, es un instalador que instala todas las funciones y que haya un proceso en segundo que genera los tiquets de idéntica forma que si fueran manuales) y que dependa toralmente del proceso principal.
Es una forma de programar que igualmente puede ser con procesos asíncronos desde el mismo ejecutable.

Gracias, lo intentare adaptar a delphi, a ver si soy capaz, si encuentro solución lo posteo para que lo reutiliceis.

En este hilo explicamos cómo hacerlo con insomnia:
http://clubdelphi.com/foros/showpost...postcount=1029

Es un programa similar.
Te lo comento, porque me resultó más sencillo que hacerlo con PostMan. A mi hubo una temporada que me funcionaba (postman), pero luego dejaron de hacerlo.

Hola a todos.

No se si alguien esta usando el servicio de consulta de facturas de la hacienda de Bizkaia. Me ocurre lo siguiente.

Tenemos una factura con dos tipos de IVA, uno normal al 21% (S1) y otro una inversión de sujeto pasivo (S2). A la hora de enviar el fichero lo enviamos el desglose de la siguiente manera y se envía correctamente.

Es decir hay que añadir dos tipos de la etiqueta <DetalleNoexenta> dentro de la etiqueta <NoExenta> uno de tipo S1 y otro de tipo S2.

Pero cuando se hace la consulta al servicio de consulta el fichero devuelto tiene la siguiente estructura.
Es decir lo que esta duplicado es la etiqueta <Noexenta> en vez de <DetalleNoExenta> dentro de ella por lo que al cargar el fichero sólo retorna un elemento en vez de dos, ya que esta duplicada <Noexenta>.

al hacer

Código Delphi [-]
ShowMessage(Resultado240.FacturasEmitidas[i].TicketBai.Factura.TipoDesglose.DesgloseFactura.Sujeta.NoExenta.Count.ToString);

Esto retorna 1 en vez de 2.

¿Alguien lo puede probar?. Por que cualquiera le explica esto a hacienda.

Hola a todos...

Como Álava es la única que devuelve los posibles "errores de validación de negocio" al enviar las facturas, me estoy encontrando con varios problemas a la hora de enviar facturas con descuentos por línea, con recargo de equivalencia, retenciones, etc... y no encuentro ninguna factura de prueba que usar como ejemplo para ver las diferencias.

He conseguido enviar sin problema facturas con varios tipos de IVA e incluso con un descuento "global" (por pronto pago, por ejemplo). Entiendo que el problema está en que estoy poniendo mal los importes en algún sitio según las condiciones de cada caso.
¿Alguien podría decirme si en el detalle de la factura (líneas), "ImporteUnitario" e "ImporteTotal" deben reflejar el importe REAL/FINAL de esa línea, con el recargo, descuento, etc. aplicados?

Por ejemplo. Para una Factura EXENTA DE IVA...

Lo que yo hago:

* * * * * * <DetallesFactura>
* * * * * * * * <IDDetalleFactura>
* * * * * * * * * * <DescripcionDetalle>TARJETA SMALL</DescripcionDetalle>
* * * * * * * * * * <Cantidad>1</Cantidad>
* * * * * * * * * * <ImporteUnitario>100.00</ImporteUnitario>
* * * * * * * * * * <Descuento>0.00</Descuento>
* * * * * * * * * * <ImporteTotal>121.00</ImporteTotal>
* * * * * * * * </IDDetalleFactura>
* * * * * * </DetallesFactura>

Pero creo que ImporteTotal debería ser 100.00 en vez de 121.00 si la factura está exenta?


Otro caso: Factura con RETENCIÓN

* * * * * * <DetallesFactura>
* * * * * * * * <IDDetalleFactura>
* * * * * * * * * * <DescripcionDetalle>WEBCAM NGS XPRESSCAM</DescripcionDetalle>
* * * * * * * * * * <Cantidad>1</Cantidad>
* * * * * * * * * * <ImporteUnitario>100.00</ImporteUnitario>
* * * * * * * * * * <Descuento>0.00</Descuento>
* * * * * * * * * * <ImporteTotal>121.00</ImporteTotal>
* * * * * * * * </IDDetalleFactura>
* * * * * * </DetallesFactura>

* * * * * * <ImporteTotalFactura>102.00</ImporteTotalFactura>
* * * * * * <RetencionSoportada>19.00</RetencionSoportada>

¿Debería ImporteTotal (121.00) reflejar la retención también? ¿O tal vez ImporteTotalFactura no deba incluir la retención?

Lo mismo me ocurre con facturas con Recargo de Equivalencia o con Descuento por línea.

¿Debería ImporteTotal reflejar SIEMPRE el importe final de la línea según las condiciones de la factura? ¿o solo el precio "real" del artículo, independientemente de las condiciones de la factura?

Sé que puede resultar obvio, pero no sé cómo hace Araba las validaciones de los totales. La facturación electrónica de otros países se encarga de sumar/restar lo que sea necesario en función de los datos/condiciones de la factura, pero en este caso es "al revés" y debemos indicar nosotros los importes exactos que se van a sumar/restar. Es decir, hay que dárselo todo masticado.

Vaya, se queda bloqueado el servicio php en cuanto llega a esta línea:
if (!$domDocument->schemaValidate($xsd)) {

Puedes probar también online en esta dirección (falta el protocolo delante y tiene un espacio, ya que no tengo permisos para poner urls), pegando el xml y el xsd:

[quote]
www .utilities-online.info/xsdvalidation
[quote]

Nosotros los comprobamos usando el API de java:

Ahora me da otro error
<br />
<b>Warning</b>: DOMDocument::schemaValidate(): Invalid Schema in <b>/..../firmador.php</b> on line <b>72</b><br />
Buahh por qué cada cosa se complica tantooo

Ya debería de funcionar como el resto de administraciones, escribimos a Álava para preguntar por la inconsistencia con respecto a las especificaciones, y nos respondieron esto:

Lo probamos con varias que no funcionaban, y ya funcionan como indica la especificación.

Hola keys, suprime el <TipoImpositivo> y <CuotaImpuesto> de la línea ISP. En ventas con Inversión de Sujeto Pasivo, el IVA no hay que consignarlo:

Y después inténtalo de nuevo.

Hola espinete, el montante de los recargos y descuentos globales (recargo financiero, descuento por pronto pago...), o sea, cargos pie factura, no se incluyen en el <ImporteTotal> de las líneas de detalle.
El <ImporteUnitario> es el precio de venta de la línea de detalle.
Si el artículo de la línea de detalle tiene descuento de venta, su importe (no su porcentaje) hay que consignarlo en <Descuento>
El <ImporteTotal> tiene que ser el propio de la línea de detalle con su IVA (y Recargo de equivalencia en su caso) correspondiente.
Si la factura incluye conceptos adicionales como entregas a cuenta, suplidos... aplicables tras el total de factura, no hay que incluirlos en el fichero TicketBAI.

Espero haberte ayudado.

El problema no esta en el envío, las facturas las envia correctamente, el problema esta en lo que devuelve hacienda en la consulta que no sigue la estructura de los xsd.

Un Saludo

QR Araba ya funciona igual que las otras
 

Hola hago_preguntas, acabo de probar el ejemplo que tenia controlado y es cierto, funciona de las dos forma, igual que las otras diputaciones forales y también con su propio sistema.

Muchas gracias

Hola ermendalenda,

Comprueba que tienes instalada la extensión libxml de PHP.
Puedes comprobarlo ejecutando Debe aparecerte una sección de libxml
Si no la tienes instalada, ya sabes ... en mi caso Saludos

Hola adolphsys,

¿Seguro que el RE (en el caso de que el destinatario esté obligado) debe estar incluído en el <ImporteTotal> de cada línea de detalle?
Según la descripción: "Importe total CON IVA de la línea de factura."
No dice que deba estar incluído el RE.
Donde sí debe estar el RE detallado es en la sección DetalleIVA -> CuotaRecargoEquivalencia

Saludos

Hola keys,

Si verificas el XML devuelto por Hacienda contra el esquema XSD ¿te da correcto?
En caso de que no dé correcto, habría que informar a Hacienda Foral.

Saludos

Estupendo Neftali, gracias! Pues probaré con insomnia porque con PostMan soy incapaz de cargar el certificado.

Hola espinete,

Mi opinión (aunque, como es lógico, la última palabra siempre la tiene Hacienda):

- Si una factura es exenta de IVA, en la línea de detalles, en <ImporteTotal> debe aparecer sin IVA.

- Si una factura lleva retención, no debe reflejarse esa retención ni en las líneas de detalle, ni en los desgloses, ni siquiera en <ImporteTotalFactura>. La retención debe ir por separado de todo ello sólo en <RetencionSoportada>
La retención no afecta a la factura ni a sus IVAs. Es un tema de pagos/cobros que irá por otro lado (declaración de retenciones de IRPF)

Se admiten otras opiniones.

Saludos

Hola APO,

Sí, yo también, como Neftali, uso Insomnia.
Es muchísimo más sencillo de configurar y utilizar que PostMan.
Te recomiendo Insomnia.

Saludos

Contenido del documento FAQ'S de Guipuzkoa
 

Por sí ayuda :

12.13 En el importe que va en la etiqueta “BaseImponible”, ¿hay que descontar los descuentos especiales, los descuentos por pronto pago, y sumarle los portes? ¿O sólo hay que indicar la suma de los importes de los detalles de la factura?
En la etiqueta Base imponible debe figurar en efecto la cifra que resulte de los descuentos y de los portes. Los descuentos que figuran en el detalle serán los descuentos unitarios.
No obstante, cada uno de los descuentos globales también deberán figurar en la factura, consignándose cada uno de ellos como una nueva línea de detalle describiendo el concepto del descuento, en su caso, y el importe, que según se configure el mismo, pudiera tener signo negativo.
El archivo XML-TicketBAI debe tener toda la información que figure en relación a los descuentos en la factura, al punto que con ese archivo se podría prácticamente considerar que sería un repositorio de las facturas por lo que el detalle del archivo XML-TicketBAI será el mismo que el detalle que figure en la factura y, por tanto, en su caso, precisará cada uno de los descuentos globales y su importe.

Gracias Sistel...

Me he liado un poco con los nombres que le han dado a las variables. ImporteUnitario en realidad es el Precio unitario, no el importe (al menos en mi cabeza, importe es precio*cantidad).
Pero luego ImporteTotal sí es el total de la línea. Por eso me liaba.

Pregunta campo Idotro
 

Hola,
alguien ha usado el campo <IDOtro> cuando se trata de un cif extranjero?
por favor un ejemplo

RAEE impuesto de reciclaje
 

Buenos días,

alguien me puede decir cómo debemos informar el RAEE (el impuesto de reciclaje) que puede tener algún artículo de una línea de detalle de la factura?
¿Tiene que ir sumado dentro del campo ImporteUnitario del DetalleFactura correspondiente?

No encuentro información sobre el RAEE en la documentación.



Muchas gracias

Hola...

Yo he conseguido enviar facturas para destinatarios extranjeros rellenando solo los siguientes datos:

Sujetos.Destinatarios.IDOtro.CodigoPais (el código ISO de 2 letras del país)
Sujetos.Destinatarios.IDOtro.IDType (04)
Sujetos.Destinatarios.IDOtro.ID (el código ISO + la identificación fiscal del destinatario en su país de origen)
Sujetos.Destinatarios.ApellidosNombreRazonSocial
Sujetos.Destinatarios.CodigoPostal
Sujetos.Destinatarios.Direccion

Fíjate que Sujetos.Destinatarios.NIF no se incluye en este caso.

Desde que envíes el campo NIF te devuelve error. NIF y IDOtro son excluyentes.

Otra cosa es que esté bien hecho, pero al menos así puedo enviar las facturas sin error/aviso

Facturas con Recargo de Equivalencia...
 

Tengo una duda con las facturas con recargo de equivalencia, y la respuesta que me dan desde Álava me provoca más dudas aún...

1. En la línea de detalle de cada artículo, el importe total debe llevar acumulado el recargo de equivalencia, no solo el IVA.

Bien, hasta ahí no hay problema.

2. Cuando hay tipo y cuota de recargo de equivalencia en el desglose, la etiqueta OperacionEnRecargoDeEquivalenciaORegimenSimplificadodebe ser ‘N’

Aquí ya se me empieza a torcer el culo... ¿Si es una factura con recargo, por qué OperacionEnRecargoDeEquivalenciaORegimenSimplificado debe ser "N" y no "S"?

3. Los campos “tipo recargo equivalencia” y “cuota recargo equivalencia” sólo deben rellenarse en el caso de que se documente una operación en la que el destinatario de la operación sea un comerciante minorista acogido al régimen especial del recargo de equivalencia y proceda la aplicación de dicho recargo.

Ya, por eso los rellenaba, porque la factura está acogida al recargo de equivalencia, no?

4. En el desglose a nivel de factura, se habilita una marca de nombre "Operación en recargo de equivalencia o Régimen simplificado", en la cual el valor por defecto es "N". Si se marca “S”, se trata de una factura expedida por un contribuyente en régimen simplificado o en régimen de recargo de equivalencia. La cuota del IVA repercutida en este caso NO se traslada a la declaración del IVA

5. Operación en recargo de equivalencia o régimen simplificado: S. Esta marca significa que la cuota de IVA no forma parte de la liquidación del impuesto, por lo que tiene la consideración de ingreso de la actividad económica a efectos del IRPF.

Ejemplo que me ponen desde Álava:

Un empresario en régimen de recargo de equivalencia expide una factura de un medicamento con base imponible IVA de 100 euros y cuota de IVA de 4 euros. ¿Cómo se debe generar el fichero TB en este caso?
Se debe marcar la clave de regímenes de IVA y operaciones con trascendencia tributaria "51 Operaciones en recargo de equivalencia".
En el desglose de factura, se deben rellenar los siguientes importes y valores:
- Base imponible: 100.
- Tipo impositivo: 4.
- Cuota del impuesto: 4.
- Tipo del recargo de equivalencia: 0.
- Cuota del recargo de equivalencia: 0.

A ver si lo he entendido bien...

Si el Emisor está acogido al Recargo de Equivalencia, se hace como el ejemplo anterior:
- clave de regímenes de IVA = 51
- Tipo Recargo 0
- Cuota Recargo 0

Y si es el Destinatario está acogido al Recargo de Equivalencia:
- Tipo del recargo de equivalencia: 5,20 (o el que sea).
- Cuota del recargo de equivalencia: (la cuota de recargo)

¿Es así o lo estoy entendiendo mal?

Asi es el xml devuelto por hacienda contra el xsd de hacienda no es correcto. Se lo he comunicado a hacienda, pero quería ver si le pasa a alguien más.

Un saludo

por si te sirve, en postman, vas a settings, Certificates, Client Certificates, Add Certificate, en Host pones la url (yo tengo la de pruebas tbai-prep.egoitza.gipuzkoa.eus) y luego pfx file pones el certificado,y en passphrase el password si hiciera falta.
Con esto yo puedo enviar sin problemas

Gracias Espinete.

Un ejemplillo:

Otro con problemas con la validación de negocios de Alava


Hago una factura muy simple


una línea con -1 x 197,29 al 21% (-238,72)


Me devuelve el error de 78-AVISO: Error validación de negocio [Sumatorio detalle no coincide con el sumatorio desglose]

Y yo mando esto (pongo solo la parte de datos referente a valoraciones)

<CabeceraFactura>
<NumFactura>21001011</NumFactura>
<FechaExpedicionFactura>21-10-2021</FechaExpedicionFactura>
<HoraExpedicionFactura>00:00:13</HoraExpedicionFactura>
<FacturaSimplificada>N</FacturaSimplificada>
<FacturaEmitidaSustitucionSimplificada>N</FacturaEmitidaSustitucionSimplificada>
</CabeceraFactura>
<DatosFactura>
<DescripcionFactura>factura a cliente</DescripcionFactura>
<DetallesFactura>
<IDDetalleFactura>
<DescripcionDetalle>IMPRESORA LASER </DescripcionDetalle>
<Cantidad>-1.00</Cantidad>
<ImporteUnitario>-197.29</ImporteUnitario>
<Descuento>0</Descuento>
<ImporteTotal>-238.72</ImporteTotal>
</IDDetalleFactura>
</DetallesFactura>
<ImporteTotalFactura>-238.72</ImporteTotalFactura>
<Claves>
<IDClave>
<ClaveRegimenIvaOpTrascendencia>01</ClaveRegimenIvaOpTrascendencia>
</IDClave>
</Claves>
</DatosFactura>
<TipoDesglose>
<DesgloseFactura>
<Sujeta>
<NoExenta>
<DetalleNoExenta>
<TipoNoExenta>S1</TipoNoExenta>
<DesgloseIVA>
<DetalleIVA>
<BaseImponible>-197.29</BaseImponible>
<TipoImpositivo>21.00</TipoImpositivo>
<CuotaImpuesto>-41.43</CuotaImpuesto>
</DetalleIVA>
</DesgloseIVA>
</DetalleNoExenta>
</NoExenta>
</Sujeta>
</DesgloseFactura>
</TipoDesglose>
</Factura>
....


Falla la valildación o fallo yo?


Gracias.

Yo para que me la tome por válida pongo la cantidad en negativo, el importe en positivo y el total en negativo.

Según ellos, se puede hacer de la siguiente manera: Cantidad sin signo y los 2 importes negativos.

...pero no lo he probado. Poniendo cantidad negativa, importe positivo y total negativo, la da por válida.

Gracias espinete. Funciona. ^\||/

:)Muchas Gracias

Álava me acaba de responder a mi duda sobre el Recargo de Equivalencia:

1) EMISOR acogido al régimen de recargo de equivalencia:

TipoRecargo = 0
CuotaRecargo = 0
OperacionEnRecargoDeEquivalenciaORegimenSimplificado = "S"
ClaveRegimenIvaOpTrascendencia = 51
(no válido para personas jurídicas, solo personas físicas)
ImporteTotal*debe incluir Importe+IVA (SIN el RE)

2) DESTINATARIO acogido al recargo de equivalencia

TipoRecargo = porcentaje del RE
CuotaRecargo = cuota del RE
OperacionEnRecargoDeEquivalenciaORegimenSimplificado = "N"
ClaveRegimenIvaOpTrascendencia = 01 (o la que sea)
ImporteTotal*debe incluir Importe+IVA+RE

He hecho pruebas de envío con ambos casos y ya no me devuelve ningún aviso/error.

Con tantas condiciones, regímenes, códigos, tipos, etc. que hay que indicar en la generación de las facturas...

"causas de exención", "clave de régimen especial", "causa de no sujeción", "tipo de factura rectificativa", "código de factura rectificativa"

...los programas facturación van a quedar de todo menos minimalistas e intuitivos, si el cliente final va a tener ahora que indicar todas estas variables antes de hacer una factura, no? O me estoy perdiendo algo?

Al menos la utilidad para crear facturas que hay en la web de Bizkaia y Gipuzkoa incluyen varios desplegables y checkboxes para indicar todas estas opciones. Me pregunto si realmente hay alguna forma de que sea lo más automático posible para el usuario final. Vamos, que si se olvidan de elegir la forma de pago, ya te digo yo que se van a olvidar de todas estas opciones "nuevas".

Por eso preguntaba hace unos días de si la "Clave de régimen especial de IVA y operaciones con trascendencia tributaria" era algo fijo (por empresa) o dependía de cada factura. Imagino que en la mayoría de los casos (un comercio de venta al público, por ejemplo), se pueden predefinir la mayoría de opciones, pero aún así habrá que poner la opción visible.

Validador
 

Terminando Validador XSD-XLM para VB6.

Madre del amor hermoso todos los santos y la Virgen del petroleo vaya cirio hay que montar.

Pues sí, yo también entiendo que importe es precio*cantidad y creo que, al menos, la gran mayoría, pero efectivamente: se refieren al Precio