SII -Nuevo sistema de la Agencia Tributaria española de envío de datos vía Webservice

[keys]

Empezado por vboloradito

ME estoy liando con los pagos.

Solo hay que enviarlos cuando son pagos en metalico. Mi empresa no tiene.

El libro de pagos en metalico parece que ha desaparecido, ¿es asi?

Los libros de cobros y pagos sólo son para las empresas que están en el regimen de criterio de caja, ya sea el cliente o el proveedor. Sólo en ese caso habrá que rellenar estos libros y da igual que sea en efectivo o no.

Otra cosa es el libro de cobros de operaciones en metálico que hay que hacer para los cobros que durante el año han superado los 6000 euros. Solo se presentan una vez al final del año. Este libro esta dentro del libro de operaciones de transcendencia.

Un Saludo.

[PASPAS]

Empezado por keys

Los libros de cobros y pagos sólo son para las empresas que están en el regimen de criterio de caja, ya sea el cliente o el proveedor. Sólo en ese caso habrá que rellenar estos libros y da igual que sea en efectivo o no.

Otra cosa es el libro de cobros de operaciones en metálico que hay que hacer para los cobros que durante el año han superado los 6000 euros. Solo se presentan una vez al final del año. Este libro esta dentro del libro de operaciones de transcendencia.

Un Saludo.

Hola Keys, tienes algún ejemplo XML de cómo enviar el cobro o pago de tipo RECC. Lo voy a implementar ahora y no me queda claro si puedo realizarlo de forma separada. A priori el WDSL están las peticiones por separado pero claro se tendrán que crear primero siempre el registro de la factura primero y posteriormente enviar el cobro. Pasará lo mismo con recibidas.
Luego tengo también dudas de cuando informar de estos datos ya que a mi parecer debe ser siempre que se haga efectivo el ingreso (Fecha cobro / pago).
Muchas gracias

[keys]

Para poder enviar un cobro/pago del RECC logicamente tiene que estar la factura previamente dada de alta con tipo de operacion 07, ya que sino el sistema de rechaza el cobro o el pago. Los cobros y pagos tienen que ir por separado de las facturas, tienen un wsdl diferente.


Luego tengo también dudas de cuando informar de estos datos ya que a mi parecer debe ser siempre que se haga efectivo el ingreso (Fecha cobro / pago). Para esto mirate la normativa pero no es asi.En las faqs de hacienda la tienes bien explicado.

Un Saludo.

[PASPAS]

Empezado por keys

Para poder enviar un cobro/pago del RECC logicamente tiene que estar la factura previamente dada de alta con tipo de operacion 07, ya que sino el sistema de rechaza el cobro o el pago. Los cobros y pagos tienen que ir por separado de las facturas, tienen un wsdl diferente.


Luego tengo también dudas de cuando informar de estos datos ya que a mi parecer debe ser siempre que se haga efectivo el ingreso (Fecha cobro / pago). Para esto mirate la normativa pero no es asi.En las faqs de hacienda la tienes bien explicado.

Un Saludo.

De acuerdo es lo que pensaba primero siempre envias la factura y posteriormente el cobro/pago.
Mi duda surge cuando un cliente no te paga o se demora tanto el pago que cambia de ejercicio cuando se hace efectivo. Creo que en este caso se debe utilizar : 03: No se cobra/paga. Ocurriria lo mismo del cobro que no esta vencido o ingresado a fecha?.
Por tanto mi duda es cuando tengo varios aplazados como debemos operar.
Por ejemplo:
Factura emitida el 18-03-17. Enviada al sistema
Tipo: Aplazado con 3 vencimientos
18-04-17- Ingresado
18-10-17 - No ingresado
18-01-18 - No ingresado

Yo pensaba implementar el envio de cobros una vez realizado el ingreso ya que para mi no esta cobrado ademas estan las posibles devoluciones , etc...
No entiendo muy bien este apartado de presentacion RECC.

Si podeis el que tenga claro esto del RECC seria muy util que enviarais ejemplos de XML. Con ejemplos de escenarios posibles ya que veo que se puede complicar este tema.

Muchas gracias

[keys]

8.3. En el caso de que efectuada una compra no se satisfaga el pago en los plazos establecidos y el nacimiento del derecho a deducir se produzca el 31 de diciembre del año posterior al que se realiza la operación. ¿Cuál es la fecha que debe registrarse como pago de la operación?

El 31 de diciembre del año posterior al que se realiza la operación por ser la fecha de devengo. Los posteriores pagos no generarán anotación alguna.
En el campo “Medio de Pago/Cobro” se consignará el valor 03.


El problema no esta en el fichero xml, ya que es de los más sencillos, el problema esta en la gestión de todo esto.

