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

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

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?

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...

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

DescripcionOperacion
 

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

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.

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,

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

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).

Resultado id
 

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..

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.

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.

CuotaDeducible facturas recibidas
 

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

Hay facturas recibidas que, por diferentes motivos, no puedes deducir-te la cuota completa de IVA.
Supongo que en este campo informas de, como su nombre indica, la cuota que puedes deducirte.
En la mayoría de los casos y de las actividades coincidirá con la cuota soportada.

Si vas a una gran superficie y compras un pen drive y 1 kg de tomates, pides factura y te lo incluyen todo, la cuota deducible sería sólo el material informático. Los tomates no son deducibles (en la mayor parte de los casos).

No sé dónde, pero en algún lugar debería haber una descripción del tag DescripcionOperacion. Porque te dan hasta 500 caracteres para rellenar. Con tal extensión se supone que esperan una descripción bastante extensa. Si fuese válido poner sólo COMPRAS VARIAS no te darían los 500.

Si alguien tiene más detalles sobre eso se agradecería que los diera, además de lo que ya sabemos por la jefaza: http://www.clubdelphi.com/foros/show...&postcount=531

Saludos,

Ahí yo discrepo. Otra cosa es que se metan más o menos pero la ley dice lo siguiente sobre los campos obligatorios de las facturas:

f) Descripción de las operaciones, consignándose todos los datos necesarios para la determinación de la base imponible del Impuesto y su importe, incluyendo el precio unitario sin Impuesto de dichas operaciones, así como cualquier descuento o rebaja que no esté incluido en dicho precio unitario.

Sacado de la web de hacienda: http://www.agenciatributaria.es/AEAT...facturas.shtml

Entiendo que eso se refiere a la factura en sí. La que se manda a los clientes o se recibe de los proveedores. Hay que incluir todos los conceptos con detalles de cantidad, precio, IVA, descuento, etc. Ya lo hace así todo el mundo.

Pero eso no tiene nada que ver con las altas en el SII y el campo DescripcionOperacion. Yo diría que se trata de otra cosa.

Saludos,

Cierto, pero en una reunión de los asesores con un técnico de hacienda para resolver dudas del SII, al preguntarle a este respecto remitió a esta ley. Ya no sé si será la cosa tan radical o no, eso es lo que tenemos que ver.

Si newtron, en parte estoy de acuerdo contigo, pero ten en cuenta que el enlace al que haces referencia habla del contenido de las facturas, y aquí estamos confeccionando un híbrido entre el Libro de IVA, el 340 y la factura.

Pero eso es un disparate. Si el usuario emite una factura con 50 o 60 líneas, que las hay, y más largas, y luego tiene que redactar aparte una descripción detallada de todo eso, las empresas van a tener que contratar a más personal.

Y luego con las recibidas, si van en papel. Si cada una lleva una descripción con 200 o 300 caracteres, hasta 500, y el administrativo lo tiene que ir copiando a mano para que luego se integren en la petición por SII...

No lo veo claro. Para eso que pidan un XML como el de la factura electrónica (la llamada Factura-e) que actualmente se manda a las administraciones públicas, donde se incluyen todos esos datos de forma automática. Eso sería lo ideal.

Saludos,

En eso estamos de acuerdo pero no creo yo que la aeat se turbe por eso. He mandado una consulta a ver qué me dicen.

Dudas sobre facturas expedidas
 

Me han surgido varias dudas en las facturas expedidas y como hacienda se lo traga todo sin quejarse os lo comento para ver como lo interpretáis vosotros:

1 Facturas expedidas de Intracomunitario de Servicios Ejemplo: dar soporte informático a una empresa de Francia
En este caso solo relleno los dos campos
FacturaExpedida.TipoDesglose.DesgloseTipoOperacion.PrestacionServicios.Sujeta.Exenta.BaseImponible = 100.00
FacturaExpedida.TipoDesglose.DesgloseTipoOperacion.PrestacionServicios.Sujeta.Exenta.CausaExencion = E5 Exenta por el artículo 25. Entregas de bienes destinados a otro Estado miembro

Dudo porque se hace raro que no haya ningún sitio donde indicar que lleva inv.suj.pas y que es exención por Intracomunitario de Servicios no por entrega de bienes

2 Facturas expedidas por recogida de material de reciclaje, exentas por INV. SUJ. PASIVO ART. 84.UNO.2.C DE LA LIVA
En este caso relleno los campos
FacturaExpedida.TipoDesglose.DesgloseFactura.Sujeta.Exenta.BaseImponible = 100
FacturaExpedida.TipoDesglose.DesgloseFactura.Sujeta.Exenta.CausaExencion = E6 Exenta por Otros

Esto casi seguro que lo tengo mal, pero no se como indicarlo de otra forma

3 Como se usa el TipoNoExenta
Estoy liado con el campo FacturaExpedida.TipoDesglose.DesgloseFactura.Sujeta.NoExenta.TipoNoExenta que puede ser "S1 Sujeta – No Exenta" o "S2 Sujeta – No Exenta - Inv. Suj. Pasivo"

Según yo creía (a pies juntillas hasta ahora) cuando en una factura de venta se aplica la inv.suj.pas NO lleva cuota de IVA, pero viendo los ejemplos de hacienda donde pone S2 y detalle base e IVA he dejado de creer. Cuando hay que utilizar S1 y cuando S2 ??


Si hay alguien que me pueda dar un poco de luz se lo agradecería

La misma palabra lo dice. La parte de la cuota de I.V.A que la empresa se puede deducir de esa factura.

