FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Temas de Hoy |
|
Herramientas | Buscar en Tema | Desplegado |
|
#1
|
|||
|
|||
Si, pero recibo esto:
Código:
<env:Body><env:Fault><faultcode>env:Client</faultcode><faultstring>Codigo[4102].El XML no cumple el esquema. Falta informar campo obligatorio.: DetalleIVA</faultstring><detail><callstack>El XML no cumple el esquema. Falta informar campo obligatorio.: DetalleIVA WSExcepcion [faultcode=null, detailMap=null, version=0, faultstring=null, faultactor=null, faultSubCode=null, reasonText=null, detail=null, nameSpaceUriDetail=null] at es.aeat.ssii.fact.xml.util.UtilesXMLSII.existeEtiquetaFin(UtilesXMLSII.java:376) at es.aeat.ssii.fact.xml.comun.ParserXmlDesgloseIva.parsearLista(ParserXmlDesgloseIva.java:57) ... Otros ficheros si que me entran correctamente, con lo cual, debe ser algo especifico de algun registro de este pero que no puedo encontrar. |
#2
|
|||
|
|||
64.000 vistas
Este hilo llegará hoy a las 64.000 vistas. No está mal.
|
#3
|
|||
|
|||
Buenas tardes,
yo estoy un conector para la base de datos de contabilidad de mi empresa con el SII, pero lo estoy haciendo con C# / .NET. ¿Algún desarrollador por aquí de .NET? Me encuentro ahora deserializando una respuesta del WebService, ya con los XSD convertidos a una clase. Por ejemplo un RespuestaLRFRecibidasType. Pero me falla. Muchas gracias! |
#4
|
|||
|
|||
Cita:
Gracias. |
#5
|
|||
|
|||
Cita:
yo soy de C#, tambien me falla...al deserialize(fstream)....te ocurre a ti lo mismo? |
#6
|
|||
|
|||
Cita:
|
#7
|
|||
|
|||
[quote=inyu;518584]¿ Si estáis en .NET por qué no agregáis una referencia al servicio ? no hace falta ir deserializando ni nada, tratas directamente con las clases, métodos y propiedades que se generan automáticamente al agregar la referencia al wsdl. ->
porque al hacer resp = oSiiSFE.SuministroLRFacturasEmitidas(oSfe); me da 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). Si usa un codificador personalizado, asegúrese de que el método IsContentTypeSupported se implemente correctamente... ¿alguna idea de porque?...gracias |
#8
|
|||
|
|||
[quote=pilarinweb;518590]
Cita:
Código:
<binding name="siiBinding" maxReceivedMessageSize="1310720"> <security mode="Transport"> <transport clientCredentialType="Certificate" /> </security> </binding> |
#9
|
|||
|
|||
No me extraña, yo soy una de ellas (de hace un tiempo) y desde aquí el agradecimiento a que hayáis dedicado tanto tiempo a resolver dudas y poner blanco sobre negro temas que a muchos programadores se nos escapan.
Tengo el tema en fases finales de desarrollo (sobre todo gracias a este foro) y entre ellas, mejora de controles existentes. Unas dudas:
|
#10
|
|||
|
|||
Cita:
|
#11
|
|||
|
|||
La ventaja es para las empresas intermediarias, que aumentan su facturación a cambio de casi nada.
|
#12
|
|||
|
|||
Cita:
Eso sí, no son precisamente baratos. Lo que ocurre es que muchas veces (como es mi caso) ya trabajan con esas empresas para la recepción y envío de documentos. Lo cual no supone que les vayan a cobrar poco, pero el cliente manda... |
#13
|
|||
|
|||
Buenas, estamos aquí intentando hacer pruebas con el NIF NO CENSADO (novedad en la 0.7) pero no nos acepta el error
"Error en el bloque de la Contraparte. El NIF no está identificado." Lo hemos probado con un NIF que sabemos que no existe, pero que tiene la letra correcta 99999999R Vosotros lo habéis conseguido, ¿remitir con NIF no censado? si es así que Nif habéis utilizado, gracias! Nota: Por cierto creemos que ya esta en funcionamiento el web service de la 0.7 porque enviamos una razón social de mas de 40 caracteres (en la versión 0.6 eran 40 de máximo y en la 0.7 son 120) y lo acepto sin problemas. |
#14
|
|||
|
|||
Cita:
|
#15
|
|||
|
|||
Cita:
|
#16
|
||||
|
||||
Cita:
8.1.9. Alta Factura Rectificativa por sustitución “S” en el Libro de registro Facturas Expedidas http://www.agenciatributaria.es/stat...ioWeb_v0.7.pdf Cita:
8.1.1.4.Ejemplo mensaje XML de alta cuando la contraparte no está censada Para los casos en que se haya rechazado una factura emitida debido a que la contraparte (NIF y nombre) no está censada en la AEAT, podrá enviar dicha factura, en un segundo intento, suministrando el NIF en el bloque <IdOtro> con los siguientes contenidos: Código país: ES Clave ID: 07. No censado Número Id: NIF no censado del receptor de la factura Apellidos y nombre: Nombre del no censado receptor de la factura. En este caso, la factura figurará en el SII como aceptada con errores. En cualquier caso un error de formato en el NIF supondrá un rechazo de la factura. XML de entrada Código:
<?xml version="1.0" encoding="UTF-8"?> <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" 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"> <soapenv:Header/> <soapenv:Body> <siiLR:SuministroLRFacturasEmitidas> <sii:Cabecera> <sii:IDVersionSii>0.7</sii:IDVersionSii> <sii:Titular> <sii:NombreRazon>EMPRESAXXXXXXXXXXXXX</sii:NombreRazon> <sii:NIF>A84532501</sii:NIF> </sii:Titular> <sii:TipoComunicacion>A0</sii:TipoComunicacion> </sii:Cabecera> <siiLR:RegistroLRFacturasEmitidas> <sii:PeriodoImpositivo> <sii:Ejercicio>2017</sii:Ejercicio> <sii:Periodo>01</sii:Periodo> </sii:PeriodoImpositivo> <siiLR:IDFactura> <sii:IDEmisorFactura> <sii:NIF>A84532501</sii:NIF> </sii:IDEmisorFactura> <sii:NumSerieFacturaEmisor>01</sii:NumSerieFacturaEmisor> <sii:FechaExpedicionFacturaEmisor>15-01-2017</sii:FechaExpedicionFacturaEmisor> </siiLR:IDFactura> <siiLR:FacturaExpedida> <sii:TipoFactura>F1</sii:TipoFactura> <sii:ClaveRegimenEspecialOTrascendencia>01</sii:ClaveRegimenEspecialOTrascendencia> <sii:ImporteTotal>26.70</sii:ImporteTotal> <sii:DescripcionOperacion>VentaXXXXXXX</sii:DescripcionOperacion> <sii:Contraparte> <sii:NombreRazon>EMPRESAYYYYYYYY</sii:NombreRazon> <sii:IDOtro> <sii:CodigoPais>ES</sii:CodigoPais> <sii:IDType>07</sii:IDType> <sii:ID>94234500B</sii:ID> </sii:IDOtro> </sii:Contraparte> <sii:TipoDesglose> <sii:DesgloseFactura> <sii:Sujeta> <sii:NoExenta> <sii:TipoNoExenta>S1</sii:TipoNoExenta> <sii:DesgloseIVA> <sii:DetalleIVA> <sii:TipoImpositivo>21</sii:TipoImpositivo> <sii:BaseImponible>22.07</sii:BaseImponible> <sii:CuotaRepercutida>4.63</sii:CuotaRepercutida> </sii:DetalleIVA> </sii:DesgloseIVA> </sii:NoExenta> </sii:Sujeta> </sii:DesgloseFactura> </sii:TipoDesglose> </siiLR:FacturaExpedida> </siiLR:RegistroLRFacturasEmitidas> </siiLR:SuministroLRFacturasEmitidas> </soapenv:Body> </soapenv:Envelope> |
#17
|
|||
|
|||
Cita:
¿Tienes que recoger la respuesta de seres y trasladarla a tu sistema o te quedas solo en seres?. Si tienes que modificar un nif lo haces en SERES-edicom y luego a mano en tu sistema o lo haces en tu sistema y tienes qeu marcarla para que la vuelva a extraer para enviar a SERES-edicom. |
#18
|
|||
|
|||
Cita:
Efectivamente, hay que hacer todo el trabajo pero dejando a ellos SOLO el envío final. Si hay que modificar algo, se modifica en el sistema del cliente y se vuelve a enviar (se vuelve a generar el fichero y a decirle a edicom que lo envíe), lo mismo que el tratar las respuestas de edicom (que son las respuestas de la AEAT). Bueno, creo que existe un cliente mu chulo, pero yo ahí no entro, espero que sólo sirva para consultar datos. La cosa es superchunga. De primeras, al usar yo WSDL el mensaje que la AEAT me acepta sin problemas a ellos no les vale porque tiene el englobado SOAP (fácil de quitar) y no tiene los namespaces (sii:, siiLR: ..) que tendría si hubiera hecho el XML a mano basándome en el XSD. Vale, hago la transformación. Pero luego lo que han hecho (en mi caso) es un cliente java para poder comunicarme con su servicio, que no deja de ser un REST, podría haberme comunicado directamente, ¿no?. En fin, dejas el archivo generado en una carpeta y ejecutas un comando para que lo envíe. Y ya está. Puedo averiguar (algo intrincadamente) que el mensaje ha sido tratado por su servidor correctamente. Pero para saber si la AEAT ha dado el ok, tengo que ejecutar un comando para recibir mensajes de respuesta. Aún estoy esperándolo, para saber cómo voy a casar el mensaje que he enviado esta mañana con su respuesta. Una odisea. |
#19
|
|||
|
|||
Cómo puede ser que esté enviando una factura con la versión 0.6 del SII, que ayer me dejaba enviar, sólo he cambiado el número de serie para que no me tire error de duplicado, ahora me muestra el error:
Codigo[4121].Error en asincrono de cuadre Código (ITEADEST/ES.AEAT.SSII.FACT.API.FE.ASINC.CONSUEMITSRV/20170517) no existe En principio se podrían enviar facturas con la versión 0.6 hasta finales de mes, no? A alguien más le da este error? Sino recuerdo mal, la información de cuadre se ponía en la versión 0.7 pero no debería pedirla si hacemos envíos con la versión 0.6 |
#20
|
||||
|
||||
Cita:
No sera que reiniciaran los datos o algo?, yo voy a empezar las pruebas de la 0.7 ahora mismo y si sale te comento |
|
|
Temas Similares | ||||
Tema | Autor | Foro | Respuestas | Último mensaje |
TICKET BAI (TicketBAI); Nuevo sistema de la Agencia Tributaria del Pais Vasco | keys | Internet | 4170 | Hace 2 Semanas 17:29:05 |
AEAT envio de datos vía Webservice problemas con WSDL | CelsoO | Internet | 11 | 09-10-2019 20:03:41 |
webService Soap de la Administración Digital Española notific@ | apicito | Internet | 3 | 31-01-2017 11:25:28 |
Error en Webservice funcion envio de sms | webmasterplc | Delphi para la web | 5 | 25-07-2013 20:10:29 |
Problemas con envío de XML a un WebService | davidvamo | Internet | 1 | 13-02-2007 15:49:20 |
|