^\||/ Gracias compañero.

Gracias por avisar.
Podrías indicar donde has visto esa información, por que no han cambiado la versión 0.3.2(aunque si el contenido) ni encuentro donde lo han publicado

Vale nada
Lleva cambiado desde esa versión
Pero no me había dado cuenta del cambio.

Acceso a esas noticias vía RSS (además de mediante la web de desarrolladores).
https://www.agenciatributaria.es/AEA.../Novedades.xml


Ahí han publicado la noticia:

Gracias por la info!!

Ok gracias
Por otro lado, alguno sabe como va el desarrollo sobre el control de fichaje, hay algo?

Definición Sistema Informático.
 

Buenos días. Estoy empezando en el tema de verifactu y agradezco de antemano toda la información que se está publicando en el foro y que es de muchísima utilidad.

Me surge una duda tonta en la definición del sistema informático. Si mi aplicación es "Multiempresa", como supongo la mayoría, cada empresa dentro de la aplicación es un objeto tributario distinto.

¿ Qué campo es el que me identificará/diferenciará unívocamente una empresa de otra, ya que supongo que todas las empresas tendrán en común <NombreRazon>, <NombreSistemaInformatico>, etc..... ?

¿ Podría ser <NumeroInstalacion> , además de asignar los campos <TipousoPosibleMultiOT> y <IndicadorMultipesOT> a 'S' ?

Muchas gracias.

Hola
Pues el Nif y/o razón social
Además de tener en cuenta que tienes que llevar por separado las bases de datos, el encadenamiento, los envios, que se vea en que empresa está trabajando cuando estas en la aplicación...

Pensando en alto!!!
Aún me estoy planteando pasar las empresas más grandes al SII y dejar solo las pequeñas a verifactu, es una movida de datos y es más fácil de controlar el SII cuando hay decenas de miles de tiquets diarios aunque haya que enviar las compras y lss faxturas ordinarias que serán poquitas.
Tantos tiquets fijo voy a tener más incidencias que con el SII y tengo más margen.

Dudas desarrollo ténico
 

Ya empezamos, acabo de empezar a leer y ya me estoy podiendo de mala ostia,
yo no soy un buen ejemplo en las redacciones, pero ostias, esto es un tema muy serio
¿alguien lee el proyecto una vez que lo redacta el becario?

Proyecto reglamento técnico
En referencia a los sistemas multiempresas
Artículo 2 Apartado d)
Que leches hay que explicar, ¿En que estado está?¿En que empresa?
Vaya tela como se explican

Seguimos
 

Hay ciertas obligaciones para los No veriFactus que no son aplicables a los Verifactu:

Pero está, que noes obligatoria para los que envian (Verifactu), me chirria:
Articulo 6, apartado f)
Me chirria el punto 1º por 2 cosas. primero por que los verifactu, si detectan alguna brecha no van a estar obligados informar con un mensaje, supongo que sí con el envio de la incidencia en el registro, raro de cojones, y segundo que no dicen que no se pueda seguir facturando, solo que informe y quite el mensaje cuando se arregle.

Disculpa, ¿es requisito tener bases de datos separadas en una aplicación multiempresa? ¿Está ese requisito documentado?

Perdona, te he dicho bases de datos, pero quería decir los registros de datos,(xml) otra cosa es que los guardes en bases de datos.
Sobre las bases de datos no hay ninguna referencia en este reglamento, pero si sobre los registros de facturación.
Según mi apreciacion, aquí puede haber un error, ya que si ese SIF que tiene 2 o mas empresas en el mismo sistema, está enviando por Veri*factu, no tiene por qué conservar registros con lo cual sería una norma solo aplicable a los sistemas No Veri*Factu, además el artículo 8 es para no Veri*factu
O sea que si envías, solo preocúpate de los demás aspectos, que se vea en todo momento en que empresa trabajas, que lleves el encadenamiento por separado y alguna norma qie no está muy clara que he puesto en post anterior

Perdona, te he dicho bases de datos, pero quería decir los registros de datos,(xml) otra cosa es que los guardes en bases de datos.
Sobre las bases de datos no hay ninguna referencia en este reglamento, pero si sobre los registros de facturación.
Según mi apreciacion, aquí puede haber un error, ya que si ese obligado tributario que tiene 2 sistemas está enviando por Veri*factu, no tiene por qué conservar registros con lo cual sería una norma solo aplicable a los sistemas No Veri*Factu.
O sea que si envías, solo preocúpate de los demás aspectos, que se vea en todo momento en que empresa trabajas, que lleves el encadenamiento por separado y alguna norma qie no está muy clara que he puesto en post anterior
I

Fecha emisión / operación
 

A efectos fiscales (IVA, IRPF) ¿Qué fecha hemos de considerar? ¿La de emisión o la de operación?

Recibo una factura con fecha de emisión 02/04/2024 y fecha de operación 30/03/2024. ¿A qué trimestre corresponde? ¿Sabéis?

Gracias

