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

Grupo de Teaming del ClubDelphi

Respuesta
 
Herramientas Buscar en Tema Desplegado
  #1  
Antiguo Hace 1 Semana
ermendalenda ermendalenda is offline
Miembro
 
Registrado: ago 2021
Posts: 886
Poder: 3
ermendalenda Va por buen camino
Buenas, alguien ha podido revisar los cambios que han subido hoy?
Responder Con Cita
  #2  
Antiguo Hace 1 Semana
novatico novatico is offline
Miembro
 
Registrado: dic 2022
Posts: 20
Poder: 0
novatico Va por buen camino
Cita:
Empezado por ermendalenda Ver Mensaje
Buenas, alguien ha podido revisar los cambios que han subido hoy?
Yo he descargado y revisado los 2 documentos.

En el DRAnexoOM_RD1007 vers. 0.13.1, en la pag. 0, como siempre aparece la lista de supuestos cambios en el resto de páginas, pero no se si estoy ciego pero no veo a que hace referencia.

En el documento de Validaciones y Errores, explica más concretamente que permiten algunos campos, como y cuando rellenarlos y también detalla algo con respecto a las "altas" y "anulaciones", que yo no había visto antes. Concretamente dice que, aunque en un mismo envío VERI*FACTU, se pueden incluir ALTAS y ANULACIONES, deben estar en diferentes bloques de "RegistroFactura", es decir, hacer como mínimo, un bloque de "RegistroFactura" para los "RegistrosAlta" y otro bloque de "RegistroFacturas" para los "RegistroAnulacion". No me queda claro si los puedo ir alternando según se hayan generado las facturas o debo agruparlos en 2 bloques para enviarlos. Esto lo puedes ver en el apartado "3.1.2 Validaciones de negocio del bloque RegistroFactura" del PDF de Validaciones.

Hay más validaciones que aclarán las posibilidades de algunos campos.

Un saludo.

Última edición por novatico fecha: Hace 1 Semana a las 11:37:16.
Responder Con Cita
  #3  
Antiguo Hace 1 Semana
ermendalenda ermendalenda is offline
Miembro
 
Registrado: ago 2021
Posts: 886
Poder: 3
ermendalenda Va por buen camino
Cita:
Empezado por novatico Ver Mensaje
Yo he descargado y revisado los 2 documentos.

En el DRAnexoOM_RD1007 vers. 0.13.1, en la pag. 0, como siempre aparece la lista de supuestos cambios en el resto de páginas, pero no se si estoy ciego pero no veo a que hace referencia.

En el documento de Validaciones y Errores, explica más concretamente que permiten algunos campos, como y cuando rellenarlos y también detalla algo con respecto a las "altas" y "anulaciones", que yo no había visto antes. Concretamente dice que, aunque en un mismo envío VERI*FACTU, se pueden incluir ALTAS y ANULACIONES, deben estar en diferentes bloques de "RegistroFactura", es decir, hacer como mínimo, un bloque de "RegistroFactura" para los "RegistrosAlta" y otro bloque de "RegistroFacturas" para los "RegistroAnulacion". No me queda claro si los puedo ir alternando según se hayan generado las facturas o debo agruparlos en 2 bloques para enviarlos. Esto lo puedes ver en el apartado "3.1.2 Validaciones de negocio del bloque RegistroFactura" del PDF de Validaciones.

Hay más validaciones que aclarán las posibilidades de algunos campos.

Un saludo.
Gracias
Van soltando poco a poco para que no nos aburramos
Responder Con Cita
  #4  
Antiguo Hace 1 Semana
CarlosR CarlosR is offline
Miembro
 
Registrado: sep 2015
Posts: 67
Poder: 9
CarlosR Va por buen camino
Firma digital

Cita:
Empezado por ermendalenda Ver Mensaje
Gracias
Van soltando poco a poco para que no nos aburramos

Usando algo de ironía le daría la razón. Pero creo que los tiros no van por ahí.

Cuando ya tienes algo hecho van y te fastidian el código. Como si se disfrutara de tiempo libre o si esto fuese un jobi.
O no lo tienen claro o demoran el tiempo para que coincida con la implantación in-situ en los clientes.
Personalmente nunca entendí que los desarrolladores tuviesen que tenerlo antes que los clientes. ¿ Cómo se puede hacer para tenerlo listo antes y no seguir actualizando a los clientes ? Y si se actualiza a los clientes entonces ya estarían obligados.



