^\||/ Gracias compañero.

Gracias por la info.
^\||/^\||/^\||/

Hola, muchas gracias por el aporte.
Parece contradictorio, para mi el cliente es el que paga, no el que cobra.. serias tan amable de aclara si es el que paga o el que cobra el que cambia el estado.
Gracias y saludos

Bueno días,

Ayer hubo un Seminario Informativo por parte de la AEAT, sobre novedades en diferentes parcelas.
También hablaron de la Factura Electrónica:
- No confirmaron fechas de publicación, más allá de decir que entraría en vigor 1 año después de la publicación del reglamento para las empresa de + 8 millones de facturación y 2 años para el resto.
- Se dieron 9 meses, a partir de la publicación, para que esté disponible la Plataforma Pública y el entorno de pruebas.
- Más allá del hecho de que las plataformas privadas admitan otros formatos, confirmaron que la Plataforma Pública, tras conversaciones de sus grupos de trabajo, usará el formato FACTURAe, y servirá como almacén central de todas las facturas enviadas.
- Las plataformas Privadas estarán obligadas a enviar a la Pública todas las facturas que reciban, pero no quedó claro quien deberá transformar a formato FACTURAe.

Creo que eso fue lo más importante de lo que se habló.

Hola, te refieres a este seminario https://www.agenciatributaria.es/sta...IF-FE-1123.pdf ?

Sí, efectivamente. En él se hablo tanto de la Ley Antifraude como de la Factura Electrónica, que es lo que en este foro nos atañe.

Chorus
 

Pués eso, "Chorus" va a ser la plataforma gratuita con el servicio mínimo para cumplir la B2B

https://sede.agenciatributaria.gob.e...ta-sesion.html

Mirándolo por encima pone esto.

En teoría en la última presentación de hacienda se dijo que sería sólo FacturaE. Igual algún día se aclaran.

Buebo si facturae es el formato del xml pero la plataforma gratuita puede llamarse chorus o choris!ñ o como quieran. Pero no dijeron la única, dijeron que podia ser privada. Lo que creo que si decían que todas tenían que comunicarse finalmente a la plataforma gratuita de la aeat.
Enfin parece que aún no está claro tal y como dices.

Hay dos significados para EDI:

1. En general EDI significa intercambio electrónico de documentos. Técnicamente Factura-E es uno de los múltiples formatos posibles para facturas enviadas por EDI; entonces en tal caso la frase arriba no prohíbe el uso de Factura-e para facturas electrónicas: al contrario, la frase autoriza cualquier formato, si es estándar.
2. Ahora bien, muy a menudo EDI se entiende como EDIFACT, el formato heredado de los Americanos de las 70s y normalizado por Naciones Unidas en 1985:cool:, con sus UNB/UNS/UNT y sus ' al final de las «líneas» (e incluyendo a menudo también su translación a XML). Este formato es efectivamente muy habitual en las relaciones entre organizaciones.

Si EDI es meramente un sinónimo de facturas electrónicas, todo este frase es meramente una descripción de lo que es el EDI :o.
Alternativamente, puede ser que intentan asegurar a las empresas que utilizan formato(s) EDIFACT para publicar sus facturas, que nada tienen que cambiar: continuarán enviando sus facturas en el formato existente (si es conforme a la norma EN16931).
Y no hablan de prohibir cualquier otro formato que no siga EDI(FACT).

No creo que tampoco han dicho nunca que sería sólo Factura-E. Entre otras razones, por qué hay una normativa de la U.E. (directiva 2014/55) que obliga los estados a aceptar dos formatos, CII y UBL (decisión de ejecución 2017/1870/UE), en todos los países, en paralelo con posibles estándares nacionales (como es el caso de Factura-E en España) y normas de facto (como parece ser es el caso para EDIFACT en España).
El artículo 6 del proyecto de RDL recoge explícitamente estas cuatro opciones, sin hacer ninguna distinción entre ellas.

Esto es lo que dijeron en la reunión.

Y a mi se me ocurre una pregunta tonta a raiz de la movida esta de las facturas electrónicas.


¿Cuando esto esté en marcha para todo el mundo tendrá sentido las plataformas tipo EDI?


Saludos.

