Facturas electrónicas [España]

[ermendalenda]

Empezado por keys

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.

[ermendalenda]

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.

[ermendalenda]

Empezado por ermendalenda

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.