Club Delphi  
    FTP   CCD     Buscar   Trucos   Trabajo   Foros

Retroceder   Foros Club Delphi > Principal > Internet
Registrarse FAQ Miembros Calendario Guía de estilo Temas de Hoy

Colaboración Paypal con ClubDelphi

Respuesta
 
Herramientas Buscar en Tema Desplegado
  #1261  
Antiguo 06-02-2024
CarlosR CarlosR is offline
Miembro
 
Registrado: sep 2015
Posts: 98
Poder: 10
CarlosR Va por buen camino
Gracias por la rapidez. Tiene lógica, no obstante tenía entre ceja y ceja la impresión de que los datos de veri*factu deberían estar en la misma tabla.
Si es lo que otros están haciendo seguro que es así. Cien ojos ven mas que dos.
Revisaré mi código lo antes posible.
Responder Con Cita
  #1262  
Antiguo 06-02-2024
Avatar de Neftali [Germán.Estévez]
Neftali [Germán.Estévez] Neftali [Germán.Estévez] is offline
[becario]
 
Registrado: jul 2004
Ubicación: Barcelona - España
Posts: 18.549
Poder: 10
Neftali [Germán.Estévez] Es un diamante en brutoNeftali [Germán.Estévez] Es un diamante en brutoNeftali [Germán.Estévez] Es un diamante en bruto
Cita:
Empezado por CarlosR Ver Mensaje
Tiene lógica, no obstante tenía entre ceja y ceja la impresión de que los datos de veri*factu deberían estar en la misma tabla.
Si es lo que otros están haciendo seguro que es así. Cien ojos ven mas que dos.
Nosotros también tenemos tablas separadas para estos datos.
Es más normalizado.
Además de esa forma no penalizas con esos campos extra en la tabla de FACTURAS (aunque estén vacíos) a clientes que no los necesitas o que no tienen VERI*FACTU.
__________________
Germán Estévez => Web/Blog
Guía de estilo, Guía alternativa
Utiliza TAG's en tus mensajes.
Contactar con el Clubdelphi

P.D: Más tiempo dedicado a la pregunta=Mejores respuestas.
Responder Con Cita
  #1263  
Antiguo 06-02-2024
Avatar de keys
keys keys is offline
Miembro
 
Registrado: sep 2003
Ubicación: Bilbao
Posts: 1.085
Poder: 23
keys Va por buen camino
Cita:
Empezado por Neftali [Germán.Estévez] Ver Mensaje
Nosotros también tenemos tablas separadas para estos datos.
Es más normalizado.
Además de esa forma no penalizas con esos campos extra en la tabla de FACTURAS (aunque estén vacíos) a clientes que no los necesitas o que no tienen VERI*FACTU.
Que yo sepa Veri*Factu no dice que tengas que tener esos campos en la base de datos, sólo dice que el programa tiene que ser capaz de generar unos ficheros con esa estructura para poder enviarlos a hacienda, ademas de garantizar el hash y otra serie de cosas de las facturas.

Otra cosa es que este mejor o peor estructurada la base de datos por tener unas tablas diferentes, ya que al final estas guardando datos en tablas distintas y al final puede influir en el rendimiento de la aplicación.
Responder Con Cita
  #1264  
Antiguo 06-02-2024
Avatar de Neftali [Germán.Estévez]
Neftali [Germán.Estévez] Neftali [Germán.Estévez] is offline
[becario]
 
Registrado: jul 2004
Ubicación: Barcelona - España
Posts: 18.549
Poder: 10
Neftali [Germán.Estévez] Es un diamante en brutoNeftali [Germán.Estévez] Es un diamante en brutoNeftali [Germán.Estévez] Es un diamante en bruto
Cita:
Empezado por keys Ver Mensaje
Que yo sepa Veri*Factu no dice que tengas que tener esos campos en la base de datos, sólo dice que el programa tiene que ser capaz de generar unos ficheros con esa estructura para poder enviarlos a hacienda, ademas de garantizar el hash y otra serie de cosas de las facturas.

Otra cosa es que este mejor o peor estructurada la base de datos por tener unas tablas diferentes, ya que al final estas guardando datos en tablas distintas y al final puede influir en el rendimiento de la aplicación.