La fecha de emisión es la que prevalece, a no ser que te paguen el día del servicio total o parcialmente, en ese caso hay que declarar en el día 30 el pago y en la emisión se resta la parte que se haya pagado.
Un ejemplo:
Estas de copas a las 11 de la noche del dia 30 en un local y finalizar a las 00.05 del dia 1. El servicio te lo han dado el día anterior pero la dactura se emite y registra el dia 1.

Con carácter general, los modelos de autoliquidación del Iva y IRPF deben incluir todas las operaciones realizadas atendiendo a su fecha de operación, momento en que se produce la prestación del servicio o la entrega de bienes. Si la factura se emite en un trimestre posterior, debe liquidar el Iva en el trimestre anterior ( si la declaración es mensual ocurre lo mismo). Por lo tanto, una operación realizada el 30/03/2024 y emitida el 02/04/2024, devengará el Iva en el periodo 1T si la declaración es por trimestre, en caso de declaración mensual, lo devengará en el mes de marzo.
Hay que tener en cuenta que las facturas rectificativas devengan el impuesto en su fecha de emisión y no de operación, ya que ésta (fecha de operación) , es la fecha en que se realizó la operación que se quiere rectificar. Por último, para abundar más en el tema, si la fecha de operación de una factura es el 31/12/2024 y la emites en 01/01/2025, ocurriría lo mismo, habría que devengar el Iva en el trimestre 4T de 2024.

Llevas razón
El caso que yo he puesto coincidiremos la fecha de operación con la de expedición al día 1. Por el poco margen de tiempo en lss operaciones y tendría que dividir las consumiciones cerrando las operaciones justo a las 12 de la noche si siguen consumiendo, no siento operativo
Lo que si tienes que tener en cuenta que ai es una emisión a una persona física, no autónomo, el mes de emisión no puede ser distinto al de la operación y eln las facturas b2b tienes hasta el día 16 del siguiente mes, pero como bien dices pertenecen al mes anterior tributariamente.

Los colegas han dado las respuestas. Solo voy a resaltar que si te pones del lado del receptor, no estas en el foro adecuado. Los SIF solo se preocupan de las facturas y concretamente de su emisión. Y el periodo para una factura emitida en base las fechas de emisión y de operación es un problema que compete al emisor, no al receptor.

de cara al IVA

Emisor: mes 03 periodo 1T (lo ha de ingresar en 1T)

Receptor: mes 04 periodo 2T (se lo deduce en 2T)

Acentos y Ñ
 

Hola, recuerdo que alguien ya lo menciono, pero para tenerlo claro:
Al pasar los datos , tanto a el xml de una factura electronica, como a los registros de facturacion de verifactu, tengo que convertir las tildes , acentos, dieresis y demas a este formaro:


"á" => "&aacute;"

Seria algo asi verdad?
Perdonad por estas preguntas, pero como lo voy viendo poco a poco, se me pasan algunas cosillas.
Gracias.

Mi pregunta:
Vuestras respuestas:
Muchas gracias a todos. Ha quedado perfectamente claro para mi. Dejadme que subraye la respuesta de sglorka por ceñirse a mi ejemplo, pero agradezco también las demás precisamente por no ceñirse a mi ejemplo y haberme permitido así ampliar mi planteamiento inicial más limitado: por el ejemplo de las copas de ermandalenda y la visión de parte del receptor de antoine0, que no había tenido en cuenta y que aclara perfectamente bilbur; en fin: muchas gracias a todos. :-)

No sé si no te estoy entendiendo bien; disculpa si es así, pero no veo la necesidad de esto. Es un xml. Deberás respetar la codificación señalada (<?xml version="1.0" encoding="utf-8"?>); nada más.