Aparte de esta discusión que tampoco lleva a ningún puerto, ¿ alguien está trabajando en firmar el xml ?
No me refiero a usar la firma digital para el canal de comunicaciones del webservice sino a la firma en el propio xml.

En el documento sometido a trámite de audiencia e información pública el 4 de enero de 2024 en la página 18 artículo 14 se habla de firma electrónica de los registros de facturación.

No detalla ni especifica si es para NO verifactu exclusivamente. Entiendo que sí. Pero aunque no se requiera en verifactu, ¿ alguien lo va a usar ? ¿ Sabe como hacerlo ?
No encontré ninguna información al respecto.


Un saludo.
Responder Con Cita
  #5  
Antiguo Hace 1 Semana
novatico novatico is offline
Miembro
 
Registrado: dic 2022
Posts: 20
Poder: 0
novatico Va por buen camino
Cita:
Empezado por CarlosR Ver Mensaje
Usando algo de ironía le daría la razón. Pero creo que los tiros no van por ahí.

Cuando ya tienes algo hecho van y te fastidian el código. Como si se disfrutara de tiempo libre o si esto fuese un jobi.
O no lo tienen claro o demoran el tiempo para que coincida con la implantación in-situ en los clientes.
Personalmente nunca entendí que los desarrolladores tuviesen que tenerlo antes que los clientes. ¿ Cómo se puede hacer para tenerlo listo antes y no seguir actualizando a los clientes ? Y si se actualiza a los clientes entonces ya estarían obligados.



Aparte de esta discusión que tampoco lleva a ningún puerto, ¿ alguien está trabajando en firmar el xml ?
No me refiero a usar la firma digital para el canal de comunicaciones del webservice sino a la firma en el propio xml.

En el documento sometido a trámite de audiencia e información pública el 4 de enero de 2024 en la página 18 artículo 14 se habla de firma electrónica de los registros de facturación.

No detalla ni especifica si es para NO verifactu exclusivamente. Entiendo que sí. Pero aunque no se requiera en verifactu, ¿ alguien lo va a usar ? ¿ Sabe como hacerlo ?
No encontré ninguna información al respecto.


Un saludo.
Con respecto a las fechas diferentes para desarrolladores y clientes, supone llevar paralelamente 2 programas, uno el que puedes instalar a los clientes hasta la fecha de entrada en vigor para ellos, y otro el que vas desarrollando con todo lo que necesitas incluir para cumplir la OM.

En el documento que publicaron de preguntas realizadas en el último webinar, dejan claro que la firma de los registros de facturación SOLO ES PARA NO VERIFACTU.

Por último comentar que, hasta hace poco en mi empresa se pretendía desarrollar una aplicación DUAL, es decir, para VERIFACTU y para NO VERIFACTU, pero con los últimos cambios que están introduciendo en todos los diseños y en la operativa, así como en la problemática de que el cliente sea el depositario de los Registros de Facturación, perdiendo los desarrolladores el control aunque no parte de la responsabilidad, estamos prácticamente decididos a desarrollar la aplicación como SOLO VERIFACTU, con la única salvedad de controlar la posibilidad de que el OT esté excluido de presentar los registros, como por ejemplo si está sujeto al SII.
Responder Con Cita
  #6  
Antiguo Hace 1 Semana
CarlosR CarlosR is offline
Miembro
 
Registrado: sep 2015
Posts: 67
Poder: 9
CarlosR Va por buen camino
Firma digital

Cita:
Empezado por novatico Ver Mensaje
Con respecto a las fechas diferentes para desarrolladores y clientes, supone llevar paralelamente 2 programas, uno el que puedes instalar a los clientes hasta la fecha de entrada en vigor para ellos, y otro el que vas desarrollando con todo lo que necesitas incluir para cumplir la OM.

En el documento que publicaron de preguntas realizadas en el último webinar, dejan claro que la firma de los registros de facturación SOLO ES PARA NO VERIFACTU.

Por último comentar que, hasta hace poco en mi empresa se pretendía desarrollar una aplicación DUAL, es decir, para VERIFACTU y para NO VERIFACTU, pero con los últimos cambios que están introduciendo en todos los diseños y en la operativa, así como en la problemática de que el cliente sea el depositario de los Registros de Facturación, perdiendo los desarrolladores el control aunque no parte de la responsabilidad, estamos prácticamente decididos a desarrollar la aplicación como SOLO VERIFACTU, con la única salvedad de controlar la posibilidad de que el OT esté excluido de presentar los registros, como por ejemplo si está sujeto al SII.