Totalmente de acuerdo.
En nuestro caso hemos decidido guardar siempre lo que se envía (SII, TBAI, VERI*FACTU,...). Pero es una decisión personal, en algunos casos no es obligatorio y como bien dices, si se hace tampoco tiene porqué ser en base de Datos. Esto es decisión nuestra.
__________________
Germán Estévez => Web/Blog
Guía de estilo, Guía alternativa
Utiliza TAG's en tus mensajes.
Contactar con el Clubdelphi

P.D: Más tiempo dedicado a la pregunta=Mejores respuestas.
Responder Con Cita
  #1265  
Antiguo 06-02-2024
Avatar de keys
keys keys is offline
Miembro
 
Registrado: sep 2003
Ubicación: Bilbao
Posts: 1.085
Poder: 23
keys Va por buen camino
Gracias, es que era por si se me escapaba algo.
Responder Con Cita
  #1266  
Antiguo 06-02-2024
pararegistrarme pararegistrarme is offline
Registrado
 
Registrado: ago 2014
Posts: 4
Poder: 0
pararegistrarme Va por buen camino
Códigos QR en impresoras ESC/POS

Hola a todos.


Me llamo Jose y voy a participar en este foro a partir de ahora aportando lo que buenamente pueda.
He estado leyendo todos los mensajes que lleváis escritos durante estos meses y algunos de ellos son bastante esclarecedores.
Parece que estamos un poco parados a la espera de la famosa Orden Ministerial para dar el pistoletazo de salida.
Respecto a la forma de sacar el XML para poder calcular el HASH esperemos que la OM lo aclare ya que, como bien habéis dicho, el XML ha de ser exacto al que coja la aeat.


He visto que tenéis preparadas las facturas con los códigos QR. Mi pregunta es si alguien ha desarrollado en Delphi la impresión de códigos QR para impresoras con lenguaje ESC/POS. Me sería de gran ayuda.


Gracias por vuestra ayuda, vuestros aportes e ideas.


Lo importante es que, entre todos, podamos ahorrarnos tiempo y resolvernos dudas/problemas que de otra forma sería caótico.


Un saludo
Responder Con Cita
  #1267  
Antiguo 06-02-2024
CarlosR CarlosR is offline
Miembro
 
Registrado: sep 2015
Posts: 98
Poder: 10
CarlosR Va por buen camino
Corrígeme si me equivoco, pero el aplicativo debe poder acogerse a veri*factu o no, es decisión de la empresa acogerse o no. El aplicativo debe tener las dos versiones.
En el caso de que te acojas a veri*facto deberás enviar las facturas a la Agencia Tributaria de forma casi inmediata, y poco mas. En el caso de que no te acojas a veri*factu no podrás poner ningún QR en tus facturas y debes tener todos los protocolos de encadenamiento, cifrado, garantía de no cambio, archivo, exportación de logs..., etc.etc.
Como el aplicativo debe tener las dos, en mi caso he optado por seguir todos los pasos tanto si se envía a la Agencia Tributaria como si no.
Sigo teniendo dudas de si hay que llevar dos o mas tablas separadas de la tabla de cabecera de factura y pies de documento o bien serviría con encadenar las mismas facturas en un campo XML en la misma tabla de cabecera de facturas que es como realmente lo tengo diseñado. Creo entender que no hay una norma fijada a tenor de lo que estoy leyendo.
He estado en numerosos weminars y aparte de hablar de fechas de entrada en vigor y algún link de la AEAT poco mas se dice.
Aprecio enormemente la colaboración de foros como este, que en determinados momentos se vuelve una necesidad.
Responder Con Cita
  #1268  
Antiguo 06-02-2024
sglorka sglorka is offline
Miembro
 