[PASPAS]

Empezado por keys

8.3. En el caso de que efectuada una compra no se satisfaga el pago en los plazos establecidos y el nacimiento del derecho a deducir se produzca el 31 de diciembre del año posterior al que se realiza la operación. ¿Cuál es la fecha que debe registrarse como pago de la operación?

El 31 de diciembre del año posterior al que se realiza la operación por ser la fecha de devengo. Los posteriores pagos no generarán anotación alguna.
En el campo “Medio de Pago/Cobro” se consignará el valor 03.


El problema no esta en el fichero xml, ya que es de los más sencillos, el problema esta en la gestión de todo esto.

Si claro el XML es sencillo, me refiero al proceso en si.
Exactamente lo que no tengo claro si gestionarlo conforme indico.
Pero me huele a que es necesario enviarlo todo aun si no esta cobrado por tanto no entiendo muy bien dicha gestion porque se hara en funcion del estado del cobro/pago que tenga en ese momento y luego nuestro sistema realiza un cambio de estado y esto gestionarlo lo hace inviable.
Por eso necesito saber o ver posibles ejemplos porque no lo tengo nada claro y tengo la sensacion que implementare y tendre que rehacer...
Sobre el ejemplo que he indicado como lo enviarias?? solo 1 registro de cobro o los 3?

[keys]

En criterio de caja, hay que declarar la factura cuando se produce. Y luego tantos cobros/pagos se realicen. Es decir lo que no se cobra/paga no se envía.

En tu ejemplo

Factura emitida el 18-03-17. Enviada al sistema //S envia con fecha del 18-03-17 como cualquier factura pero con tipo de operacion 07

Tipo: Aplazado con 3 vencimientos
18-04-17- Ingresado //Se envia un registro de cobro el 18/04/2017 por que es cuando se hace el cobro
18-10-18 - Ingreesado //Esto hay que enviar un registro de cobro el 18/10/18
18-01-18 - No ingresado //No hay que enviar nada hasta que se produzca el cobro.

Si a 31 de diciembre del ejercicio 2018 (Es decir a 31 de diciembre del ejercicio siguiente de la fecha de factura) hay que declarlo en el libro de cobros con fecha 31/12/2018 En el campo “Medio de Pago/Cobro” se consignará el valor 03.

[PASPAS]

Empezado por keys

En criterio de caja, hay que declarar la factura cuando se produce. Y luego tantos cobros/pagos se realicen. Es decir lo que no se cobra/paga no se envía.

En tu ejemplo

Factura emitida el 18-03-17. Enviada al sistema //S envia con fecha del 18-03-17 como cualquier factura pero con tipo de operacion 07

Tipo: Aplazado con 3 vencimientos
18-04-17- Ingresado //Se envia un registro de cobro el 18/04/2017 por que es cuando se hace el cobro
18-10-18 - Ingreesado //Esto hay que enviar un registro de cobro el 18/10/18
18-01-18 - No ingresado //No hay que enviar nada hasta que se produzca el cobro.

Si a 31 de diciembre del ejercicio 2018 (Es decir a 31 de diciembre del ejercicio siguiente de la fecha de factura) hay que declarlo en el libro de cobros con fecha 31/12/2018 En el campo “Medio de Pago/Cobro” se consignará el valor 03.

Muchisimas gracias...

[[newtron]]

Hola de nuevo.

He tenido una reunión con un asesor para otros temas y me ha preguntado por el asunto SII. Yo tan feliz le digo...."pues está medio controlado"... después me pregunta por el concepto de las facturas y me ha dejado pillando moscas. Yo hasta ahora no le había hecho mucho caso a ese asunto pero me comenta que en hacienda dicen que hay que esmerarse con ese tema así que habrá que ver qué hacemos al respecto.

Seguramente tendremos una reunión con uno de hacienda que dice que domina el SII y le preguntaré al respecto, ya iré informando.

Saludos

[CMB]

Empezado por newtron

He tenido una reunión con un asesor para otros temas y me ha preguntado por el asunto SII. Yo tan feliz le digo...."pues está medio controlado"... después me pregunta por el concepto de las facturas y me ha dejado pillando moscas. Yo hasta ahora no le había hecho mucho caso a ese asunto pero me comenta que en hacienda dicen que hay que esmerarse con ese tema así que habrá que ver qué hacemos al respecto.
Seguramente tendremos una reunión con uno de hacienda que dice que domina el SII y le preguntaré al respecto, ya iré informando.

Si te refieres al tag DescripcionOperacion, pues sí, sería muy interesante saber lo que hay que poner ahí. Después de que aquella jefaza de Hacienda dijera que no se puede poner cualquier cosa, nos hemos quedado a la espera. Ver http://www.clubdelphi.com/foros/show...&postcount=531

