![]() |
Joder.es que ll que estoy viendo es que la nota de crédito es una anulación propiamente dicha, la diferencia es que la anulación no lleva número de serie ni número de factura.
Yo te digo que en tixketbai lo he solucionado poniendo una serie interna para tener esos negativos en el periodo impositivo en los ue se hizo la anulación y así y3ner más claro los datos. Por otro lado si es legal deberían compatibilizarlo con verifactu y lo arreglaran si no está contemplado, no pueden saltarse el reglamento de facturación |
Cita:
Otra pregunta es si ¿Podríamos? Ahora bien, es difícil ver la diferencia con una nota de crédito «interna» emitida para corregir un error de entrada, dónde las dos facturas se quedan en casa, nadie más que tú, tu contable y tu controlador fiscal se enteren (y esas sí que se pueden anular). Pero en tal caso, hay que anular la primera factura, y también anular la nota de crédito. De no hacerlo, la balance contable no saldrá equilibrada. Cita:
En la respuesta de la operación de alta: Si el registro enviado es rechazado por estar duplicado. En la respuesta de la operación de baja: Si el registro enviado es rechazado porque ya está dado de baja.» Yo diría que no se esperan duplicaciones... Cita:
|
Anulación de Facturas
Gracias por tu comentario.
Entonces podemos estar en un escenario en que no sería necesario anular facturas. Si tenemos un error en los tipos impositivos, fecha de expedición, numeración, etc. podríamos emitir una factura ordinaria en negativo y posteriormente una rectificativa x sustitución que corrige la primera, como indica la consulta vinculante V0902-22 que podemos ver en Iberley fechada en este año. Este procedimiento es más natural ya que entregar un solo documento rectificativo al cliente final podría generar errores al contabilizar dos veces las misma operación, en cambio, con este procedimiento enviamos ambas facturas (la factura de abono y la rectificativa). En este escenario, entiendo que no debemos informar el registro de anulación, mantenemos la factura inicial como emitida y enviamos dos registros, la factura que abona y la rectificativa. ¿ Podemos estar de acuerdo en este aspecto ? Saludos |
Cita:
|
Cita:
|
Cita:
|
Borrador XMLs
Hola.
os dejo un borrador de los 2 XML para que vayamos practicando/corrigiendo, seguro tengo algún error y ademas me faltan datos de cabecera. Registro/s de Alta: Código:
<?xml version="1.0" encoding="UTF-8"?>Código:
<?xml version="1.0" encoding="UTF-8"?> |
Cita:
|
Cita:
|
Prueba
Esto es una prueba, aun no hay concreción de los campos/Nodos del XML.
Es importante destacar que la huella(Hash) se calcula en Base al SHA256 del Nodo: Código:
<RegistroFacturacion>Ejemplo Factura Simplificada 1.20Euros pan al 4%IVA Código:
<?xml version="1.0" encoding="UTF-8"?> |
Cita:
|
Código:
<?xml version="1.0" encoding="UTF-8"?>Me faltaban un par de campos Código:
<CalificacionOperacion>S1</CalificacionOperacion> <CuotaRepercutida>0.04</CuotaRepercutida> |
Mínimo registros o mínimo minutos
En los sistemas en los que corran muchos usuarios a la vez, puede crearte un problema de saturación de la cola de envío, eso hay que tenerlo en cuenta y ahora no se como resolverlo, por que si el envio maximo son 1000registros y la AEAT no gestiona bien eso y me pone que el envío lo haga cada hora ya la hemos liado, confiemos en que tengan buenos algoritmos.
En lss aplicaciones de escritorio de 1 usuario, da igual el metodo que elijas pero hay que tener en cuenta que si tienes una avería estaría bien tener un sistema preparado para enviar lo que tengas después de los minutos que te dicen, sobre todo para que no te pille un cambio de periodo impositivo en la que tengas que tener el envío hecho antes del día X. Esto "va a trae cola" |
Cita:
|
Cita:
Yo creo que en este caso a TicketBAI basta con que enviéis la anulación. Justo la anulación es para "borrar" (en cieta manera) una factura que se ha emitido de forma errónea (y en casos muy concretos). Tu caso parace uno de ellos. La anulación ya incluye información de la factura inicial, por lo que yo creo que con eso basta. Si enviaras ambas cosas (en ningúna documentación de anulaciones habla de enviar nada más), como tú bien dices, estarías enviando información duplicada. De todas formas, estas dudas puedes enviarlas al buzón de preguntas técnicas para estar 100% seguro. |
Respecto a la polémica de las anulaciones/rectificaciones y desde mi punto de vista (ratificado por conocedores de las leyes): Si una factura es del día o del día anterior y no sale de la empresa, la marco como NULA. Si se ha entregado o es de hace más de dos días, siempre una rectificativa (Hacienda admite nota de crédito o factura rectificativa... así que no me complico calculando si se ha presentado IVA o no). Así que a Hacienda le comunicaré la anulación o la nueva factura.
Estoy dando forma al procedimiento para generación y cálculo del Hash (como algunos de vosotros por lo que veo). La Huella de la factura anterior debe formar parte de la Huella de la nueva factura, pero... ¿Cuál es la factura anterior? Supongo que será la anterior dentro de la misma serie ¿no? Si tengo terminales elaborando facturas autónomamente (auto-ventas en ruta, lineales de supermercados, tiendas remotas, venta on-line....) Cada uno calculará la Huella respecto a su factura anterior, según su serie. A la base de datos central, esas facturas llegarán cada cierto tiempo o al final de día... y si no está sujeto al SII, puede que incluso varios días más tarde. Para el SII, actualmente espero a que todas las facturas estén incorporadas al ERP, se pasan a contabilidad, y una vez contabilizadas (se supone que ya han pasado todos los filtros, rectificaciones y chequeos), se envían a H.P. Normalmente, una factura emitida un día, se envía al SII al día siguiente (si no han habido problemas de comunicaciones). Pero para Veri*factu, es obligatorio enviar la factura inmediatamente, según he entendido, con lo cual no me vale este sistema y trato de replantearlo todo. |
Efectivamente el tema de las facturas hechas en terminales remotos e independientes es algo que me lleva rondando la cabeza desde que empezó este asunto. ¿Un programa de una pda que emite facturas y no está conectado a internet cómo leches lo resuelves? A mi lo mejor que se me ocurre es asignarle el hash cuando se reciban en la base de datos general entendiendo de que ese hash se calculará por series de facturación.
|
Veo que tenéis un pequeño lío con el calculo del hash:
*Primero: hay que calcularlo inmediatamente por que es seguro que parte del Hash irá en el qr del tiquet. *Segundo : la huella de la factura anterior, habrá que esperar definición, ya que depende de varias cosas, por ejemplo de si es software con tecnología de escritorio... Pero lo que si dice la norma es que el encadenamiento no depende de la serie, o sea no hay un encadenamiento por cada serie si emites un ticket desde una máquina y desde la misma máquina inmediatamente después emites otra cosa, una factura ordinaria, una rectificativa o ll que sea, se encadenará con la anterior, en este ejemplo con el ticket. Parece que hay una incongru3ncia con la definición inicial de las anulaciones, ya que el encadenamiento no tiene sentido pues carecen de serie y número correlativo , además eb cada anulación puede indicar que se anulan varias facturas al igual que en las facturas recapitulativas. En el país Vasco las anulaciones no llevan encadenamiento así que no es de extrañar que cambien esto en verifactu. Aún falta mucha información , la doctrina, el xsd completo, el webservice... |
Esquema 1
1 Archivos Adjunto(s)
Os dejo adjunto Esquema 1 de Ayuda
![]() |
Esquema 2
1 Archivos Adjunto(s)
Esquema 2, sin envio
![]() |
Cita:
|
Cita:
Por tanto la definición del SHA-256 ya indican que son 64 digitos en hexadecimal. Entiendo que no hay duda |
Cita:
|
Cita:
Hegenerado el xml con SoapUI como.indicabas a través del wdsl, lo pondré mañana. En él podemos ver como se construye el envío con la posibilidad de incluir varias altas con facturas de simplificadas, normales,rectificativas , sustitutivas o de anulación Cada vez tengo más claro que con lo de la huella el encadenamiento de la anulación está mal definida o va a ser una cosa rara de blockchain |
Cita:
Por supuesto el hash es solo en un sentido y es indescifrable(teoricamente ya qur tenemos los futuros quantum que los 256 se los van a comer con patatas y te generarán en un futuro multiples posibles textos descifrados que serviran de referencia para romper el cifrado y dar posibles resultados con tecnología inversa. ya estan trabajando en nuevos protocolos de cifrado) El sha256=256bits 256bits=64caracteres hexadecimales=32caracteres ascii |
Cita:
|
Soap
Código:
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" |
Cita:
Estoy probando de esta manera a ver si consigo algo: Código:
procedure TForm2.Button1Click(Sender: TObject); |
Cita:
Te lo puedes descargar gratititamente y generar en un momento, lo vas a ver rápido pero tambien hay muchos tutoriales si lo buscas en Google Yo he cambiado los prefijos que me había generado que no me gusta mucho que ponga sum: sum1: ... Es una lástima que uan no haya puesto la referencia del servicio web (Res) de pruebas. Por eso te da error |
Cita:
El problema viene después para el envío de la petición, que me temo que desde Delphi 2007 voy a tener problemas con el certificado. ¿Verdad? |
Cita:
Ya iré poniéndolo. |
Cita:
Si quieres que te ayude con algún tipo de prueba, ya me dices... Un saludo. |
Cita:
Ve adelantandando mirando el funcionamiento de curl.exe , échale un vistazo a los parámetros para que lo asimiles rápido. Esto está al alcance de todos los desarrolladores, da igual que programen en cobol delphi versiones antiguas, vb6.. |
Envio De Soap
Hola, para los desarrolladores que tenemos lenguajes "Arcaicos", hay 2 soluciones que pasan por Curl.exe y depende de la construcción final del SOAP.
Aunque debes revisar a ver si delphi 2007 tiene librería curl. Este metodo de envio lo uso para Factura Electrónica y funciona perfectamente, Faceb y Faceb2b por Soap. Vamos a explicar los parametros del envio: *El envio(Ojo este es para Factura electronica, aún no tenemos los parametros para Verifactu: Código:
curl --connect-timeout 10 --insecure -A "FacturaePHP/1.7.1" -H "SOAPAction: https://webservice.face.gob.es#enviarFactura" --data "@C:\....\...\archivo.xml" --cert-type P12 --cert c:\....\fichero_certificado.pfx:clave -H "Content-Type: text/xml" https://se-face-webservice.redsara.es/facturasspp2 -o C:\....\Respuesta_face_o.html -D C:\...\Respuesta_face_D.html--connect-timeout 10 ----> Tiempo de espera ante eventuales problemas de conexión, es recomeendable por que hay casos en que se eterniza la conexión si hay un problema. --insecure ----> Puede ser necesario para qyue se admitan conexiones SSl poco seguras -A "FacturaePHP/1.7.1" --> Variable CURLOPT_USERAGENT, pueden solicitar que tenga un contenido especifico en caso de factura electrónica es la versión del esquema utilizado: FacturaPhp/1.7.1 -H "SOAPAction: https://webservice.face.gob.es#enviarFactura" ----> Equivale a la variable CURLOPT_HTTPHEADER= Cabecera de Envio. -H "Content-Type: text/xml" ----> Otro Contenido de la variable CURLOPT_HTTPHEADER --data "@C:\tpvision\Facturarealcanasta_FICTICIO_fichero.xml" ---> Fichero a Enviar, construido con el Soap --cert-type P12 --cert c:\....\fichero_certificado.pfx:clave ----> Certificado Electronico y clave, ojo con esto ya que es demasiado visible, hay que intentar que la ejecución al menos sea invisible y no dejar rastro. https://se-face-webservice.redsara.es/facturasspp2 ----> Servicio WEB/RES -o C:\....\Respuesta_face_o.html --> Respuestaen XML se envia al fichero indicado -D C:\...\Respuesta_face_D.html ---> Respuesta Simple Ok,Ko, Error xxx.., igualmente se envia al ficherro indicado, noponer el mismo qu en -o Si en la composicion del Soap pidieran, como en Face algun dato del certificado, por ejemplo la variable publica, el soap podrias hacerlo con php, que eso es otra historia que si hace falta ya lo pondré, y en ese caso el envio lo pdrias hacer tambien en php: Este sería el envio del soap en php, que tambien puedes ejecutarlo con un comando curl desde cualquier aplicacion, si fuera necesario ampliaré esto:: Código:
$ch = curl_init(); |
Una cosa que es jodida:
Curl usa certificados propios (con caducidad) para ejecutarse,así que tened en cuenta que en algún momento hay que actualizarlo. El último de curl.exe caduca en 2028, que además coincide con la intención global de cambiar los métodos de cifrado actuales, hashes y todo lo que venga. Por eso pienso que han reservado un campo en el que indican el algoritmo para el calculo de hash y actualmente solo admite el sha256 |
Cita:
Voy a leerlo con calma unas cuantas veces para digerirlo bien. Una duda. ¿Para generar el fichero xml desde SOAP, como lo haría con el SOAPUI que me comentaste en un post anterior? |
Aunque no son definitivos (y es otro hilo), el envío será similar a los que hemos hecho en otros proyectos con hacienda (en concreto con TicketBAI).
Puedes mirar más ejemplos de envío con CURL en estos hilos: https://www.clubdelphi.com/foros/sho...&postcount=769 https://www.clubdelphi.com/foros/sho...&postcount=737 https://www.clubdelphi.com/foros/sho...&postcount=746 https://www.clubdelphi.com/foros/sho...&postcount=889 https://www.clubdelphi.com/foros/sho...postcount=2996 Aprovechando, que en breve imagino que iremos teniendo algo de código, vamos a utilizar el mismo sistema que otras veces y usaremos el segundo mensaje del hilo para ir poniendo referencias a códigos que los usuarios vayan publicando (el primero queda como resumen de datos importantes). Así, en este primer mensaje del hilo dejamos el resumen, y en este segundo iremos añadiendo referencia a códigos útiles. Es similar a lo que hemos hecho aquí con TicketBAI (segundo hilo con códigos útiles). Pongo aquí la referencia de TicketBAI, porque como el sistema es muy similar, posiblemente los códigos que hemos utilizado para TicketBAI/Batuz serán iguales o muy similares a los que vamos a utilizar en Veri*Factu. Además hay referencias a como hacer las cosas con diferentes componentes e incluso con diferentes lenguajes. Recomiendo a todos aquellos que estáis empezando a codificar o que todavía no lo habéis hecho y estáis pensando cómo hacerlo que dediquéis antes algo de tiempo a revisar este mensaje (creo que os puede ser útil y ospuede ayudar a haceros una idea de los que vaís a necesitar -en cuando a componentes-. |
Cita:
|
Cita:
|
Cita:
Buenos días. Aprovechando el ejemplo que publicaste he estado haciendo pruebas para el envío de las FacturaE, que actualmente lo estaba haciendo manual, y parece que gracias a tu ejemplo, le voy a poder sacar provecho en automático. Lo único que he tenido que retocar es la parte donde se indica la url a la que conectarse. Para que funcione bien tuve que dejarlo así: Código:
"Content-Type: text/xml" -v https://se-face-webservice.redsara.es/facturasspp2" |
| La franja horaria es GMT +2. Ahora son las 02:01:20. |
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