O sea, que sí es importante poder modificar la fecha de emisión y es justo y necesario que se permita desde veri*factu. La situación que proponía sglorka hace ya algún tiempo (https://www.clubdelphi.com/foros/sho...?p=554228#1229) de alguien que siempre factura a final de mes los albaranes del mes pero casualmente un 31 de marzo era festivo y no fue hasta el día 1 de abril cuando pudo ponerse con este proceso... Poder establecer la fecha de emisión permite que el receptor también declare las compras hechas en el periodo en que realmente se hicieron.

Entiendo que de cara al IRPF no sabes cómo es ¿Sabe alguien si también es así? Por ejemplo, en el modelo 130 ¿Se considera la fecha de operación en las ventas y la de emisión en las compras?

Y si en la factura también se indica la fecha de operación ¿El comprador puede utilizar esta fecha o necesariamente ha de atenerse a la fecha de emisión?

Si usas un software antiguo y tienes que escribir a pelo los nodos en un output debes convertir a utf8 los caracteres más especiales, ñ, á,à,â,âçć.... pero si no solo tienes que indicar que es UTF8 para que se haga todo automáticamente. Igual para leer los xmls utf8, si tu software no los interpretas tendrás que convertirlo.
Yo no lo hago como has indicado, tengo los caracteres utf8 equivalentes de los más usados y del resto de caracteres demasiado especiales los cambio a un espacio.

De esta forma me va bien a mí:

Hola, gracias por vuestras respuestas, lo revisare , la base de datos la tengo creada, como utf-8-spanish-ci , supongo que al alimentar el xml directamente no habra problema.
Uso visual Studio c# 2015, en cuanto termine de migrar todo , probare si genera correctamnete las facturas Factura-e.

El modelo 130 es para determinar una provisión. Solo importa lo que está en la contabilidad de la empresa, en gastos y ingresos, en el momento de hacer la declaración. Es perfectamente posible que para las compras, se considere la fecha de operación de cada una de las recepciones (que no tiene por qué ser la única fecha de operación indicada en la factura recapitulativa). Para las ventas nacionales, normalmente si vendes con portes pagados debes esperar la confirmación de la entrega de parte del transportista para registrar el ingreso; pero puedo entender que se registre con la fecha del albarán de salida del almacén.

No puedes registrar en tu contabilidad una factura recibida con una fecha anterior a la fecha de emisión (lo que decía Bilbur).

Tengo que hacerte una observación. La posibilidad de emitir rectificativa por error en fecha de expedición era porque el destinatario es un particular, y sólo en este caso, estamos OBLIGADOS a emitir la factura a final de mes. Si es un empresario o profesional, se puede emitir la factura antes del 16 del mes siguiente.
Si un empresario recibe físicamente, una factura con fecha de expedición 01/04/2024, el día 10/04/2024 (porque venía por correo ordinario) por las operaciones realizadas en el mes de marzo, el empresario puede deducirse el Iva en el periodo 1T ya que tiene hasta el día 20 de abril para hacerlo. El derecho a deducción nace en el mismo momento en que se produce el devengo del impuesto, siempre y cuando, tengas físicamente la factura recibida en tu poder. Si por algún motivo se te olvida deducírtela en 1T puedes hacerlo el las declaraciones posteriores hasta un margen de 4 años. El IRPF funciona igual, si un gasto es deducible lo podrás imputar si se ha producido el devengo del impuesto.

Cita literal

"El devengo es el momento en el que nace el ingreso o gasto. En derecho tributario, el devengo de un impuesto es el momento en el que nace la obligación tributaria aunque todavía no sea exigible. El pago es el momento en el que dicha obligación tributaria es exigible"

Que buena explicación, gracias.

Macrodato
 

No veo clara esta utilidad... ¿Cómo lo tenéis implementado? Ese importe de ¿100.000 €? lo tenéis como constante y preguntáis al usuario si es correcto en cada factura. Es la única forma de ver su utilidad porque si simplemente se informa el nodo con un S(í) o un N(o) en función de la cantidad no tiene ningún sentido. Pero la pregunta que se haga al usuario puede ser un poco rara: Me imagino un "Vaya tocho de factura ¿No te habrás pasado?"; vale, puede ser bastante más sutil: "Factura de alto importe; no hay error ¿Verdad?". Sin embargo, no me parece que este sea un control importante a añadir; a fin de cuentas, si te has confundido y a alguien le has facturado unos cientos de miles más de la cuenta, seguro que si tú, como emisor, no te has enterado, al destinatario no le va a pasar desapercibido.

[OFF-TOPIC]
Gracias nuevamente a ambos por la aclaración. No parece excesivamente complicado (al menos, no para vosotros) pero ¡Me arde el cerebro considerando las matizaciones!
Por cierto, siento añadir un post sin información práctica para el grupo (la info ya estaba ahí) pero tengo la necesidad de agradecer las respuestas. Sería estupendo añadir un check (o algo así) para hacer saber al autor que me ha resultado útil...

Buenas, veo que a fecha de hoy hay publicado esto:

NumeroInstalacion
 

He puesto la definición que se da en el Excel del diseño de registro (pestaña 5: Definición SistemaInformatico) pero no me entero de qué quiere decir. ¿No es suficiente con la versión del SIF para diferenciar instalaciones pasadas de presentes y de futuras?

¡Muchísimas gracias! ¡Estupendo aporte!

Una pregunta de principiante,

La diferencia entre los sistemas Verifactu y No Verifactu ¿ Es sólo que el no verifactu no envía automáticamente la factura ?

Gracias

Cada instalación debes identificarla y que no esté r3petida, tu lo identificas como quieras.
Un ejemplo concatenar : cif+numero de comercio+nunero de tpv

Esencialmente es que además si nk envía tienes que tener en cuenta los registros de eventos, firmar los xmls y que conserves perfectamente los archivos los años que hacen falta 4 ó 5 no recuerdo

No.
El envío es lo de menos.
Si no estás en veri*factu hay una serie de premisas que tu sistema DEBE cumplir; Esas mismas premisas si estás en veri*factu se asume que ya se cumplen al enviar la factura a la AEAT.

Esta es una imagen de una dispositiva de las primera presentaciones.
Busca referencias a los elementos a los que se hace referencia en la parte derecha.

De nada , me alegra que le sea util a alguien mas.

Gracias por la respuesta, también a ermendalenda.
Mi pregunta va en la línea de que Verifactu exige el encadenamiento e integridad (con hash) de las facturas, que son requisitos de no verifactu
Si hago mi programa compatible con Verifactu ¿ Podría ser suficiente para que sin enviar los .xsig fuera compatible con No Verifactu ?