Creo que sí. Para empresas de tamaño medio-grande que tienen informáticos en casa que han desarrollado un sistema súper-integrado para emitir y recibir los archivos EDIFACT (de los cuáles facturas INVOIC es solo una parte). No tienen que cambiar nada, ya lo tienen todo cocinado.
Incluso para un importe relativamente modesto podrían recuperar en formato electrónico las facturas de sus proveedores, luego desarrollar una herramienta que hace el cotejo de estas facturas contra las pendientes de recibir que tienen en cartera; y soñar, si este desarrollo sale bien, a poder «rentabilizarlo» sobre el departamento de Compras de la empresa... :(

De hecho, es la música que algunas plataformas EDIFACT están vendiendo ahora mismo. (O intentan vender; no sé si sale a cuenta, ya que tengo mis dudas sobre el rendimiento del cotejo; pero sus departamentos de marketing no paran).

Las que veo peor son las empresas, a menudo fabricantes de impresoras, que han vendido sistemas de G.E.D. con, básicamente, el mismo objetivo final («desengrasar» los departamentos de Compras), en las últimas 10-15 años. Dentro de poco la misma función será bastante más sencilla, solo se deberán recuperar las facturas en formato estructurado desde la plataforma SPFE. Si tienen una función de cotejo que funcione bien, entonces estupendo para ellas, van a poder rentabilizarla. Si no...

Confirmado Facturae
 

Buenas amigos, en el seminario del día 14/2/24 han confirmado que el punto de entrada público(gratuito) será en formato Facturae, donde todos tendremos que enviar, ya sea a través del punto de entrada que contratemos a través de otra empresa o directamente, los servicios se suponen que serán parecidos a los actuales de face y faceb2b, consulta de administrcionws de un cif etc.
Ya os digo que esto tiene mucho curro, yo ya he empezado y para intentar evitar errores sobre los datos administrativos de las empresas a las que envías hay que currarse las consultas, os recomiendo también descargaos los códigos postales de todo el territorio español para que al poner el cp os aparezca la localidad y provincia
Dejad rn las bases dr dato un campo de más de 10caractwres pata el dir de la administración ya q8w me da la sensación de que alguna vez lo tendrían que ampliar.
Tened muy en cuenta si es persona física o jurídica para generar el xml 1ue cambia mucho.
Para saber si es persona física o jurídica para los nifs y nie españoles se puede saber por la configuración del código identificativo.
Hay que currar muchísimo para dárselo fácil al usuario.

^\||/ Gracias compañero. Al final se las apañarán para que nos caigan a la vez los dos truños Verifactu y Factura Electrónica. :mad::mad:

Verifactu Vs Factura electrónica
 

Post erroneo

Verifactu Vs Factura electrónica
 

No sé si alguien con más experiencia en factura electrónica sabe la equivalencia entre la factura sustitutiva o de canje con la factura electrónica.
Se me ocurren 2 formas:
Factura completa, insertando los documentos pdf de los tiquets
Factura recapitulativa e indicando fecha y número de tiquet de cada operación

Pero ninguna de las 2 formas encaja 100%

A mi entender, las facturas electrónicas hay que subirlas cuando se emiten a una persona física o jurídica. Las facturas simplificadas sin identificación del sujeto, no tiene sentido ser enviadas a la plataforma, ya que es una plataforma para el intercambio de facturas entre empresas y autónomos. Otra cosa es el verifactu... ahí sí hay que enviarlas una a una, nada de recapitular, ya que cualquier cliente, con su ticket, tiene que tener la posibilidad de consultar si ese ticket está subido correctamente a la AEAT.

Otra cosa. He leido esto en un artículo:

No lo entiendo bien... Se supone que el punto de entrada habrá que poner el DIRe de la empresa/autonomo receptor de la factura, para que éstos puedan recibir dichas facturas. ¿Qué pinta el software privado que usen?

Buebo estoy programando ya para factura electrónica, y sí, si admiten varias opciones facturas sinplificadas, ordinarias y eecapitulativas. Ahora bien, la simplificada puede bo tener mucho sentido o sí, ya que aunque sea simplificada se la puedes enviar a alguien con cif, por ende ya está nominada. Lo mismo va por ahí el asunto de la sustitutiva para las electrónicas.
Por otro lado, ese artículo de que fuente es ?
Eso podría hacerse sí facturae ampliase la estructura añadiendo otros nodos (proveedor o punto de entrada) y un campo dir3 más amplio, que actualmente sólo es de 10 caracteres.
No me extrañaría, pero por lógica la historia sería más normal justo al revés, o sea. El que tenga otro proveedor ya tendrá que currarse el proveedor de leer las facturas del punto de entrada público o incluso que estén todos los proveedores a crear ese punto de entrada público para enlazar. Así el comprador puede dar el dir3 de facturae o el del proveedor según el comercio, pienso yo que para no liar darán siempre los 2.
Por otro lado facturar admite el nodo "extensiones" lo cual sería una gran putada para nitroso que intentase que metieras ahí a todos los proveedores, ya que al final estaríamos en las mismas, para que quiero un punto de entrada público si no hay capacidad de tener en cuenta todas las extensiones....pero se me ocurre tb que hagan alguna extension común para enviar a cualquier proveedor, por ahí pueden ir los tiros, aunque también pueden querer aprovechar el nodo de información adicional de la factura para no tener que cambiar ni añadir estructuras
Hay muchas posiblidades

Si no recuerdo mal en la charla de la aeat dijeron que todas las facturas tienen que ir al punto de entrada público, tengan o no contratado uno privado.

Si quieren controlar la morosidad (que creo que no va a ser lo unico que controlen) debe ser asi. No van a estar conectándose ellos a todos.
Creo que este control va a ir más allá y no sé hasta donde llegará ese control de morosidad y que recogerá el reglamento, me temo que vamos a tener que estudiar nos también los temas relaci9nados con límites en las fechas de pago...
Al final me voy a hacer asesor fiscal en vez de programador.
Vaya tela.

Sobre Nodos facturae
 

Hola, sigo analizando facturae.
En cuanto a las equivalencias de tipos de factura:
-Para la sustitutiva ya que no hay una equivalencia explicita y como facturae está concebida para cobrar y pagar ( no es reporte a la AEAT), entonces Factura Sustitutiva(Verifactu)=Factura Completa(Facturae)
-Y ahora al revés, Factura Recapitulativa Facturae(albaranes, notas de entregas convertidas a factura)=Factura Completa Verifactu


En cuanto nodos que no contemplamos normalmente y que hay que tener en cuenta:
-Ibank=Cuenta donde solicitamos la transferencia (Si solitamos pago por transferencia)
-INETownCode=Código población segn el INE(Ojo no es el código Postal, podeis descargaros del INE la tabla, lo que es complicado es establecer la relación de las direcciones con los codigos de poblacion y los codigos postales, ni siquiere la Seguridad Social lo tiene bien, pero podeis dejarlo sin relacion y que lo escriban, aunque seguro el usuario se va a equivocar muchisimo si no vinculais y dais una ayuda)
InstallmentDueDate e InstallentAmountDate=Fecha e importe del efecto, pertenecen al nodo Installments(se repite tantos efectos tengas). Una factura puede emitirse para que pague en otra/s fecha/s, por transferencia o por otro metodo, aqui debes poner la/s fecha/s e importes
-AdministrativesCentres= Son datos opcionales que tendrá que darnos el cliente si quiere que le emitamos las facturas según estos Roles. Por ejemplo una empresa que tenga distintos centros de operaciones por provincia, tendremos que tener creado al mismo cliente con distintos centros administrativos para que cada uno accesa a sus facturas.
-AdditionalData=Esto va a ser un nodo importante en el que agregaremos información adicional. Casi seguro en un subnodo de este nodo insertaremos el QR(en modo texto), podremos insertar el pdf de la factura en un formato especifico para poder insertarlo, por ejemplo en BASE64.

Otros datos importantes que teneis que tener en cuenta:
CountryCode= a Rellenar según tabla de codigo de paises Alpha 3, que son los códigos de los paises en 3 caracteres según la normatica ISO 3166-1, que es la que usa facturae, aunque la nueva ley habla de la obligatoriedad de emitir al menos para los clientes de España, no sé si se va a dar algún caso en que haya que meter el codigo de pais por el tipo de cliente que no sea residente y sea de la UE, recordad que el CodigoPais para verifactu es Alpha 2.
Tipo de Cliente: Persona Fisica o Juridica=Es facil establecer (Para los nifs, cifs, españoles) si es Fisica o Juridica, pero dejaos un campo a rellenar por si las moscas.

Por aclarar lo de los códigos postales.
Correos tiene sus parcelas de reparto para dividirlos por oficina (códigos postales) que no tirne que coincidir con los códigos de municipios que son códigos,como su nombre indica, de municipios para que cada administración del municipio al que pertenece, trate los datos, aytos, etc.
Esto quiere decir que un código postal puede estar en más de un código de municipio y esto lía un poco a los desarrolladores si quiren establecer vínculos directos. Y ya para liar más, hasta una misma calle puede pertenecer a varios códigos postales pero pertener a un solo municipio.

Face B2B
 

Buenas,

Están cambiando la WEB de face y la de face B2B actualizando los documentos.
Tengo una duda ¿los WS para mandar a la administración publica son distintos de los de entre empresas?
Y en tal caso ¿Dónde encuentro los de admiración publica ?


Gracias,

Las estructuras (esquemas ) de generacion del fichetro son las mismas perono los de los de envíos y respuestas lss ws son distintas en sitio y esquemas de envío y respuesta Face tiene su ws de pruebas y de producción y faceb2b los suyos. Ahora estoy con el móvil pero te los busco y te los pongo en cuanto pueda.

Te dejo documentacion.

Aqui los Endpoints de conexion:
//************************************
//************* FACE **************
//************************************
// ENTORNO DE PRODUCCION
"https://webservice.face.gob.es/facturasspp2" :

// ENTORNO DE PRUEBAS
"https://se-face-webservice.redsara.es/facturasspp2";
//************************************


//************************************
//************ FACEB2B ************
//************************************
// ENTORNO DE PRODUCCION
"https://ws.faceb2b.gob.es/sv1/invoice" :

// ENTORNO DE PRUEBAS
"https://se-ws-faceb2b.redsara.es/sv1/invoice";
//************************************

Preproducción RPC Literal
https://se-ws-faceb2b.redsara.es/sv1/clients?wsdl
Preproducción RPC Encoded
https://se-ws-faceb2b.redsara.es/sv1/ie/clients?wsdl
Producción RPC Literal
https://ws.faceb2b.gob.es/sv1/clients?wsdl
Producción RPC Encoded
https://ws.faceb2b.gob.es/sv1/ie/clients?wsdl

https://www.google.com/url?esrc=s&q=...s0xp-AtugHBKHb
https://www.google.com/url?esrc=s&q=...LZsQGz6jKS3Eit
https://www.facturae.gob.es/politica...turae_v3_1.pdf
https://www.google.com/url?esrc=s&q=...goYHSqSd7wmLGr
https://www.collegesidekick.com/study-docs/1339157

No sé si funcionan todos los links. Si no te pongo los nombres de los pdfs y te salen el enlace de gob.es para descargarlos en google

Ws
 

Gracias. Tiene pinta que dentro de poco sacaran la normativa de ley Crea y crece y nos va a volver a tocar ponernos con esto otra vez.

Espero que tarden, aunque yo ya estoy trabajando sobre ello por que la base Facturae es lo más probable y dific8l es que cambien de opinión. Eso sí, tiene la pinta que el esquema facturae tenga algunos cambios, pero no creo que demasiado, ya que el tema de los programas de las administraciones cuesta mucho renovarlos

Referencias legales en facturae
 

Hola. Estoy tratando de establecer un proceso de facturación electrónica con una empresa en base al estándar facturae v.3.2. Esta empresa en su guía de uso EDI, establece que en el apartado de literales legales, es obligatorio cumplimentar las referencias (<LegalReference>) "Certkey" y "Hashkey". ¿Alguien sabe qué demonios es esto? No he conseguido encontrar ninguna información al respecto. Muchas gracias por la ayuda.

Hola, estoy buscando lo mismo pero no encuentro información. Continuo en la busqueda y en el caso de encontrar te lo apunto en el hilo. Suerte.

Buenas.


Yo genero facturas compatibles facturae en distintos clientes para facturar a organismos públicos, no relleno esos campos que comentas y no es mayor problema.



Donde si relleno el apartado <LegalReference> es cuando son facturas que hago para el Kit Digital pero ahí lo único que va es un texto similar a esto:

-<LegalLiterals>

<LegalReference>Financiado por el programa Kit Digital. Plan de Recuperación, Transformación y Resiliencia de España "Next Generation EU". IMPORTE SUBVENCIONADO ..... /LegalReference>

</LegalLiterals>


No sé si esto te servirá.
Saludos.

Como generar una facturaE
 

Buenos días,

Estoy buscando algún ejemplo o tutorial para generar una factura electrónica en XML a partir de la estructura definida en Facturaev3_2_2.xdb publicado por la administración.
Sabéis donde puedo encontrar ayuda sobre este tema. Necesito solamente generar los XML en el formato correcto.

Muchas gracias y saludos.

Yo en particular genero los XML usando el componente TXMLDocument. Cuando tengo dudas de cómo implementar algún dato en el XML lo que hago es crear un ejemplo en el programa facturae, exportar el XML y ver cómo lo genera. Imagino que podrás encontrar ejemplos de uso del componente por internet, si no es así me lo dices y miro de enviarte un extracto de esa parte de mi programa.


Saludos.

Te tendrían que ampliar información, es raro que te pidan una clave de certificado y el hash(que tampoco te dicen si es el público o el privado). Pero si lo tienes que meter en legalrerefencee es para uso interno para el emisor o el receptor, tiene pinta que en vez de firmar el xml lo que hacen es meter las claves ahí para comprobar la validez, en cuyo caso sería una chapuza.

Muchas gracias newtron,

Si con TXMLDocument es como lo intento hacer, ya he trabajado con este componente antes para generar los ficheros SEPA de comunicación con los bancos y todo bien pero, ahora no consigo generar las facturas correctamente.

Mediante XML data binding he importado el esquema y he generado la classe pero no acabo de entender como crear el XML correctamente.

Un ejemplo me iria muy bien, gracias.

Saludos

Ok pásame un correo por privado y te envío un .txt con el código para que le eches un vistazo. Es largo como para ponerlo por aquí.

BtG
 

Buenas noches. No sé si alguien más le ha dado vueltas a un asunto.
Para evitar errores de los usuarios estoy intentando que el cif identifique el tipo de factura electronica que vamos a confeccionar, ya que hasta ahora, en España, Face es para BTG y facebtb es la plataforma y punto de entrada gratuito para el resto, y sinceramente creo que Face va a seguir existiendo separadamente del r3sto.
BTB(empresa a empresa)
BTC(empresa a consumidor final)
BTG(empresa a organismo publico)
El BTC no sé si la información a incluir según sea autónomo o persona fisica(sin ser autonomo )tienen diferencias, le echo un vistazo a Facturae a ver si hay diferencias en la confección.
El BTG creo que los cifs tienen letras específicas para todos los organismos públicos: algunos empiezan por S etc..
Si tenéis algo sobre esto, ruego información de todas formas iré informando de los resultados, a ver que sale.

En este enlace los explican:

https://dudaslegislativas.com/labora...tre-cif-y-nif/

y algo interesante de lo que me acabo de enterar:

Gracias "Sxxxxxxxx", "Pxxxxxxxx","Exxxxxxxx" y "Qxxxxxxxx" = posibles B2G = posible Face (De momento), pero acabo de ver en redsara que hay cifs normales que empiezan por ejemplo por "A", asi que poco me sirve esta idea,


Os dejo un enlace interesante
https://edicomgroup.es/blog/la-factu...esas-espanolas

face
 

Si no me equivoco, las referencias de la ley crea y crece sobre la factura electronica, van dirigidas a las facturas B2B (Entre Empresas), pero no dice nada sobre B2G (De empresa a organismos publicos). Pero tengo una duda sobre las B2G o sea sobre Face en España, a ver si alguien me lo puede resolver, por que seguramente me surja la misma duda (o parecida) con las B2B ya que la base, en principio, va a ser Facturae también.
A ver, cuando una administracion te pide una factura hay que indicar la tripleta de códigos DIR3, obligatoriamente: Oficina Contable, Unidad Tramitadora y Organo Gestor. Además les pueden asignar otro nombre. Hasta aquí bien. El problema es que hay un nodo que no termino de entender y no sé si tiene relación con el tipo de este triplete de Dir3, este es el RoleTypeCode, o sea, si yo elijo estoy dando de alta la unidad tramitadora, ¿Me tienen que dar el Roletypecode? ¿Es obigatorio? ¿El Roletypecode para la unidad tramitadora puede ser cualquiera de los 9 opcionales o está restringido según la Unidad Dir3 que estoy dando de alta?
No encuentro documentación al respecto, aunque si he visto que para las 3 unidades Básicas del trplete siempre he encontrado el mismo Rol, pero no sé si es coincidencia.