Un Saludo.

rumores
 

corre el rumor de que la AEAT va a dar prorroga a las empresas que no esten listas para el dia 1 de Julio. Pero que no lo hara publico hasta que se acerque la fecha. Y que la empresa debería soliticarlo por escrito.

En el documento "PREGUNTAS FRECUENTES SII (versión 0.6)" ya pone que existe esta opción:

Lo qeu tu indicas es un redeme que factura menos de 6 millones al año, que si se quiere ahorrar el SII se sale del REDEME y ya no esta afectado.
El rumor es para todas las empresas, tambien para las que facturan mas de 6 millones al año

EStoy intentando mandar una baja de factura recibida y me da error (cogi el ejemplo de este foro).

LA he construido de manera similar a la baja de una emitida.

<faultstring>Codigo[4102].El XML no cumple el esquema. Falta informar campo obligatorio.: NombreRazon</faultstring>
<detail>
<callstack>El XML no cumple el esquema. Falta informar campo obligatorio.: NombreRazon

lo he comparado con el de baja de emitida y la información es la misma.
¿Teneis algun ejemplo completo que funcione?

Intentando averiguar qué vamos a hacer con el tema de la descripción de las facturas les envié una consulta a estos señores tan simpáticos de la aeat que es la siguiente:

la respuesta ha sido bastante ilustrativa:

como ya habréis visto la mayoría, en el apartado 2.15 de las FAQ pone que ese es un campo libre de 500 posiciones y punto.

Yo no sé si es que no tienen mucha idea o me están vacilando.

Saludos.

gLopez, Muchas gracias por tu sugerencia. Funcionando. Primera factura enviada. Gracias a todos. Un saludo

Pero eso no es una respuesta vinculante. Si lo tomas al pie de la letra puedes poner una descripción genérica igual para todas las facturas. Y no exime de que luego haya sanciones para quienes lo hagan. Y el marrón acabará en el programador por no escribir el código como es debido.

¿Para cuándo la versión 0.7?
 

¿Sabe alguien en qué fecha se aplicará la versión 0.7 ya anunciada?

Hola.

Échale un vistazo a este código a ver si te aclara algo:

Código Delphi [-]
    ASuministroLRFacturasRecibidas := BajaLRFacturasRecibidas.Create;
    ASuministroLRFacturasRecibidas.Cabecera := CabeceraSiiBaja.Create;
    // DATOS:
    ASuministroLRFacturasRecibidas.Cabecera.IDVersionSii:=VersionSiiType(0);       // 0.1
    ASuministroLRFacturasRecibidas.Cabecera.titular := PersonaFisicaJuridicaESType.Create;
    ASuministroLRFacturasRecibidas.Cabecera.Titular.NombreRazon:=Bd.BuscaValor('DATOSEMPRESA','NOMBRE','  ','');    // NOMBRE DEL PRESENTADOR
    ASuministroLRFacturasRecibidas.Cabecera.Titular.NIF:=Bd.BuscaValor('DATOSEMPRESA','MNIF','','');              // CIF del PRESENTADOR (DEBE COINCIDIR CON EL CERTIFICADO SELECCIONADO)

    //Se crean todas las estructuras de datos de la consulta
    SetLength(ARegistroLRFacturasRecibidas, M);

    for N := 0 to M do begin
      FormSII.PBProceso.Position := FormSII.PBProceso.Position+1;
      If Grid.ValorCeldaPorCampoYFila('ENVIAR',N+1)='X' then begin
        FormSII.Label5.Caption := 'Factura: '+Grid.ValorCeldaPorCampoYFila('FACTURA',N+1);
        Application.ProcessMessages;
        // Busco registro en tabla de iva
        Tabla.FindKey([Grid.ValorCeldaPorCampoYFila('CODIGO',N+1)]);
        // Busco registro en tabla de cuentas
        TablaCuentas.FindKey([Tabla.FieldByName('CUENTA').AsString]);
        ARegistroLRFacturasRecibidas[N]:=LRBajaRecibidasType.Create;
        ARegistroLRFacturasRecibidas[N].IDFactura:=IDFacturaRecibidaNombreBCType.create;
        ARegistroLRFacturasRecibidas[N].IDFactura.NumSerieFacturaEmisor:=Grid.ValorCeldaPorCampoYFila('FACTURA',N+1); // Numero de factura
        ARegistroLRFacturasRecibidas[N].PeriodoImpositivo:=PeriodoImpositivo.Create;
        ARegistroLRFacturasRecibidas[N].PeriodoImpositivo.Ejercicio:=Bd.BuscaValor('DATOSEMPRESA','MEJERCICIO','','');  //  AÑO
        ARegistroLRFacturasRecibidas[N].IDFactura.FechaExpedicionFacturaEmisor:=Grid.ValorCeldaPorCampoYFila('FECHA',N+1);                 // FECHA DE EXPEDICION FACTURA    (dd-mm-yyyy)
        ARegistroLRFacturasRecibidas[N].IDFactura.IDEmisorFactura:= IDEmisorFactura.Create;
        ARegistroLRFacturasRecibidas[N].IDFactura.IDEmisorFactura.NombreRazon := Tabla.FieldByName('NOMBRE').AsString;
        ARegistroLRFacturasRecibidas[N].IDFactura.IDEmisorFactura.NIF  := Tabla.FieldByName('CIF').AsString;

      end;
    end;
    //se añade el array de facturas creado anteriormente
    ASuministroLRFacturasRecibidas.RegistroLRBajaRecibidas :=ARegistroLRFacturasRecibidas;

Saludos