Registrado: mar 2017
Posts: 224
Poder: 8
sglorka Va por buen camino
Cita:
Empezado por CarlosR Ver Mensaje
Corrígeme si me equivoco, pero el aplicativo debe poder acogerse a veri*factu o no, es decisión de la empresa acogerse o no. El aplicativo debe tener las dos versiones.
En el caso de que te acojas a veri*facto deberás enviar las facturas a la Agencia Tributaria de forma casi inmediata, y poco mas. En el caso de que no te acojas a veri*factu no podrás poner ningún QR en tus facturas y debes tener todos los protocolos de encadenamiento, cifrado, garantía de no cambio, archivo, exportación de logs..., etc.etc.
Como el aplicativo debe tener las dos, en mi caso he optado por seguir todos los pasos tanto si se envía a la Agencia Tributaria como si no.
Sigo teniendo dudas de si hay que llevar dos o mas tablas separadas de la tabla de cabecera de factura y pies de documento o bien serviría con encadenar las mismas facturas en un campo XML en la misma tabla de cabecera de facturas que es como realmente lo tengo diseñado. Creo entender que no hay una norma fijada a tenor de lo que estoy leyendo.
He estado en numerosos weminars y aparte de hablar de fechas de entrada en vigor y algún link de la AEAT poco mas se dice.
Aprecio enormemente la colaboración de foros como este, que en determinados momentos se vuelve una necesidad.
Yo tenía en mente también desarrollar el aplicativo para que cubriese el modo VeriFactu y el modo Requerimiento, pero esa idea voló de mi cabeza nada más ver en la OM, la tabla de eventos que hay que gestionar, además de hacerte cargo de la copia de seguridad de los registros de facturación durante los últimos 4 años que tienen que estar disponibles para un requerimiento. La aplicación no tiene porqué cubrir ambos modos, es más, creo que la inmensa mayoría sólo va a desarrollar VeriFactu y el cliente tendrá lentejas. El reglamento define un campo en el xml donde tú dices si tu aplicación va a trabajar en un modo u otro.

Respecto de las tablas que te traen loco, te haría una reflexión. A veces programamos para resolver un problema y una vez que tenemos el proceso funcionando lo cerramos y a otra cosa. No nos paramos a pensar cómo deberíamos actuar en caso de que dicho proceso tuviera que responder a un imprevisto. Mientras va todo bien el programa funciona pero si surge un problema, restauración del sistema con una copia de hace dos días por encriptación del equipo, envío incorrecto del algún campo como, fecha de operación, régimen tributario, huella calculada con un retorno de carro de más, etc. tenemos que poder resurgir de estas cenizas y que nuestro proceso pueda salir más o menos airoso.
Te digo esto porque da igual las tablas que uses para resolver el problema, te tienes que preguntar lo siguiente. ¿ Con la estructura que he diseñado para el mundo de las mil maravillas donde todo funciona, podría rehacerme de un imprevisto ?

En mi caso particular, le emisión de documentos de venta no la he tocado en el sistema. He creado tablas de apoyo, Cabeceras, Líneas de venta, Bases-Tipos-Cuotas, etc que almacenan una foto estática de cómo se ha emitido la factura, con descripciones de productos, nombre, dirección, provincia de cliente, etc. sin identificadores, sólo texto descriptivo. Estas tablas las uso para generar los registros de facturación y no guardan integridad referencial con mis tablas maestras. Cuando imprimo una factura ya no lo hago desde mis tablas de facturas si no de estas tablas de apoyo que están aisladas ( recuerda que si reimprimes una copia de factura debe decir lo mismo que la primera vez que lo hiciste, si has cambiado datos personales del cliente o descripciones de productos, no pueden influir en esta copia).
Estas tablas no participan de ningún repositorio de informes con lo que no penalizan la obtención de los mismos.

En resumen, espero que te sirva de un poco de ayuda.
Responder Con Cita
  #1269  
Antiguo 06-02-2024
CarlosR CarlosR is offline
Miembro
 
