Foros Club Delphi

Foros Club Delphi (https://www.clubdelphi.com/foros/index.php)
-   Internet (https://www.clubdelphi.com/foros/forumdisplay.php?f=3)
-   -   SII -Nuevo sistema de la Agencia Tributaria española de envío de datos vía Webservice (https://www.clubdelphi.com/foros/showthread.php?t=91252)

encoder59 31-08-2017 11:47:05

Cita:

Empezado por Nasca (Mensaje 520708)
¿Dónde se puede consultar eso?

O te refieres a la información que muestra las diferencias cuando está "Parcialmente contrastada".

Cuando está "Parcialmente contrastada" no es problema ya que las claves coinciden.
Cuando está "No contrastada" es porque o la contraparte no la ha registrado o porque las claves no coinciden (que vendría a ser lo mismo).
El caso es que la FAQ que comentaba parece dar a entender que las consultas deberían devolver lo que pido.
Ya que en toda factura hay dos partes, emisor y receptor, mi rol en recibidas es en la contraparte de las emitidas por otros y viceversa (mis emitidas son sus recibidas y viceversa, en unas soy emisor y en otras contraparte)

Por tanto si consultara las recibidas debería poder ver aquellas en que la contraparte soy yo, tanto si la he subido yo como si la ha subido otro. Como queda registrado quien es el presentador sería sencillo ver si es de las que he recibido y registrado yo o si es de las que han registrado otros hacia mí y que todavía no he recibido para poder registrarlas.

Nasca 31-08-2017 11:53:32

He realizado comprobaciones para consultar lo presentado por otras partes y no lo he encontrado.
Parece que solo es posible consultar los registros de los que eres titular, que no emisor.

razorxxx 31-08-2017 12:30:13

Cita:

Empezado por razorxxx (Mensaje 520669)
Muy buenas!
Estoy tratando de generar desde Delphi un archivo XML de tipo Libro Cobros Emitidas. Utilizando el XML Data Binding generé la unit necesaria desde SuministroLR.xsd
El caso es que en una parte del código me lanza el error EIntfCastError: "interface not supported", pero no veo el fallo. Mi código es el siguiente (los datos fiscales son ficticios):

Código Delphi [-]
var
   Libro: SuministroLR.IXMLSuministroLRCobrosEmitidas;
   Cobro: SuministroLR.IXMLDatosPagoCobroType_sii;
   Document: IXMLDocument;
   FichEntrada: TextFile;
   NumSerieFacturaAnterior: String;
   Linea: WideString;
   I, J: Integer;
begin
     // Creamos documento XML en blanco, sólo con los namespaces necesarios
     try
        Document := TXMLDocument.Create(nil);
        Document.ParseOptions := [poResolveExternals, poValidateOnParse];
        Document.Options := Document.Options + [doNodeAutoIndent];
        Document.NodeIndentStr := '    ';
        Document.XML.Text := ' +
                             'xmlns:sii="https://www2.agenciatributaria.gob.es/static_files/common/internet/dep/aplicaciones/es/aeat/ssii/fact/ws/SuministroInformacion.xsd">';
        Document.Active := True;
     except
           SWERROR := 1;
           EXIT;
     end;
     try
        Libro := GetSuministroLRCobrosEmitidas(Document);
        Libro.AddChild('sii:Cabecera');
        Libro.Cabecera.IDVersionSii := VERSION_SII;
        Libro.Cabecera.AddChild('sii:Titular');
        Libro.Cabecera.Titular.NombreRazon := 'Prueba'
        Libro.Cabecera.Titular.NIF := 'A12345678';
        Libro.AddChild('siiLR:RegistroLRCobros');
        Libro.RegistroLRCobros[i].AddChild('siiLR:IDFactura');
        Libro.RegistroLRCobros[i].IDFactura.AddChild('sii:IDEmisorFactura');
        Libro.RegistroLRCobros[i].IDFactura.IDEmisorFactura.NIF := 'A12345678';
        Libro.RegistroLRCobros[i].IDFactura.NumSerieFacturaEmisor := '170001';
        Libro.RegistroLRCobros[i].IDFactura.FechaExpedicionFacturaEmisor := '20-08-2017';
        Libro.RegistroLRCobros[i].AddChild('siiLR:Cobros');
        Cobro := Libro.RegistroLRCobros[i].Cobros.Add;   // Aquí es donde me tira el error!

Si muestro el XML mediante ShowMessage(Libro.XML) me va mostrando el árbol correctamente:

Código:

<siiLR:SuministroLRCobrosEmitidas xmlns:siiLR="https://www2.agenciatributaria.gob.es/static_files/common/internet/dep/aplicaciones/es/aeat/ssii/fact/ws/SuministroLR.xsd" xmlns:sii="https://www2.agenciatributaria.gob.es/static_files/common/internet/dep/aplicaciones/es/aeat/ssii/fact/ws/SuministroInformacion.xsd">
    <sii:Cabecera>
        <sii:IDVersionSii>1.0</sii:IDVersionSii>
        <sii:Titular>
            <sii:NombreRazon>Prueba</sii:NombreRazon>
            <sii:NIF>A12345678</sii:NIF>
        </sii:Titular>
    </sii:Cabecera>
    <siiLR:RegistroLRCobros>
        <siiLR:IDFactura>
            <sii:IDEmisorFactura>
                <sii:NIF>A12345678</sii:NIF>
            </sii:IDEmisorFactura>
            <sii:NumSerieFacturaEmisor>170001</sii:NumSerieFacturaEmisor>
            <sii:FechaExpedicionFacturaEmisor>20-08-2017</sii:FechaExpedicionFacturaEmisor>
        </siiLR:IDFactura>
        <siiLR:Cobros/>
    </siiLR:RegistroLRCobros>
</siiLR:SuministroLRCobrosEmitidas>

¿A alguien se le ocurre dónde puede estar fallando? Gracias de antemano.

Me respondo a mi mismo. Al final he conseguido hacer un apaño tratando el nodo como IXMLNode y no como IXMLDatosPagoCobroType_sii. Entonces ya podemos trabajar con las funciones AddChild y ChildNodes. Por ejemplo:

Cobro := Libro.RegistroLRCobros[i].Cobros.AddChild('sii:Cobro');
Cobro.AddChild('sii:Fecha');
Cobro.ChildNodes['Fecha'].NodeValue := '20-08-2017';
Cobro.AddChild('sii:Importe');
Cobro.ChildNodes['Importe'].NodeValue := '1500.00';
Cobro.AddChild('sii:Medio');
Cobro.ChildNodes['Medio'].NodeValue := '01';

No sé si será porque el .xsd está mal definido o qué, pero al menos ya funciona!

razorxxx 31-08-2017 13:06:23

Obligatoriedad
 
Alguno dirá si me estoy haciendo las preguntas que he publicado recientemente a estas alturas de la película, pero soy de Canarias y ninguno de mis clientes emitía facturas con IVA hasta hace poco. Ahora me pregunto...realmente es obligatorio remitir los cobros de emitidas y los pagos de recibidas a la AEAT? O sólamente con enviar las facturas emitidas y recibidas es suficiente?

Nasca 31-08-2017 13:08:58

Cita:

Empezado por razorxxx (Mensaje 520722)
Alguno dirá si me estoy haciendo las preguntas que he publicado recientemente a estas alturas de la película, pero soy de Canarias y ninguno de mis clientes emitía facturas con IVA hasta hace poco. Ahora me pregunto...realmente es obligatorio remitir los cobros de emitidas y los pagos de recibidas a la AEAT? O sólamente con enviar las facturas emitidas y recibidas es suficiente?

Solo aquellos que estén en régimen especial de criterio de caja.

razorxxx 31-08-2017 13:33:17

Cita:

Empezado por Nasca (Mensaje 520723)
Solo aquellos que estén en régimen especial de criterio de caja.

Muchas gracias por tu pronta respuesta Nasca. Tengo entendido que ese régimen es de carácter optativo, verdad?

mrobles 31-08-2017 13:40:03

Cita:

Empezado por encoder59 (Mensaje 520714)
Tampoco aparece en la consulta web

http://www.clubdelphi.com/foros/show...postcount=2396

Nasca 31-08-2017 13:45:30

Cita:

Empezado por razorxxx (Mensaje 520724)
Muchas gracias por tu pronta respuesta Nasca. Tengo entendido que ese régimen es de carácter optativo, verdad?

Si. Es un puto engaño así que no creo que haya muchos en ese régimen.

Hay empresas que incluso por sistema se niegan a trabajar con empresas en dicho régimen. Les complica mucho su operatoria fiscal.

encoder59 31-08-2017 15:17:49

Cuando está "Parcialmente contrastada" no es problema ya que las claves coinciden y las discrepancias vienen en el contraste.

Cuando está "No contrastada" es porque o la contraparte no la ha registrado o porque las claves no coinciden (que vendría a ser lo mismo).
El caso es que la FAQ que comentaba parece dar a entender que las consultas deberían devolver lo que pido.
Ya que en toda factura hay dos partes, emisor y receptor, mi rol en recibidas es en la contraparte de las emitidas por otros y viceversa (mis emitidas son sus recibidas y viceversa, en unas soy emisor y en otras contraparte)

Por tanto si consultara las recibidas debería poder ver aquellas en que la contraparte soy yo, tanto si la he subido yo como si la ha subido otro. Como queda registrado quien es el presentador sería sencillo ver si es de las que he recibido y registrado yo o si es de las que han registrado otros hacia mí y que todavía no he recibido para poder registrarlas.

xamminf 01-09-2017 09:57:08

Período impositivo para Facturas Recibidas
 
Hola chicos,

He estado tratando de averiguar el funcionamiento del "periodo impositivo" para facturas recibidas. Pero no lo termino de tener claro. Me llama la atención que la aeat para explicarlo se limite a poner un ejemplo con conceptos "fecha límite" no explicados. ( http://www.agenciatributaria.es/AEAT...a__span_.shtml )

A lo que vamos. Lo que yo entiendo es que una fra. podrá ser declarada como período igual a la fecha de fra. siempre que la fecha contable no sea posterior al 15 del mes siguiente de la fecha de factura.

Ya digo que no lo tengo ni cerca de claro.

A ver si alguien puede arrojar luz

Saludos

PASPAS 01-09-2017 10:31:18

Cita:

Empezado por xamminf (Mensaje 520753)
Hola chicos,

He estado tratando de averiguar el funcionamiento del "periodo impositivo" para facturas recibidas. Pero no lo termino de tener claro. Me llama la atención que la aeat para explicarlo se limite a poner un ejemplo con conceptos "fecha límite" no explicados. ( http://www.agenciatributaria.es/AEAT...a__span_.shtml )

A lo que vamos. Lo que yo entiendo es que una fra. podrá ser declarada como período igual a la fecha de fra. siempre que la fecha contable no sea posterior al 15 del mes siguiente de la fecha de factura.

Ya digo que no lo tengo ni cerca de claro.

A ver si alguien puede arrojar luz

Saludos

Depende de las fechas y de cuando quieras deducirlas
Por ejemplo
Si recibes la factura el 4 de agosto pero con fecha factura prov 31 de julio
Aqui tienes 2 posibilidades debes permitir q tu programa pueda poner periodo de julio o de agosto
Por eso esta el ejemplo de la aeat muy bien explicado
Saludos

xamminf 01-09-2017 10:39:43

Cita:

Empezado por PASPAS (Mensaje 520754)
Depende de las fechas y de cuando quieras deducirlas
Por ejemplo
Si recibes la factura el 4 de agosto pero con fecha factura prov 31 de julio
Aqui tienes 2 posibilidades debes permitir q tu programa pueda poner periodo de julio o de agosto
Por eso esta el ejemplo de la aeat muy bien explicado
Saludos


Gracias por tu ayuda.

Ejemplo aeat: "El empresario B recibe la factura el 30 de septiembre y efectúa su registro contable el 10 de octubre."

¿ Por cual de las dos fechas puede imputarse a periodo impositivo 09, por el 30 de septiembre (recepcion) o por el 10 de octubre (contabilizacion) ?

Para nada creo que esté bien explicado. Los ejemplos se agradecen siempre, pero deben ir precedidos de la teoría, sino es difícil encontrar el por qué.

newtron 01-09-2017 10:50:18

Cita:

Empezado por xamminf (Mensaje 520755)
Gracias por tu ayuda.

Ejemplo aeat: "El empresario B recibe la factura el 30 de septiembre y efectúa su registro contable el 10 de octubre."

¿ Por cual de las dos fechas puede imputarse a periodo impositivo 09, por el 30 de septiembre (recepcion) o por el 10 de octubre (contabilizacion) ?

Para nada creo que esté bien explicado. Los ejemplos se agradecen siempre, pero deben ir precedidos de la teoría, sino es difícil encontrar el por qué.

El periodo impositivo es el mes correspondiente a la fecha de contabilización de la factura (compras/gastos) o de emisión (ventas).

Saludos

xamminf 01-09-2017 11:23:37

Cita:

Empezado por newtron (Mensaje 520756)
El periodo impositivo es el mes correspondiente a la fecha de contabilización de la factura (compras/gastos) o de emisión (ventas).

Saludos

Estimado Jimmy,

Eso, a la luz del ejemplo aeat, no es cierto.

Saludos y gracias por tu (intento de) ayuda

newtron 01-09-2017 11:30:56

Cita:

Empezado por xamminf (Mensaje 520757)
Estimado Jimmy,

Eso, a la luz del ejemplo aeat, no es cierto.

Saludos y gracias por tu (intento de) ayuda

¿Hablas con Jimmy o conmigo?

xamminf 01-09-2017 11:33:55

Para todos intento centrar la jugada, que parece no ha sido tenida en cuenta, probablemente por ignorancia de los usuarios, probablemente porque tenían un sistema de trabajo que coincidía con los resultados de fecha de contabilización:

La aeat permite "devengar" una factura recibida en el mismo mes en que se recibe, aunque se contabilice más tarde.
Es verdad que se puede "devengar" en el período que se contabiliza, pero habrá usuarios, naturalmente, que prefieran deducirse antes la compra y no esperar al mes siguiente.

xamminf 01-09-2017 11:34:33

Cita:

Empezado por newtron (Mensaje 520758)
¿Hablas con Jimmy o conmigo?

Disculpa, te llamé Jimmy, por Jimmy "Newtron".

newtron 01-09-2017 11:39:35

Cita:

Empezado por xamminf (Mensaje 520760)
Disculpa, te llamé Jimmy, por Jimmy "Newtron".

No me llamo Jimmy, mi nick es newtron.

Cita:

Empezado por xamminf (Mensaje 520759)
Para todos intento centrar la jugada, que parece no ha sido tenida en cuenta, probablemente por ignorancia de los usuarios, probablemente porque tenían un sistema de trabajo que coincidía con los resultados de fecha de contabilización:

La aeat permite "devengar" una factura recibida en el mismo mes en que se recibe, aunque se contabilice más tarde.
Es verdad que se puede "devengar" en el período que se contabiliza, pero habrá usuarios, naturalmente, que prefieran deducirse antes la compra y no esperar al mes siguiente.

¿Quien "devenga" una factura recibida sin contabilizarla?, yo no conozco a nadie. Por otro lado, según lo que dices, si quiero contabilizar y devengar una factura de compras de Enero de 2016 ¿qué tengo que poner? ¿Periodo=Enero y Ejercicio 2016?

newtron 01-09-2017 12:03:10

Cita:

Empezado por xamminf (Mensaje 520757)
Estimado Jimmy,

Eso, a la luz del ejemplo aeat, no es cierto.

Saludos y gracias por tu (intento de) ayuda

Por otro lado no me gusta ese tono con el que me respondes.

Yo no soy infalible, me puedo equivocar como cualquiera, pero aun en el caso de que yo estuviera equivocado no creo que esta sea una respuesta adecuada a un intento de echarte una mano de forma totalmente desinteresada.

Hay veces que he visto respuesta erróneas y siempre digo que discrepo, no tengo claro que sea así, o mil formas de decir las cosas y realmente ese tono condescendiente no creo que sea el oportuno.

xamminf 01-09-2017 12:14:24

Cita:

Empezado por newtron (Mensaje 520762)
Por otro lado no me gusta ese tono con el que me respondes.

Yo no soy infalible, me puedo equivocar como cualquiera, pero aun en el caso de que yo estuviera equivocado no creo que esta sea una respuesta adecuada a un intento de echarte una mano de forma totalmente desinteresada.

Hay veces que he visto respuesta erróneas y siempre digo que discrepo, no tengo claro que sea así, o mil formas de decir las cosas y realmente ese tono condescendiente no creo que sea el oportuno.

Disculpa si te he molestado.
Llevaré mucho cuidado de que no vuelva a ocurrir.

newtron 01-09-2017 12:31:36

Cita:

Empezado por xamminf (Mensaje 520763)
Disculpa si te he molestado.
Llevaré mucho cuidado de que no vuelva a ocurrir.

No hay problema.

Por otro lado no me has contestado a la pregunta que te he hecho anteriormente, ¿qué datos pondrías en ese supuesto?

xamminf 01-09-2017 12:42:20

Cita:

¿Quien "devenga" una factura recibida sin contabilizarla?, yo no conozco a nadie. Por otro lado, según lo que dices, si quiero contabilizar y devengar una factura de compras de Enero de 2016 ¿qué tengo que poner? ¿Periodo=Enero y Ejercicio 2016?
Esa pregunta no la entiendo bien.

Pongo un ejemplo para explicarme:

Fecha factura = 29/9
Fecha recepción = 30/9
Fecha contabilización = 1/10

Aquí el usuario podrá poner como período 09 ó 10. Si la fra. es de 300.000 € tendrá mucho interés en poner 09

Casimiro Notevi 01-09-2017 12:47:27

Cita:

Empezado por xamminf (Mensaje 520763)
Estimado Jimmy,
Eso, a la luz del ejemplo aeat, no es cierto.
Saludos y gracias por tu (intento de) ayuda .

No es lógico contestar de esa forma a quien está intentando ayudarte, ¿no te parece?
Punto 20 de nuestra guía de estilo:
Cita:

Eliminar de base cualquier tipo de controversia personal en público y nunca responder a provocaciones personales, la cortesía, el respecto y el buen trato son fundamentales para una interacción armónica entre los foristas, no se tolerará ninguna transgresión a este respecto.

Nasca 01-09-2017 12:49:57

Yo planteo esto en términos de varias fechas.

En facturas recibidas
Por ejemplo, factura con fecha 25/07/2017, recibida el 10/08/2017: FechaExpedicion = 25/07/2017 - FechaFiscal = 25/07/2017 o 31/07/2017 - FechaEntrada = 10/08/2017
Misma factura recibida el 16/08/2017: FechaExpedicion = 25/07/2017 - FechaFiscal = 01/08/2017 o 16/08/2017 - FechaEntrada = 16/08/2017

En facturas emitidas
La fecha fiscal no necesariamente es la FechaExpedicion, hay que considerar la fecha de devengo del impuesto, que tiene más relación con la fecha de operación que con la fecha de expedición/emisión de la factura.

newtron 01-09-2017 12:55:11

Cita:

Empezado por Casimiro Notevi (Mensaje 520767)
No es lógico contestar de esa forma a quien está intentando ayudarte, ¿no te parece?
Punto 20 de nuestra guía de estilo:

No pasa nada Antonio, tema zanjado, gracias.

Cita:

Empezado por xamminf (Mensaje 520766)
Esa pregunta no la entiendo bien.

Pongo un ejemplo para explicarme:

Fecha factura = 29/9
Fecha recepción = 30/9
Fecha contabilización = 1/10

Aquí el usuario podrá poner como período 09 ó 10. Si la fra. es de 300.000 € tendrá mucho interés en poner 09

Vale, puede elegir entre fecha de recepción y de contabilización pero yo entiendo que es un sinsentido manejar esas dos fechas y lo prudente para evitar confusiones es que la fecha de recepción y contabilización sea la misma. Si como bien dices la factura es de 300.000€ la fecha de contabilización puede ser 30/9.

¿Que se pueden manejar las dos fechas? pues imagino que si pero yo no le veo la utilidad.

Dicho todo esto yo entiendo que la respuesta que te di en su momento es totalmente correcta.

Saludos

APO 05-09-2017 11:59:20

Hola,
Tengo un problemilla, una vez recibo la respuesta del envío en bloque de facturas de compra, debo localizar en la base de datos del programa de gestión factura a factura para actualizar el estado.
Encuentro que en la respuesta solo dispongo de los siguientes campos para localizar la factura:

RespuestaEnvio.RespuestaLinea[i].IDFactura.IDEmisorFactura
RespuestaEnvio.RespuestaLinea[i].IDFactura.NumSerieFacturaEmisor
RespuestaEnvio.RespuestaLinea[i].IDFactura.FechaExpedicionFacturaEmisor

La combinación de estos 3 campos no es la cable primaria, aunque normalmente sería suficiente para localizar inequívocamente la factura.
¿Estáis localizando la factura con estos 3 campos o se me está pasando algo por alto?

Gracias.

Nasca 05-09-2017 12:12:20

Efectivamente solo cuentas con eso.

En emitidas se puede obviar la identidad del emisor, pero en recibidas lo tendrás que usar necesariamente.

Lo ideal sería que se pudiese remitir la clave primaria asignada en recibidas, pero no es devuelta en la respuesta. Cosa diferente si consultas las facturas al margen del envío. En este caso podrías enviar la clave primaria de tu base de datos en la descripción de la factura. Aunque en ese caso no tendrás localizada la respuesta de las incorrectas.

newtron 05-09-2017 12:43:30

Cita:

Empezado por APO (Mensaje 520834)
Hola,
Tengo un problemilla, una vez recibo la respuesta del envío en bloque de facturas de compra, debo localizar en la base de datos del programa de gestión factura a factura para actualizar el estado.
Encuentro que en la respuesta solo dispongo de los siguientes campos para localizar la factura:

RespuestaEnvio.RespuestaLinea[i].IDFactura.IDEmisorFactura
RespuestaEnvio.RespuestaLinea[i].IDFactura.NumSerieFacturaEmisor
RespuestaEnvio.RespuestaLinea[i].IDFactura.FechaExpedicionFacturaEmisor

La combinación de estos 3 campos no es la cable primaria, aunque normalmente sería suficiente para localizar inequívocamente la factura.
¿Estáis localizando la factura con estos 3 campos o se me está pasando algo por alto?

Gracias.

Yo tengo un campo autonumérico en cada una de las tablas. Al preparar los datos para hacer la llamada vas guardando ese código en el orden en que los vas enviando, posteriormente la respuesta te las va devolviendo en el mismo orden con lo que sólo tienes que ir buscando por ese código e ir actualizando el estado según la respuesta recibida.

Saludos

mrobles 05-09-2017 12:58:24

Cita:

Empezado por newtron (Mensaje 520836)
Yo tengo un campo autonumérico en cada una de las tablas. Al preparar los datos para hacer la llamada vas guardando ese código en el orden en que los vas enviando, posteriormente la respuesta te las va devolviendo en el mismo orden con lo que sólo tienes que ir buscando por ese código e ir actualizando el estado según la respuesta recibida.

Saludos

Si mal no recuerdo, no te las devuelve siempre en el orden en el que las enviaste, cuidado con eso

CMB 05-09-2017 13:06:44

Cita:

Empezado por mrobles (Mensaje 520838)
Si mal no recuerdo, no te las devuelve siempre en el orden en el que las enviaste, cuidado con eso

Y aunque así fuese, no te puedes fiar, pues eso no es ningún compromiso y lo pueden cambiar cuando a ellos les convenga. Yo hago una búsqueda de la factura con los 2 o 3 (depende) campos clave, y cuando la encuentra le escribo el CSV y demás datos de interés.

newtron 05-09-2017 13:46:46

Cita:

Empezado por CMB (Mensaje 520840)
Y aunque así fuese, no te puedes fiar, pues eso no es ningún compromiso y lo pueden cambiar cuando a ellos les convenga. Yo hago una búsqueda de la factura con los 2 o 3 (depende) campos clave, y cuando la encuentra le escribo el CSV y demás datos de interés.

Pufffffffffffffffffffff.... pues la verdad es que no me "mola" demasiado andar buscando por los campos clave, veo bastante más seguro buscar por una clave única. Hasta ahora no he tenido problemas de que se me trastoque el orden de la respuesta pero no sé....

CMB 05-09-2017 14:39:46

Cita:

Empezado por newtron (Mensaje 520842)
Pufffffffffffffffffffff.... pues la verdad es que no me "mola" demasiado andar buscando por los campos clave, veo bastante más seguro buscar por una clave única. Hasta ahora no he tenido problemas de que se me trastoque el orden de la respuesta pero no sé....

Depende del tipo de tablas con el que trabajes se trata de una sola línea, buscar por dos campos o por tres, que en realidad basta con uno y dos (emitidas y recibidas respectivamente), tanto si lo haces con SQL como con tablas Paradox, aunque hay más variaciones.

manelb 05-09-2017 16:33:23

Cita:

Empezado por CMB (Mensaje 520844)
tanto si lo haces con SQL como con tablas Paradox, .

Que ilusión, todavía queda alguien más que trabaja con tablas paradox....

Javierus 08-09-2017 13:41:08

Cita:

Empezado por manelb (Mensaje 520848)
Que ilusión, todavía queda alguien más que trabaja con tablas paradox....

¡Y yo, y yo!

CMB 08-09-2017 14:06:04

Cita:

Empezado por Javierus (Mensaje 520923)
¡Y yo, y yo!

Muchos más de lo que parece usan Paradox todavía.

Y Delphi 7, el obsoleto y desfasado Delphi 7, mantiene aún la fidelidad de miles de programadores en todo el mundo. Porque permite hacerlo casi todo, y para lo que no se puede hacer con él, existen multitud de third parties y libraries que te lo resuelven.

CMB 09-09-2017 13:25:19

Operaciones entre el TAI y Canarias, Ceuta y Melilla
 
De acuerdo con la FAQ 2.22, las ventas desde el TAI (Península y Baleares) a Canarias, Ceuta y Melilla se consideran exportación cuando se trata de entrega de bienes, y hay que dar el valor 02 al campo ClaveRegimenEspecialOTrascendencia. Pero cuando se trata de prestación de servicios, ya no es una exportación, y hay que dar el valor 08 a ClaveRegimenEspecialOTrascendencia, y el tipo de factura, cuando se registra como recibida, es F5 (Importaciones (DUA)).

Ahora bien, si en una misma factura se mezclan prestación de servicios y entrega de bienes, parece que debemos usar el campo ClaveRegimenEspecialOTrascendenciaAdicional1 (y ClaveRegimenEspecialOTrascendenciaAdicional2).

Entonces, ¿existe obligación de indicar por separado el importe que corresponde a los servicios y a los bienes? Y en caso afirmativo, ¿en qué posición dentro de la petición?

¿Tiene alguien un ejemplo sencillo?

Muchas gracias por adelantado.

Saludos,

nuevo1234 11-09-2017 13:29:22

Cita:

Empezado por CMB (Mensaje 520954)
De acuerdo con la FAQ 2.22, las ventas desde el TAI (Península y Baleares) a Canarias, Ceuta y Melilla se consideran exportación cuando se trata de entrega de bienes, y hay que dar el valor 02 al campo ClaveRegimenEspecialOTrascendencia. Pero cuando se trata de prestación de servicios, ya no es una exportación, y hay que dar el valor 08 a ClaveRegimenEspecialOTrascendencia, y el tipo de factura, cuando se registra como recibida, es F5 (Importaciones (DUA)).

Ahora bien, si en una misma factura se mezclan prestación de servicios y entrega de bienes, parece que debemos usar el campo ClaveRegimenEspecialOTrascendenciaAdicional1 (y ClaveRegimenEspecialOTrascendenciaAdicional2).

Entonces, ¿existe obligación de indicar por separado el importe que corresponde a los servicios y a los bienes? Y en caso afirmativo, ¿en qué posición dentro de la petición?

¿Tiene alguien un ejemplo sencillo?

Muchas gracias por adelantado.

Saludos,

Hola,

En la FAQ 3.20. ¿Cómo se registra una factura que comprende operaciones con distinta clave de régimen especial?

Dice al final de la respuesta: "Esta combinación no implicará un desglose de los importes por cada una de las claves pero sí implicará considerar los distintos campos adicionales que deben informarse teniendo en cuenta cada una de ellas"

No sé si esto te ayuda.....

CMB 11-09-2017 13:54:53

Cita:

Empezado por nuevo1234 (Mensaje 520983)
Hola,
En la FAQ 3.20. ¿Cómo se registra una factura que comprende operaciones con distinta clave de régimen especial?
Dice al final de la respuesta: "Esta combinación no implicará un desglose de los importes por cada una de las claves pero sí implicará considerar los distintos campos adicionales que deben informarse teniendo en cuenta cada una de ellas"
No sé si esto te ayuda.....

Pues sí que puede ser de ayuda. Aunque la redacción de la FAQ no está muy clara, haré un esfuerzo para interpretarla sin equivocarme.

Muchas gracias por tu aportación.

Saludos,

CMB 11-09-2017 14:05:27

Cita:

Empezado por nuevo1234 (Mensaje 520983)
Hola,
En la FAQ 3.20. ¿Cómo se registra una factura que comprende operaciones con distinta clave de régimen especial?

Añadido después de mirarme la FAQ con más detenimiento:

Para incluir más de un tag ClaveRegimenEspecialOTrascendencia establecen unas compatilidades que no son aplicables al caso de las Canarias con prestación de servicios y entrega de bienes en una misma factura.

Si se trata de prestación de servicios, la clave es 08 (Operaciones sujetas al IPSI / IGIC), y con entrega de bienes la clave es 02 (Exportación).

Después de leer la FAQ 3.20 me da la sensación de que esas dos claves no son compatibles, por lo que el problema no se puede solucionar por esa vía.

Si alguien tiene una solución le agradecería su ayuda.

Saludos,

mrobles 11-09-2017 17:02:49

Dejo un dato curioso:

Correcto:
Código:

<sii:BaseImponible>1000</sii:BaseImponible>
<sii:PorcentCompensacionREAGYP>10.50</sii:PorcentCompensacionREAGYP>
<sii:ImporteCompensacionREAGYP>100.5</sii:ImporteCompensacionREAGYP>

Incorrecto:
Código:

<sii:PorcentCompensacionREAGYP>10.50</sii:PorcentCompensacionREAGYP>
<sii:BaseImponible>1000</sii:BaseImponible>
<sii:ImporteCompensacionREAGYP>100.5</sii:ImporteCompensacionREAGYP>



La franja horaria es GMT +2. Ahora son las 22:15:14.

Powered by vBulletin® Version 3.6.8
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Traducción al castellano por el equipo de moderadores del Club Delphi