Si hay que pedir al usuario que pierda su tiempo escribiendo una descripción única para cada factura, pues se pone. Pero esto no va a ser agradable, ni para él ni para nosotros, que recibiremos alguna que otra queja.

Saludos,

[PASPAS]

Empezado por CMB

Si te refieres al tag DescripcionOperacion, pues sí, sería muy interesante saber lo que hay que poner ahí. Después de que aquella jefaza de Hacienda dijera que no se puede poner cualquier cosa, nos hemos quedado a la espera. Ver http://www.clubdelphi.com/foros/show...&postcount=531

Si hay que pedir al usuario que pierda su tiempo escribiendo una descripción única para cada factura, pues se pone. Pero esto no va a ser agradable, ni para él ni para nosotros, que recibiremos alguna que otra queja.

Saludos,

Pues lo pregunte eso a la aeat y me dijeron que no sera motivo de exclusion la no especificacion de la descripcion . En emitidas lo tengo solucionado pero no para el resto pongo algo generico.estaria bien que lo aclararasen insistire de nuevo a la aeat.
Lo que me tiene con muchas dudas es las peticiones de cobros y pagos porque no tengo forma de casar la respuesta cuando me devuelven el resultado. Si se envian pagos recc a la vuelta quiero marcarlos pero no veo la forma de hacerlo ya que es a nivel de factura y no de cada linea de pago enviado por tanto lo consultare tambien si alguien sabe como podria indicarlo porque no veo la forma.
Saludos. Creo q proximamente tendremos version 0.8

[nuevo1234]

Empezado por PASPAS

Pues lo pregunte eso a la aeat y me dijeron que no sera motivo de exclusion la no especificacion de la descripcion . En emitidas lo tengo solucionado pero no para el resto pongo algo generico.estaria bien que lo aclararasen insistire de nuevo a la aeat.
Lo que me tiene con muchas dudas es las peticiones de cobros y pagos porque no tengo forma de casar la respuesta cuando me devuelven el resultado. Si se envian pagos recc a la vuelta quiero marcarlos pero no veo la forma de hacerlo ya que es a nivel de factura y no de cada linea de pago enviado por tanto lo consultare tambien si alguien sabe como podria indicarlo porque no veo la forma.
Saludos. Creo q proximamente tendremos version 0.8

No existe un identificador del pago, es decir, aunque se devolviese a nivel de pago no hay manera de casarlo porque no existe un identificador único del pago como sí tenemos de factura. Creo que la solución podría ser guardar temporalmente un identificador de cada pago enviado a nivel de factura (si mi aplicación tiene un identificador de pago)y si me responden con ok a nivel de factura es que todos los pagos enviados asociado a esa factura son ok. En ese caso marco todos los pagos enviados por factura en mi aplicación (sé los que son porque me he guardado temporalmente su identificador por factura antes de enviarlos) porque o bien son todos pagos enviados ok o son todos ko para cada factura.

[CMB]

Empezado por PASPAS

Pues lo pregunte eso a la aeat y me dijeron que no sera motivo de exclusion la no especificacion de la descripcion

Tiene que ser un malentendido. En el manual se indica claramente que DescripcionOperacion es obligatorio.

Nos conviene aclararlo por las implicaciones que tiene. Es decir, si se puede poner una frase genérica o tiene que ser única en cada factura.

Saludos,

[PASPAS]

Empezado por nuevo1234

No existe un identificador del pago, es decir, aunque se devolviese a nivel de pago no hay manera de casarlo porque no existe un identificador único del pago como sí tenemos de factura. Creo que la solución podría ser guardar temporalmente un identificador de cada pago enviado a nivel de factura (si mi aplicación tiene un identificador de pago)y si me responden con ok a nivel de factura es que todos los pagos enviados asociado a esa factura son ok. En ese caso marco todos los pagos enviados por factura en mi aplicación (sé los que son porque me he guardado temporalmente su identificador por factura antes de enviarlos) porque o bien son todos pagos enviados ok o son todos ko para cada factura.

No vale tu solucion puesto que se pueden hacer envios parciales de los pagos y luego si uno de los pagos esta mal formado y el registro de pago anterior lo tienes ok que haces marcas todas mal aun teniendo el anterior registro bien. Esto para simultaneos pero para parciales aun podemos decir q los casos de error se multiplican. No veo logico el planteamiento realizado por la aeat.
Saludos

[manelb]

Hola buenos días…
Hace unos días que vengo siguiendo el foro y me ha servido de mucha ayuda….Gracias a todos y a partir de ahora espero aportar mi granito de arena.