Registrado: sep 2015
Posts: 98
Poder: 10
CarlosR Va por buen camino
Si, realmente es un tostón no acogerse a veri*factu. Por eso llevo ya mas de un año cambiando TODO el sistema de gestión. Entre otras cuestiones los logs y la identificación de cada registro. Hay un log para developers y otro para el que lleve el mantenimiento de la instalación y otro para el propio sistema. Allí se recogen todas las incidencias. Se necesita una buena auditoría, aunque nadie está libre de intervenciones externas. Eso sí, hay que registrarlo todo en los logs y no se pueden alterar.
Según yo leí en el comunicado del año 2022 parece ser que los aplicativos DEBEN TENER LAS DOS MODALIDADES. Es el cliente quien exige eso.
Puedes trabajar en la nube, es otra opción. Ahí puedes tener las copias automatizadas y controladas. Personalmente trabajo la mayoría con C++ builder pero tanto C++ como Delphi tienen un gran sistema cliente/servidor denominado DataSnap. Eso te da capas para trabajar en la nube con seguridad y potencia.
En fin, gracias por vuestro inestimable apoyo. Cualquier cosa que se necesite en el foro no hay mas que hacérmelo saber.
Responder Con Cita
  #1270  
Antiguo 07-02-2024
edari edari is offline
Miembro
 
Registrado: jun 2021
Posts: 222
Poder: 4
edari Va por buen camino
Cita:
Empezado por CarlosR Ver Mensaje
Corrígeme si me equivoco, pero el aplicativo debe poder acogerse a veri*factu o no, es decisión de la empresa acogerse o no. El aplicativo debe tener las dos versiones.
En el caso de que te acojas a veri*facto deberás enviar las facturas a la Agencia Tributaria de forma casi inmediata, y poco mas. En el caso de que no te acojas a veri*factu no podrás poner ningún QR en tus facturas y debes tener todos los protocolos de encadenamiento, cifrado, garantía de no cambio, archivo, exportación de logs..., etc.etc.
Como el aplicativo debe tener las dos, en mi caso he optado por seguir todos los pasos tanto si se envía a la Agencia Tributaria como si no.
Sigo teniendo dudas de si hay que llevar dos o mas tablas separadas de la tabla de cabecera de factura y pies de documento o bien serviría con encadenar las mismas facturas en un campo XML en la misma tabla de cabecera de facturas que es como realmente lo tengo diseñado. Creo entender que no hay una norma fijada a tenor de lo que estoy leyendo.
He estado en numerosos weminars y aparte de hablar de fechas de entrada en vigor y algún link de la AEAT poco mas se dice.
Aprecio enormemente la colaboración de foros como este, que en determinados momentos se vuelve una necesidad.

Yo no lo tengo tan claro.


Nosotros solo vamos a hacer la programar la opción Verifactu y tengo claro que es potestad de nuestros clientes si alguno quiere quedarse en el otro sistema abandonar nuestra empresa.
Responder Con Cita
  #1271  
Antiguo 07-02-2024
Sistel Sistel is offline
Miembro
 
Registrado: nov 2019
Ubicación: Bilbao
Posts: 416
Poder: 5
Sistel Va por buen camino
Cita:
Empezado por edari Ver Mensaje
Yo no lo tengo tan claro.
Nosotros solo vamos a hacer la programar la opción Verifactu y tengo claro que es potestad de nuestros clientes si alguno quiere quedarse en el otro sistema abandonar nuestra empresa.
Hola,

Soy de la misma opinión.
Nosotros ofreceremos sólo la opción Verifactu y al cliente que no le guste ... tiene otras ofertas en el mercado.

Saludos
Responder Con Cita
  #1272  
Antiguo 07-02-2024
Avatar de Neftali [Germán.Estévez]
Neftali [Germán.Estévez] Neftali [Germán.Estévez] is offline
[becario]
 
Registrado: jul 2004
Ubicación: Barcelona - España
Posts: 18.549
Poder: 10
Neftali [Germán.Estévez] Es un diamante en brutoNeftali [Germán.Estévez] Es un diamante en brutoNeftali [Germán.Estévez] Es un diamante en bruto
Cita:
Empezado por CarlosR Ver Mensaje
...pero el aplicativo debe poder acogerse a veri*factu o no, es decisión de la empresa acogerse o no.
El aplicativo debe tener las dos versiones.
Yo no tengo claro esas afirmaciones.
No creo que el programa deba llevar las 2 implementaciones y no creo eso sea una decisión del cliente final.

Creo que tú puedes decidir implementar la opción de envío inmediato (con eso ya cumples con la ley) y vender tu programa con esa implementación.
Puedes justificar más o menos al cliente porqué tu programa funciona de esas manera, pero no creo que estés obligado a más.

