Cita:
Código:
var |
ya lo conseguí.
Código:
<AltaFactuSistemaFacturacion xmlns:soapenv="......./envelope/" ahora voy a rellenar los demás campos. Cita:
|
Cita:
Desde el punto de vista de remisión de información, existirán dos servicios web, uno para el alta y remisión inmediata, detallado en el Diseño de registro DR Alta.Verifactu, y otro para la remisión por requerimiento, detallado en el Diseño de registro DR Alta.Requerimiento (que son las "hojas" del DR sobre las que no tienen dudas). Adicionalmente, y como elementos propios del SIF, existirá el Registro de Eventos, obligatoriamente en los sistemas no Veri*factu. Este Registro de Eventos es necesario para para que se consideren cumplidas las condiciones establecidas en el artículo 8.3 del Reglamento aprobado por el Real Decreto 1007/2023. Lo que se describe en el DR Evento.v.0.3 es la información estructurada que debe contener. Un ejemplo de acciones a registrar en el DR de Eventos puede ser: Instalación o puesta en marcha inicial del sistema informático, Detección de anomalías en la integridad, inalterabilidad y trazabilidad de registros de eventos, Exportación de registros de facturación generados en un periodo, entre otros. Este registro de Eventos, por el momento, se menciona en el artículo 8.3 de Disposición 24840 del BOE núm. 291 de 2023 Por último, también existirá como elemento propio del SIF, un DR Alta.C-E, que se denomina, Diseño de Registro de Alta Conservación y Exportación, o también su análogo para la anulación, que indica cómo se debe conservar los datos en el SIF y también, en su caso, cómo se debe exportar. Ambos son la base u origen de la información de los registros de facturación y comparten un contenido muy similar con los que se utilizarán para la remisión, ya sea inmediata o por requerimiento, pero su ámbito es el propio SIF. Esperamos haberle aclarado su duda, no obstante, cuando se publique la OM se ofrecerá información más detallada sobre estas cuestiones (y muchas otras). |
Cita:
|
Cita:
No molesta en absoluto. Aunque este es un foro principalmente sobre Delphi, caben mensajes de otros lenguajes, Y aunque hay foros específicos de cada lenguaje, en temas como este, LeyAntifraude (SII o TicketBAI) se permite publicar en textos y códigos en otros lenguajes de programación, porque "prima" el tema sobre el que va el hilo (LeyAntifraude). |
Cita:
|
Cita:
Estoy comparando y lo que tú me mandas tiene mucho más contenido que el que me ha generado a mi importándolo desde Delphi. No solo no encuentro la cabecera que en el tuyo si: Código:
'''<remarks/> Código:
'''<remarks/> ¿Podrías mandar el link del wsdl que estás importando a ver si es que no estoy cogiendo el correcto? ¿Es normal que el mismo wsdl al importarlo desde dos lenguajes diferentes se "coma" cosas? Un poco más abajo están las siguientes definiciones: Código:
'''<remarks/> |
Cita:
Hola estoy un poco espeso, he leido esta respuesta y me he quedado con la misma duda que tenua, a raiz de esta respuesta de la aeat, sabeis si realmente los sistemas SÍ VERIFACTU (O sea que envian directamente) tienen que crear algún evento. el de instalación inicio de envio...? no entiendo muy bien el mensaje |
Cita:
|
Cita:
|
Más sobre el QR
Al parecer en el pdf, según la OM propuesta), habrá que ponerle el enlace (Escribiendolo completo e integrandole el enlace) debajo o encima del dibujo del QR.
|
ejemplo posible QR
1 Archivos Adjunto(s)
Os adjunto un pdf con aproximación de como quedaría una factura con QR en pdf según los datos que nos dan en la OM.
Las medidas son 35x35 ya que como piden entree 30x30 y 40x40 me quedo justo en el centro para tener margen por si hay alguna putadilla con las medidas de la impresora. |
Cita:
No entiendo nada. ¿Será por culpa de la ñapa esa que hacemos para que no de el error de las cadenas más largas de 255 caracteres? |
Cita:
No creo que sea por eso. Ese error es de Delphi una vez importado, simplemente por cómo se ha formado el fichero (que está bien formado). Salvo que delphi no acepta esas cadenas largas. |
Cita:
|
Cita:
Acabo de volver a hacer las siguientes pruebas de importación del wsdl:
Con las dos primeras opciones aparentemente me genera lo mismo, mientras que sin lo importo con la última opción, entonces si que me genera un wsdl con la famosa CABECERA, VersionType, etc. ¿Puede ser posible que sólo por eso ya cambie tanto la importación del fichero WSDL?. Ahora la llamada al SOAP la tengo que hacer así para que me compile: Código:
var |
1 Archivos Adjunto(s)
A mi los tres ficheros generados con esas opciones me resultan similares.
Completando el código que has puesto, la llamada podría ser similar a esta:
En este caso genera un fichero como este: Código:
<?xml version="1.0"?> Adjunto los 3 ficheros generados al importar el WSDL y el propio fichero WSDL. |
Cita:
Gracias Germán por el ejemplo. El problema es que ese código a mi no me compila en mi Delphi Berlín, se ve que este tipo de instrucciones no le gustan:
¿Hay alguna forma de modificar eso para que compile en Delphi Berlín? Gracias de nuevo y un saludo. |
Cita:
Código:
var |
Cita:
Aquí vuelve el pesado de turno da dar la brasa. Disculpas por anticipado si estoy diciendo tonterías, pero entiendo que cambios si que ha habido. En su momento posteaste los ficheros generados tras importar la wsdl: https://www.clubdelphi.com/foros/sho...&postcount=971 y si los comparas con los que posteas ahora podrás ver que no son iguales. Los "antiguos" tienen 1713 líneas y los "nuevos" tienen 2112 líneas. Así que algo si que ha cambiado entre ambas importaciones, A mi me genera la importación de 1713 líneas si lo hago en automático o 1.1 y la de 2112 si la hago en modo 1.2. |
La franja horaria es GMT +2. Ahora son las 10:49:11. |
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