FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Temas de Hoy |
|
Herramientas | Buscar en Tema | Desplegado |
#2421
|
||||
|
||||
Cita:
Por otro lado no me has contestado a la pregunta que te he hecho anteriormente, ¿qué datos pondrías en ese supuesto?
__________________
Be water my friend. |
#2422
|
|||
|
|||
Cita:
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 |
#2423
|
||||
|
||||
Cita:
Punto 20 de nuestra guía de estilo: Cita:
__________________
La otra guía de estilo | Búsquedas avanzadas | Etiquetas para código | Colabora mediante Paypal |
#2424
|
|||
|
|||
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. |
#2425
|
||||
|
||||
Cita:
Cita:
¿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
__________________
Be water my friend. |
#2426
|
|||
|
|||
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. |
#2427
|
|||
|
|||
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. |
#2428
|
||||
|
||||
Cita:
Saludos
__________________
Be water my friend. |
#2429
|
||||
|
||||
Cita:
|
#2430
|
|||
|
|||
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.
|
#2431
|
||||
|
||||
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é....
__________________
Be water my friend. |
#2432
|
|||
|
|||
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.
|
#2433
|
|||
|
|||
Que ilusión, todavía queda alguien más que trabaja con tablas paradox....
|
#2434
|
|||
|
|||
¡Y yo, y yo!
|
#2435
|
|||
|
|||
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. |
#2436
|
|||
|
|||
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, |
#2437
|
|||
|
|||
Cita:
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..... |
#2438
|
|||
|
|||
Cita:
Muchas gracias por tu aportación. Saludos, |
#2439
|
|||
|
|||
Cita:
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, |
#2440
|
||||
|
||||
Dejo un dato curioso:
Correcto: Código:
<sii:BaseImponible>1000</sii:BaseImponible> <sii:PorcentCompensacionREAGYP>10.50</sii:PorcentCompensacionREAGYP> <sii:ImporteCompensacionREAGYP>100.5</sii:ImporteCompensacionREAGYP> Código:
<sii:PorcentCompensacionREAGYP>10.50</sii:PorcentCompensacionREAGYP> <sii:BaseImponible>1000</sii:BaseImponible> <sii:ImporteCompensacionREAGYP>100.5</sii:ImporteCompensacionREAGYP> |
|
|
Temas Similares | ||||
Tema | Autor | Foro | Respuestas | Último mensaje |
TICKET BAI (TicketBAI); Nuevo sistema de la Agencia Tributaria del Pais Vasco | keys | Internet | 4288 | Hace 1 Día 13:58:30 |
AEAT envio de datos vía Webservice problemas con WSDL | CelsoO | Internet | 11 | 09-10-2019 21:03:41 |
webService Soap de la Administración Digital Española notific@ | apicito | Internet | 3 | 31-01-2017 12:25:28 |
Error en Webservice funcion envio de sms | webmasterplc | Delphi para la web | 5 | 25-07-2013 21:10:29 |
Problemas con envío de XML a un WebService | davidvamo | Internet | 1 | 13-02-2007 16:49:20 |
|