Cita:
Empezado por CarlosR Ver Mensaje
Sigo teniendo dudas de si hay que llevar dos o mas tablas separadas de la tabla de cabecera de factura y pies de documento o bien serviría con encadenar las mismas facturas en un campo XML en la misma tabla de cabecera de facturas que es como realmente lo tengo diseñado.
Creo que estás mezclando cosas.
De verdad que no veo que tiene que ver el encadenamiento de los XML de las facturas que envías a la AEAT, con el diseño de tablas de tu aplicación.
Al final tú guardas facturas en tu Base de Datos (sea como sea), de cada factura generas un XML, le añades una parte del ultimo XML generado(encadenamiento) y lo firmas.
__________________
Germán Estévez => Web/Blog
Guía de estilo, Guía alternativa
Utiliza TAG's en tus mensajes.
Contactar con el Clubdelphi

P.D: Más tiempo dedicado a la pregunta=Mejores respuestas.

Última edición por Neftali [Germán.Estévez] fecha: 07-02-2024 a las 10:03:41.
Responder Con Cita
  #1273  
Antiguo 07-02-2024
Avatar de newtron
[newtron] newtron is offline
Membrillo Premium
 
Registrado: abr 2007
Ubicación: Motril, Granada
Posts: 3.591
Poder: 21
newtron Va camino a la fama
Hola a tod@s.


Según interpreto yo en lo que he leido sobre la ley TODOS los programas que salgan al mercado tendrán que ser VeriFactu 9 meses después de la publicación del desarrollo de la ley. Independientemente de eso el usuario final decidirá si envía de forma automática los datos o no pero el programa deberá de tener la opción de enviarlos a requerimiento de la aeat.


Saludos.
__________________
Be water my friend.
Responder Con Cita
  #1274  
Antiguo 07-02-2024
sglorka sglorka is offline
Miembro
 
Registrado: mar 2017
Posts: 224
Poder: 8
sglorka Va por buen camino
Cita:
Empezado por newtron Ver Mensaje
Hola a tod@s.


Según interpreto yo en lo que he leido sobre la ley TODOS los programas que salgan al mercado tendrán que ser VeriFactu 9 meses después de la publicación del desarrollo de la ley. Independientemente de eso el usuario final decidirá si envía de forma automática los datos o no pero el programa deberá de tener la opción de enviarlos a requerimiento de la aeat.


Saludos.
Creo que no lo has interpretado bien. Cito Orden Ministerial

Artículo 3. Particularidades aplicables a los “Sistemas VERI*FACTU”.
De acuerdo con lo previsto en el artículo 16.2 del Reglamento, se presumirá que los sistemas
informáticos que tengan la consideración de “Sistemas de emisión de facturas verificables” o
“Sistemas VERI*FACTU”, cumplen por diseño los requisitos y características que recogen el
resto de secciones del capítulo II de esta orden y, en tanto actúen como sistemas
VERI*FACTU, no les serán de aplicación los artículos 6.b), 6.c), 6.d), 6.e), 6. f), 7.f), 7.h), 7.i),
7.j), 8 y 9 de esta orden.


Según el reglamento, un sistema es VeriFactu si realiza la remisión voluntaria de los registros de facturación de forma inmediata, consecutiva, segura, etc.. y sus características está desarrolladas en el
Artículo 16. Especificaciones técnicas de la remisión voluntaria

Por lo tanto, si un sistema VeriFactu está exento de cumplir el Artículo 8. Conservación, accesibilidad y legibilidad de los registros de facturación no nos pueden pedir mediante requerimiento la remisión de los registros de facturación por que , primero, no estamos obligados a conservarlos (Artículo 8) y segundo, evidente, ya los tienen ellos.
Responder Con Cita
  #1275  
Antiguo 07-02-2024
CarlosR CarlosR is offline
Miembro
 
Registrado: sep 2015
Posts: 98
Poder: 10
CarlosR Va por buen camino
Thumbs up citas de documentos oficiales de la AEAT

DOCUMENTO SOMETIDO A TRÁMITE DE INFORMACIÓN PÚBLICA 21 DE FEBRERO DE 2022