Gracias por su respuesta. Llevar dos códigos de soft en paralelo es bastante costoso. Al menos para nustra empresa.

No tengo claro si al final voy a sacar el soft dual o no. De momento intentaré cumplir toda la normativa del modelo dual. Seguramente bloquearé los ejecutables para que solo soporten verifactu. Pero dejo la puerta abierta a utilizar NO verifactu en un futuro si el mercado así me lo exige. Si esto sucede tendré dos versiones, una dual y otra no. Mas que nada será la misma versión bloqueada para que nadie se pueda columpiar con los datos y diferenciada en sus identificadores. Desde luego no voy a asumir directamente la responsabilidad de la custodia y no alteración de los datos de ningún cliente. En último recurso habrá que hacer un contrato, etc.etc. Los abogados saben de eso. Pero poner mi pequeño patrimonio en una balanza para cumplir los caprichos de un cliente, ni de coña.

Si tiene nociones sobre como usar una firma digital en el xml me sería de gran ayuda. O si usa algún producto del mercado para tal fin.



Gracias.
Responder Con Cita
  #7  
Antiguo Hace 1 Semana
Avatar de newtron
[newtron] newtron is offline
Membrillo Premium
 
Registrado: abr 2007
Ubicación: Motril, Granada
Posts: 3.473
Poder: 21
newtron Va camino a la fama
Cita:
Empezado por novatico Ver Mensaje
Con respecto a las fechas diferentes para desarrolladores y clientes, supone llevar paralelamente 2 programas, uno el que puedes instalar a los clientes hasta la fecha de entrada en vigor para ellos, y otro el que vas desarrollando con todo lo que necesitas incluir para cumplir la OM.

En el documento que publicaron de preguntas realizadas en el último webinar, dejan claro que la firma de los registros de facturación SOLO ES PARA NO VERIFACTU.

Por último comentar que, hasta hace poco en mi empresa se pretendía desarrollar una aplicación DUAL, es decir, para VERIFACTU y para NO VERIFACTU, pero con los últimos cambios que están introduciendo en todos los diseños y en la operativa, así como en la problemática de que el cliente sea el depositario de los Registros de Facturación, perdiendo los desarrolladores el control aunque no parte de la responsabilidad, estamos prácticamente decididos a desarrollar la aplicación como SOLO VERIFACTU, con la única salvedad de controlar la posibilidad de que el OT esté excluido de presentar los registros, como por ejemplo si está sujeto al SII.

No sé si me estoy perdiendo algo pero yo veo claramente que los programas hay que prepararlos para ser VERIFACTU y simplemente poner una opción para que los registros se envíen de forma automática o no. De esta manera el que quiera que envíe y el que no que tenga una opción para enviar los registros (entre fechas imagino) si se los requieren.


Saludos.
__________________
Be water my friend.
Responder Con Cita
  #8  
Antiguo Hace 1 Semana
pablog2k pablog2k is offline
Miembro
 
Registrado: may 2017
Posts: 86
Poder: 8
pablog2k Va por buen camino
Cita:
Empezado por newtron Ver Mensaje
No sé si me estoy perdiendo algo pero yo veo claramente que los programas hay que prepararlos para ser VERIFACTU y simplemente poner una opción para que los registros se envíen de forma automática o no. De esta manera el que quiera que envíe y el que no que tenga una opción para enviar los registros (entre fechas imagino) si se los requieren.


Saludos.
no es así del todo.
con verifactu NO tienes que firmar el xml , simplemente lo generas y se lo envías a la AEAT, de manera mas o menos inmediata
sin verifactu SI que tienes que firmar el xml (como hace ticketbai) , guardártelo , y enviarlo a la AEAT cuando lo soliciten (y encima la responsabilidad es tuya como comentan los compañeros)
Por eso al final siempre va a ser mejor con VERIFACTU, ya que haces el xml (sin firmar), envías y listo
Responder Con Cita
  #9  
Antiguo Hace 1 Semana
CarlosR CarlosR is offline
Miembro
 
Registrado: sep 2015
Posts: 67
Poder: 9
CarlosR Va por buen camino
No verifactu