Respecto al tema de la descripción en las facturas, tanto en compras como en ventas, supongo que va a depender de como tengamos cada uno diseñado nuestro sistema de contabilidad pero os explico como he pensado solucionarlo en nuestra aplicación.
Toda la información que se necesita para enviar los diferentes libros la tenemos concentrada en las tablas correspondientes a IVA.
En estas mismas tablas tenemos información sobra las diferentes contrapartidas en las que contabilizar cada una de las facturas, teniendo en cuenta que cada factura puede tener diferentes contrapartidas

70000000 Ventas de productos XXXXX
70000001 Ventas de productos YYYYYYY
70000002 Ventas de productos ZZZZZZZZZZZzz
70500000 Prestaciones de Servicios

Y lo mismo para compras con el 600

La idea sería poner directamente el nombre de las cuentas de las diferentes contrapartidas, o una tabla auxiliar que para cada contrapartida recupere la descripción que el usuario haya establecido.

Es una posibilidad….

[[newtron]]

Empezado por manelb

Hola buenos días…
Hace unos días que vengo siguiendo el foro y me ha servido de mucha ayuda….Gracias a todos y a partir de ahora espero aportar mi granito de arena.

Respecto al tema de la descripción en las facturas, tanto en compras como en ventas, supongo que va a depender de como tengamos cada uno diseñado nuestro sistema de contabilidad pero os explico como he pensado solucionarlo en nuestra aplicación.
Toda la información que se necesita para enviar los diferentes libros la tenemos concentrada en las tablas correspondientes a IVA.
En estas mismas tablas tenemos información sobra las diferentes contrapartidas en las que contabilizar cada una de las facturas, teniendo en cuenta que cada factura puede tener diferentes contrapartidas

70000000 Ventas de productos XXXXX
70000001 Ventas de productos YYYYYYY
70000002 Ventas de productos ZZZZZZZZZZZzz
70500000 Prestaciones de Servicios

Y lo mismo para compras con el 600

La idea sería poner directamente el nombre de las cuentas de las diferentes contrapartidas, o una tabla auxiliar que para cada contrapartida recupere la descripción que el usuario haya establecido.

Es una posibilidad….

Yo creo que eso sigue siendo una descripción bastante genérica. Según el asesor con el que he hablado la ley dice que la descripción de la factura debe de ser suficiente para, a partir de ahí, justificar el tipo de iva que va en la factura. O sea, que habría que expresar claramente los productos y/o servicios que se están vendiendo/comprando puesto que el iva de las naranjas no es el mismo que el de los coches (por ejemplo).

[Galahad]

Hola , buenos días.
Grácias a todos los que están aportando en este foro, me está sirviendo muchísimo.

Tengo entendido que cuando se hace la presentación, en la respuesta se devuelve un ID (número identificativo), que es una especie de número justificante de dicho envío.
La intención es la de guardar dicho ID en el envio general o en cada factura presentada, por si después es necesaria hacer alguna gestión con la AEAT.
¿ Alguién me puede decir como acceder/localizar dicho número ?, he estado repasando el .pas de SuministroFacEmitidas , pero no lo encuentro.
Un saludo..

[CMB]

Empezado por Galahad

Tengo entendido que cuando se hace la presentación, en la respuesta se devuelve un ID (número identificativo), que es una especie de número justificante de dicho envío.
La intención es la de guardar dicho ID en el envio general o en cada factura presentada, por si después es necesaria hacer alguna gestión con la AEAT. ¿ Alguién me puede decir como acceder/localizar dicho número ?, he estado repasando el .pas de SuministroFacEmitidas , pero no lo encuentro. Un saludo..

En la respuesta, para las facturas aceptadas o aceptadas con errores te suministra un CSV (código seguro de verificación). El CSV es el mismo para todas las facturas incluidas en el envío.

[vboloradito]

Empezado por newtron

Yo creo que eso sigue siendo una descripción bastante genérica. Según el asesor con el que he hablado la ley dice que la descripción de la factura debe de ser suficiente para, a partir de ahí, justificar el tipo de iva que va en la factura. O sea, que habría que expresar claramente los productos y/o servicios que se están vendiendo/comprando puesto que el iva de las naranjas no es el mismo que el de los coches (por ejemplo).

Nosotros no guardamos la descripción de las compras, facturas recibidas, vamos a poner compras y la descripción de la cuenta contable donde va asociada esa compra.
Pero la documentación actual solo dice que es obligatorio, no especifica el nivel de detalle. si piden mas lo dejamos para la version 2.

[vboloradito]

¿Que hay que informar en el campo CuotaDeducible de las facturas recibidas?