Página 11, Artículo 8.
... habla de los requisitos que debe cumplir todo programa informático indistintamente de si se utilizará o no veri*factu.

Página 17, Artículo 16.
2-A los efectos de este Reglamente, se presumirá que los Sistemas de emision de facturas verificables cumplen por diseño los requisitos del artículo 8.2

Página 17, Artículo 17.
1-Es voluntario acogerse a veri*factu (QR y subida de datos a la AEAT automática)
No sólo es voluntario sino que puedes solicitar una explusión de la empresa por determinados factores.

¿ Qué haces si el cliente no se había acogido a veri*factu y decide acogerse en algún ejercicio ?
¿ Una versión del programa en función de cada situación ? El productor informático no puede obligar al cliente a tomar una decisión fiscal.

BOLETIN OFICIAL DEL ESTADO 06-12-2023

Página 161955,
... etandarización de los formatos de los registros que contienen la información generada, su aportación a la Administración Tributaria, ya sea mediante requerimiento singular...

Página 161956,
... necesidad de interactuar con tales datos en su formato nativo
b) Conseguir que todas las operacones que se realicen se graben en el sistema informático de manera segura, no manipulable, accesible...
d) Garantizar la integridad, autenticidad y trazabilidad de los datos registrados...

Página 161961,
apartados Dos y Tres. Habla sobre los requisitos a aplicar en los sistemas informáticos incluido veri*factu

Para concluir :

He estado en algunos weminar, entre otros uno en el que participaba el director general de informática y de inspecciones tributarias,
la conclusión mas o menos que comprendí (es difícil comprender a esta gente) fue que si usas veri*factu la AEAT no indagará mucho mas
en los sistemas informáticos porque ya tienen los datos allí.

Sin otro ánimo de parecer un PESADO quería aclarar mi post. Grcias por vuestras participaciones.
Cada una me aporta una nueva forma de comprender el proceso de integración y enriquece el producto final.
Un saludo a todos.

P.D. "No existen preguntas sin respuesta, solo preguntas mal formuladas." -Laurence Fishburne-
Responder Con Cita
  #1276  
Antiguo 07-02-2024
Avatar de Neftali [Germán.Estévez]
Neftali [Germán.Estévez] Neftali [Germán.Estévez] is offline
[becario]
 
Registrado: jul 2004
Ubicación: Barcelona - España
Posts: 18.549
Poder: 10
Neftali [Germán.Estévez] Es un diamante en brutoNeftali [Germán.Estévez] Es un diamante en brutoNeftali [Germán.Estévez] Es un diamante en bruto
Lo pongo aquí porque es un tema importante.

Estraído de las dispositivas de la AEAT, de este PDF:
https://www.agenciatributaria.es/sta.../Novedades.pdf




Según el párrafo señalado, yo entiendo que la AEAT asume que puede haber sistemas sólo diseñados como VERI*FACTU. Si eso no estuviera permitido ya ni lo pondrían aquí.
__________________
Germán Estévez => Web/Blog
Guía de estilo, Guía alternativa
Utiliza TAG's en tus mensajes.
Contactar con el Clubdelphi

P.D: Más tiempo dedicado a la pregunta=Mejores respuestas.
Responder Con Cita
  #1277  
Antiguo 07-02-2024
CarlosR CarlosR is offline
Miembro
 
Registrado: sep 2015
Posts: 98
Poder: 10
CarlosR Va por buen camino
Thumbs up

Pues sí, había visto ese PDF y creo que hasta lo tengo impreso, pero por alguna razón no lo recordaba.
Queda meridianamente claro.

Gracias.
Responder Con Cita
  #1278  
Antiguo 07-02-2024
antoine0 antoine0 is offline
Miembro
 
Registrado: oct 2021
Posts: 233
Poder: 4
antoine0 Va por buen camino
Cita:
Empezado por CarlosR Ver Mensaje
¿ Qué haces si el cliente no se había acogido a veri*factu y decide acogerse en algún ejercicio ?
Lo mismo que tu haces si tu cliente te dice que se ha acogido a una opción inusual del Código aduanero, o decide emitir algunas facturas acogidas al IVA en otro país de la U.E. (para poner ejemplos): le explicas a tu cliente que tu programa no es un todopoderoso y que este caso no lo contempla (en la actualidad; siempre dejar opciones comerciales...)