Cita:
Empezado por newtron Ver Mensaje
No sé si me estoy perdiendo algo pero yo veo claramente que los programas hay que prepararlos para ser VERIFACTU y simplemente poner una opción para que los registros se envíen de forma automática o no. De esta manera el que quiera que envíe y el que no que tenga una opción para enviar los registros (entre fechas imagino) si se los requieren.


Saludos.

Sinceramente creo que se está perdiendo en un laberinto de normas. NO verifactu es mucho mucho mas restrictivo que verifactu. Encima el responsable de la autenticación, conservación y verificación de los datos del cliente es usted no su cliente.
Se firman los registros en NO verifactu, en cambio en verifactu no.
Se firman los eventos. Los requerimientos de la AEAT van a ser continuados, etc.etc.etc.

No tengo a mano ahora mismo toda la documentación al respecto pero ante la duda yo también aconsejo usar "solo verifactu". Opción en la que se renuncia a usar NO verifactu. Si el programa tiene las dos opciones debe cumplir la mas restrictiva que es NO verifactu.
En mi anterior comentario he aludido a que generaré dos ejecutables. Uno para dual verifactu / NO verifactu y otro ejecutable para solo verifactu. Solo verifactu es apriori el que pondré en producción.

No sé si al final sacaré el dual a producción porque tengo serias dudas de la responsabilidad que puedo adquirir, inclusive teniendo precios significativamente mayores para dar dicho soporte que tal vez no me compense el esfuerzo y riesgo.

En mi opinión debería leerse la documentación de la AEAT antes de poner en producción su proyecto. Mi consejo es que se acoja a solo veri*factu si tiene dudas.


Un saludo.
Responder Con Cita
  #10  
Antiguo Hace 1 Semana
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.289
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
Aparte de esta discusión que tampoco lleva a ningún puerto, ¿ alguien está trabajando en firmar el xml ?
No me refiero a usar la firma digital para el canal de comunicaciones del webservice sino a la firma en el propio xml.

Podéis revisar, si os queréis hacer una idea, el sistema de firma que se usa en TciketBAI (firma del XML) que imaginamos que va a ser similar a la que nos pedirán aquí.
Así podéis haceros una idea de los diferentes sistemas o componentes (SecureBlackBox , TElXMLSigner, Autofirma, Chillkat,...) que se pueden usar para firmar un XML y ver también algo de código.
Revisad este mensaje en la parte de Firmar XML.

NOTA DEL MODERADOR: Lo que si os pido es que no mezcléis referencias de ese hilo -TicketBAI- en este; Que nos sirva como consulta, pero hasta que no podamos discutir aquí sobre la firma en LeyAntifraude, no hagamos suposiciones ni demos por hecho que va a ser igual que allí (gracias).
__________________
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: Hace 1 Semana a las 12:41:14.
Responder Con Cita
  #11  
Antiguo Hace 1 Semana
CarlosR CarlosR is offline
Miembro
 
Registrado: sep 2015
Posts: 67
Poder: 9
CarlosR Va por buen camino
Firma digital

Cita:
Empezado por Neftali [Germán.Estévez] Ver Mensaje
Podéis revisar, si os queréis hacer una idea, el sistema de firma que se usa en TciketBAI (firma del XML) que imaginamos que va a ser similar a la que nos pedirán aquí.
Así podéis haceros una idea de los diferentes sistemas o componentes (SecureBlackBox , TElXMLSigner, Autofirma, Chillkat,...) que se pueden usar para firmar un XML y ver también algo de código.
Revisad este mensaje en la parte de Firmar XML.

NOTA: Lo que si os pido es que no mezcléis referencias de ese hilo -TicketBAI- en este; Que nos sirva como consulta, pero hasta que no podamos discutir aquí sobre la firma en LeyAntifraude, no hagamos suposiciones ni demos por hecho que va a ser igual que allí (gracias).

Voy a echar un vistazo.
Gracias.
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 11:05:35
Adictos informaticos ... Trigger Humor 2 11-10-2004 12:18:32
Nosotros los Informáticos Trigger Humor 1 10-10-2004 14:58:09
Patrón de los Informáticos. obiwuan Varios 20 10-09-2003 14:44:54
Chistes Informaticos jhonny Humor 2 11-08-2003 21:59:09


La franja horaria es GMT +2. Ahora son las 16:31:00.


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