si nos fijamos en el ejemplo suministrador por la AEAT:
Código:
<sii:Exenta> si miramos, la línea señalada en negrita, eso NO es la base imponible. (o es la base Imponible de la factura rectificada?) (pero entonces que hace en negativo?) ¿alguna opinión? |
Hola de nuevo.
Hasta ahora solo había probado con facturas emitidas sin grandes problemas. Estoy intentando implementar en la misma unidad facturas recibidas y estoy teniendo problemas. ¿Hay que importar todos los ficheros wsdl de los distintos tipos de facturas? porque a mi se me hace un lío al hacer la llamada de factura emitida o recibida si los tengo en la misma unidad. Saludos |
Cita:
|
Cita:
|
Os recomiendo hacer formularios independientes.
Porque entonces se confunden los tipos de los distintos objetos. Y referenciar por "unit.tipo" es liarlo mas. saludos ! Código:
<sii:Exenta> He repasado el cuadernillo de la aeat y no dice nada al respecto. Eso si, el sistema traga con lo que le pongas. le da igual. Según he podido entender en una respuesta de la AEAT: En marzo parece que abrirán una web para comprobar. El formulario NO parece que sea para subir XMLs, será para teclear a mano la factura. Saludos ! |
Cita:
|
Cita:
Hola soykarloscc, Bueno, yo tambien ando en el tema, pero en VB.NET -muy similar a C# en estructura- por lo que me gustaria, si es posible intercambiar info contigo sobre el tema-. Mi mail es jslegido@gmail.com Un saludo |
Cita:
Yo todavía no he llegado a eso pero como te comentaba en otro post imagino que debe de haber algún campo en el que se informe del número de la factura que estás rectificando aparte del número de la factura rectificativa que tendrá el suyo propio. Saludos |
Respuesta a mensaje de prueba con HTML no con XML
Cita:
Yo también estoy generando los XML a mano a partir de las plantillas facilitadas por la AEAT, y para enviar el archivo XML uso node.js ... Estoy probando todavía ... He visto que si no registro el Certificado al hacer la llamada https, la TGSS me responde con un html apuntando a erro4033.html (No puedo adjuntar enlaces todavía), y cuando lo incluyo, me responde con un html indicando: Se ha producido un error Error del cliente. Se ha producido un error en la solicitud que impide al servidor procesarla. Puede contactar con el servicio de atención al contribuyente indicando el código de error 400. ¿ Teneís idea alguien de porqué contesta así en vez de con un XML tal cual se indica en el manual ? Gracias. |
Hola a todos.
Sin certificado valido no se puede enviar nada. El sistema de la aeat genera errores. Por otro lado no es lo mismo una factura rectificativa que una factura que se ha mandado mal. Para una factura rectificativa es otra factura nueva que se genera y rectifica a otra anterior y en ese caso si hay que mandar una rectifictiva e indicar la que estas rectificando, ya sea positiva o negativa. Una factura que se ha mandado mal, es decir hay un dato mal como puede ser el cliente, bases imponibles, etc hay que mandar la factura otra vez pero con clave A1 en el campo tipo de comunicación o A4 si es del regimen de viajeros. Eso es lo que yo creo. Un Saludo. |
Ahora deberíamos revisar:
http://www.agenciatributaria.es/AEAT...ormacion.shtml Si modificas una factura con A1 te devuelve un CSV diferente. Y dice modificaciones en "datos registrales" que no me queda muy claro que es.... eso si, la presentación con A0 y A1 es la misma. saludos ! |
Hola.
Yo entiendo que una modificación registral es que en la factura enviada hay cosas que se han informado mal (Cliente, bases imponibles, Datos Registrales, etcc), es decir la factura ya esta aceptada en el sistema y hay que volverla a enviar, o la factura ha sido aceptada con avisos que hay que corregir. PAra eso se utiliza la clave A1 o A2 en el tipo de comunicación. Logicamente te devuelve un CSV nuevo por que es un envío nuevo y cada envio devuelve un csv nuevo y tendras uno para el primer envío y otro para el segundo. Es mas en la información pone que se puede modificar una factura que se envío y luego se dio de baja. Una factura rectificativa es un nueva factura con su número nuevo y que rectifica una anterior. Es decir hay otro documento de factura por medio. Como bien dices todo esto esta explicado mas o menos en la información de la aeat. Que por cierto gracias a Trump :D ahora la tenemos en inglés. Un Saludo. |
Buenos días !
por intervenir hoy... técnicamente creo que ya los que trabajamos en Delphi no tenemos problemas para hacer los envíos. si os fijáis en uno de los cuadernillos de la AEAT (Presentacion_SII_es_es) se incluyen capturas de pantalla de la futura web de consulta de las facturas que tienen ya recibidas. Pero como me dijeron, no será accesible hasta marzo. Ahora bien: mi preocupación viene en componer adecuadamente el XML que se envía. Ahora mismo no tengo claro los modelos (emitidos y recibidos) de canarias, sociedades cuyo nif empieza por N, autofacturas... si alguien pudiera publicar algún ejemplo de dichos archivos creo que seria de gran utilidad para ir comparando los que vamos generando. No puedo publicar ninguno de estos porque no lo tengo claro. Saludos ! |
Cita:
3.11. A la hora de desglosar los datos de la factura, ¿debe indicarse si la operación es una entrega de bienes o una prestación de servicios? El desglose se hará obligatoriamente a nivel de operación cuando: El cliente sea extranjero (tipo “ID Otro” o NIF que empiece por N) y No sea una factura simplificada o un asiento resumen. Es decir hay que desglosar por "desglose Tipo Operacion". Si el cif empieza por o es extranjero y la operacion no es simplificada ni resumen. Te pongo un ejemplo de una factrura con una parte de prestación y otra parte de entrega. En cuanto a la autofacturas me imagino que es poner en los datos del declarado los mismos datos de la empresa que declara y el tipo de operación que corresponda. LAs ventas a canarias no dejan de ser unas ventas exentas. Por cierto has conseguido algo con lo de enviar mas de 13 facturas en hacienda no me contestan nada. Un Saludo |
Gracias Keys !
luego miro tus ejemplos aeat me ha respondido algunos correos, pero ese precisamente NO. (+13 facturas) aunque estoy enviando facturas 1 a 1. ¿porque? porque me funciona, obtengo un csv individual, y el envio / respuesta es mas claro y a nivel de programa es mas sencillo no equivocarte. Si no tengo contra-indicación seguire asi. Saludos ! mirado el ejemplo de N... según parece el tipo de NIF, no condiciona el tipo de trabajos que realizas: según pone prestación de servicios.... seguro que pasa... pero... porque además el error que devuelve dice mas o menos eso... también si lo colocas como "exento" pasa. de ahí mis dudas. les consulte a la aeat y tampoco han dicho nada hasta el momento, a ver que dice nuestro asesor fiscal... De canarias ni idea... en fin, esto ya no es programación, esto es otro tema ya. ¿no? |
Cita:
¿Cómo se obtiene el csv? Saludos |
Yo prefiero hacerlo de forma conjunta ya que creo que va a influir en la velocidad y además hemos optado por guardar el fichero de respuesta de la AEAT para que lo puedan consultar en cualquier momento ademas del CSV, y hacerlo de forma individual supondrá que el número de ficheros va a crecer mucho.
Si no me contestan nada de la aeat no quedará mas remedio que hacerlo de una en una, pero me da la impresión que va a ser un problema de nuestro delphi ya que me estraña que nadie haya presentado aún ficheros con más de 13 registros. Por cierto alguno a descubierto como hacer que el xml que se genera no tenga en todas las lineas el xmlns de cada tipo de campo. Lo digo para que el fichero de envío quede mas claro. Un Saludo. |
Hay que tener en cuenta que ahora mismo todo está en pruebas, así que no sería de extrañar que la limitación de 13 esté relacionada con este tema.
Como una forma de evitar saturaciones, ya que a efectos de realizar pruebas de formato y comunicaciones es suficiente. Que sea precisamente 13 incluso refuerza esa impresión. Como informático si tengo que elegir un número elijo 13 o 69 ;) |
Código:
resultado := GetsiiSOAP(true,'',emitidas).SuministroLRFacturasEmitidas(ASuministroLRFacturasEmitidas); Saludos ! |
Cita:
Las ventas a canarias en el 340 hay que declararlas como una operacion habitual exenta, me imagino que aqui será igual. Otra cosa es una venta de un canario a un canario que en ese caso si lleva el IGIC, pero yo no tengo esos casos. |
Cita:
Una factura rectificativa no necesariamente minora. Podría tener el mismo importe e incluso mayor. Las rectificativas substituyen a facturas normales que tienen alguna anomalía, sea el caso de un precio o cantidad erróneos, el NIF o domicilio fiscal incorrectos, el tipo de IVA impropio, etc. Se pueden (y creo que se deben) incluir también las devoluciones de género. Deben llevar una secuencia de numeración aparte. No parece normal que el importe total sea negativo, pues si has vendido 100 unidades y te devuelven 30, la rectificativa será por 70 unidades (positivas). Contablemente su importe se suma, al mismo tiempo que se resta el importe de la factura rectificada, para que todo cuadre. |
Cita:
Cita:
En tu ejemplo de que vendes 100 unidades y te devuelven 30 yo creo que la rectificativa tendría que ser de -30 unidades. De una forma o de otra le preguntaré a mi asesor porque ya me pones en duda. Saludos |
Cita:
|
Revisad la información de la Agencia Tributaria. Hay dos tipos de rectificativas, por sustitución y por diferencias. La segunda es la opción mas sencilla. La otra es un coñazo en cuanto a gestión de registros.
Mas información en: |
Cita:
Saludos. |
Hola a todos. Alguien ha conseguido enviar Cobros de facturas emitidas. No cosigo poner bien los datos de conexión estoy poniendo lo siguiente.
defWSDL = 'https://www2.agenciatributaria.gob.es/static_files/common/internet/dep/aplicaciones/es/aeat/ssii/fact/ws/SuministroCobrosEmitidas.wsdl'; defURL = 'https://www7.aeat.es/wlpl/SSII-FACT/ws/fe/SiiFactCOBV1SOAP'; defSvc = 'siiService'; defPrt = 'SuministroCobrosEmitidasPruebas'; Gracias. |
Hola A todos. Ya lo he solucionado, las direcciones están bien. El problema esta en que uso un objeto THTTPPRIO para generar los envíos, pues si lo utilizas con otro envio de otro tipo antes, da error. Es decir lo utilizo para enviar las facturas emitidas y si luego lo utilizo para enviar los cobros o pagos da un error.
Tengo que utilizar un objeto para cada unit que me genera el delphi con el wdsl importer. Un Saludo. |
Hola Otra Vez. Puede poner alguien un ejemplo de un fichero de suministro de cobros para facturas emitidas.
Me dice que el xml no es valido pero lo reviso y no lo veo. Gracias. |
Si usas las urls de los esquemas y Wizdler como complemento de Firefox te saca los ejemplos directamente.
Código:
<Envelope xmlns="http://schemas.xmlsoap.org/soap/envelope/"> |
Buenas a tod@os.
Bueno... yo realmente estoy con .Net haciendo esto mismo y recibo el error "El tipo de contenido text/html del mensaje de respuesta no coincide con el tipo de contenido del enlace (text/xml; charset=utf-8)". He visto que lo habéis relacionado con el certificado pero en principio mi certificado es correcto ya que conecto con la web de la AEAT desde el explorador seleccionando dicho certificado. La verdad ando un poco perdido ya que importo la referencia a WSDL para Facturas Emitidas y creo mi objeto con una factura emitida. Hasta ahi todo perfecto pero a la hora de pasarle a la función SuministroLRFacturasEmitidas del web service mi objeto esperando un objeto de tipo RespuestaLRFEmitidasType con la respuesta de mi envío por parte de la AEAT me encuentro con el error. Lo mas raro es que si no le asigno el certificado, el error es el mismo. A ver si alguien me da un poco de luz. Muchas gracias |
Cita:
|
Cita:
|
Y otra duda... ¿Lo que agrego es la direccion del WSDL verdad? Es que el Web Service esta en https://www7.aeat.es/wlpl/SSII-FACT/...iiFactFEV1SOAP. ¿O estoy totalmente equivocado?
|
Hola a todos. ¿Alguien ha podido enviar algun registro al suministro de cobros de facturas expedidas? Estoy intentando generar un fichero pero en la parte de cobro no me pone el xmlns y esto hace que a la hora de presentarlo de un error de 'Falta campo obligatorio COBRO' si le pongo el xmlns a mano yo en el fichero funciona.
Es decir hay que poner <Cobro xmlns="https://www2.agenciatributaria.gob.es/static_files/common/internet/dep/aplicaciones/es/aeat/ssii/fact/ws/SuministroInformacion.xsd"> Con <Cobro> solo que es lo que genera el delphi no vale. La forma de generarlo es la siguiente : SetLength(Cobros, 1); Cobros[0] := DatosPagoCobroType.Create; Cobros[0].Fecha := '01-01-2017'; Cobros[0].Importe := '12.12'; Cobros[0].Medio := MedioPagoType(0); Cobros[0].Cuenta_O_Medio := '1234'; ASuministroCobrosEmitidas[Nfactura].Cobros := Cobros; Por cierto la utilidad Wizdler es una bomba. Gracias. |
Cita:
En la parte de referencias tengo: url="https://www2.agenciatributaria.gob.es/static_files/common/internet/dep/aplicaciones/es/aeat/ssii/fact/ws/SuministroCobrosEmitidas.wsdl" filename="SuministroCobrosEmitidas.wsdl" /> El wdl apunta a la dirección correcta, verdad? Alguno lo ha conseguido? |
Cita:
defWSDL = 'https://www2.agenciatributaria.gob.es/static_files/common/internet/dep/aplicaciones/es/aeat/ssii/fact/ws/SuministroCobrosEmitidas.wsdl'; defURL = 'https://www7.aeat.es/wlpl/SSII-FACT/ws/fe/SiiFactCOBV1SOAP'; defSvc = 'siiService'; defPrt = 'SuministroCobrosEmitidasPruebas'; |
Cita:
|
Te está generando el xmls en la linea de cobro? Si es así puedes poner un ejemplo de como lo estás generando.
|
Cita:
siiSoap.SuministroLRCobrosEmitidas(variableCobroEmitida); Vamos, nada que no hagáis ya vosotros. |
NIF y razón social para pruebas
Ya que el webservice exige que los NIFs sean reconocidos por Hacienda, en los envíos de pruebas tenemos que poner datos reales, tanto el NIF como la razón social. Si te los inventas recibes una respuesta de rechazo.
¿Alguien sabe si existen parejas de NIF y razón social que sin ser reales pueden ser usados en pruebas y ser aceptados como buenos? Muchas gracias. Saludos |
La franja horaria es GMT +2. Ahora son las 00:33:53. |
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