Cita:
¿ Una versión del programa en función de cada situación ?
Esto me da a pensar que el precio de los programas no-Veri*factu (o con las dos opciones) pueden salir más caros que los programas solo Veri*factu; e incluso que la diferencia puede ser notable.
Y creo que sería bastante lógico, además.

Cita:
El productor informático no puede obligar al cliente a tomar una decisión fiscal.
No es lo que estas haciendo, si le dices a tu cliente que no lo puedes acompañar en su viaje si él toma tal decisión.
Dicho de otra forma: si implementas solo la parte Veri*factu, lo debes poner bien claro en la documentación comercial, para que le cliente no se equivoque comprando el programa inadaptado.
Y si tienes clientes ya y no piensas desarrollar la opción no-Veri*factu, ahora parece un buen momento para pensar en el mensaje marketing que hay que diseñar para explicar a estos clientes 1º que les va a costar el cambio iniciado por el gobierno (incluso cosas como poner el sistema de facturación conectado a internet, o el tema de los certificados), y 2º que solo está la opción de acogerse al Veri*factu, si se quieren quedar contigo y tener menos inspecciones de Hacienda. O algo así (no soy bueno en marketing ).
Responder Con Cita
  #1279  
Antiguo 07-02-2024
jlmoli_67 jlmoli_67 is offline
Miembro
 
Registrado: feb 2024
Posts: 43
Poder: 0
jlmoli_67 Va por buen camino
Problema con destinatario en el xml

Buenas, tengo un problema que llevo tres dias sin poder solventar y que esta relacionado con los destinatarios.

No tengo narices de crear el siguiente nodo con el wsdl importado dentro de RegistroAltaFacturas (..prewww2.aeat.es|static_files|common|internet|dep|aplicaciones|es|aeat|tikeV1.0|cont|ws|SistemaFac turacion.wsdl)


<sum1: Destinatarios>
<sum1: IDDestinatario>
<sum1: NombreRazon>XXXXX</sum1:NombreRazon>
<sum1:NIF>XXXXX</sum1:NIF>
</sum1:IDDestinatario>
</sum1: Destinatarios>

Para empezar no puedo asignar la propiedad NIF a PersonaFisicaJuridicaType pero si me aparece dicha propiedad para PersonaFisicaJuridicaESType.

Como lo lo habeis hecho ? Alguien por favor me podria ayudar mostrandome el codigo a generar para poder crear el dichoso destinatario?


muchas gracias de antemano
Responder Con Cita
  #1280  
Antiguo 08-02-2024
jlmoli_67 jlmoli_67 is offline
Miembro
 
Registrado: feb 2024
Posts: 43
Poder: 0
jlmoli_67 Va por buen camino
Ya lo consegui, gracias.

Tengo ya casi todo el xml. Lo poco que me queda creo que no me dara problemas.

El codigo lo desarrolle en vb .net y lo tengo bastante avanzado. Si alguien lo necesita sera un placer darselo.
Responder Con Cita
Respuesta



Normas de Publicación
no Puedes crear nuevos temas
no Puedes responder a temas
no Puedes adjuntar archivos
no Puedes editar tus mensajes

El código vB está habilitado
Las caritas están habilitado
Código [IMG] está habilitado
Código HTML está deshabilitado
Saltar a Foro

Temas Similares
Tema Autor Foro Respuestas Último mensaje
Hijo de Informáticos gluglu Humor 3 13-03-2007 12:05:35
Adictos informaticos ... Trigger Humor 2 11-10-2004 13:18:32
Nosotros los Informáticos Trigger Humor 1 10-10-2004 15:58:09
Patrón de los Informáticos. obiwuan Varios 20 10-09-2003 15:44:54
Chistes Informaticos jhonny Humor 2 11-08-2003 22:59:09


La franja horaria es GMT +2. Ahora son las 01:34:36.


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
Copyright 1996-2007 Club Delphi