Club Delphi  
    Paypal   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

Tema Cerrado
 
Herramientas Buscar en Tema Desplegado
  #1  
Antiguo 17-10-2024
sglorka sglorka is offline
Miembro
 
Registrado: mar 2017
Ubicación: Tenerife
Posts: 563
Poder: 10
sglorka Va por buen camino
Cita:
Empezado por rci Ver Mensaje
Por cierto, en este caso concreto, cogéis alguno de los mensajes del error (poco entendibles) para mostrar al usuario o creáis uno propio indicando que ha fallado el servidor remoto, por ejemplo.

Muchas Gracias
Pues te puedo dar alguna idea. Cuando recibes un error al enviar unmensaje se abren tres escenarios.

Escenario 1, no has llegado al servidor de Aeat, el objeto Respuesta tiene a Nothing la propiedad "RespuestaLinea" además del nodo "DatosPresentacion". Esta respuesta indica que la Aeat no se ha enterado de nada, fallo en comunicación, no hay Internet, endponit inccesible, ausencia de certificado, certificado no apto para autenticación sobre línea segura...) y el error lo devuelve el protocolo de comunicaciones. Los posibles errores que te vas a encontrar son "System.ServiceModel.EndpointNotFoundException", "System.ServiceModel.CommunicationException", "System.Security.Cryptography.CryptographicException", "System.ServiceModel.ProtocolException" . Debes proceder informando del error y volviendo a reenviar el mensaje.

Escenario 2, has llegado al servidor de Aeat, el objeto Respuesta tiene a Nothing la propiedad "RespuestaLinea" además del nodo "DatosPresentacion". Esta respuesta indica que la Aeat se ha enterado de que le ha llegado algo pero no entiende qué es, debido a que el modelo tiene algún tipo de fallo en su construcción, falta algún nodo, o el certificado que estás utilizando no lo reconoce. El típico error que recibirás es "System.ServiceModel.FaultException". En este caso, el reenvío no va a solucionar nada, debes informar al cliente que tiene que ponerse en contacto con su Servicio Técnico.

Escenario 3, has llegado al servidor de la Aeat, la propiedad "RespuestaLinea" del objeto Respuesta tiene contenido. El servicio te ha aceptado el mensaje con sus Registros de Facturación indicando en cada línea el estado de cada registro, Aceptado, Aceptado con Errores, Incorrecto. Informarás al cliente de lo que hay que subsanar o rectificar
  #2  
Antiguo 17-10-2024
rci rci is offline
Miembro
 
Registrado: nov 2020
Posts: 569
Poder: 6
rci Va por buen camino
Cita:
Empezado por sglorka Ver Mensaje
Pues te puedo dar alguna idea. Cuando recibes un error al enviar unmensaje se abren tres escenarios.

Escenario 1, no has llegado al servidor de Aeat, el objeto Respuesta tiene a Nothing la propiedad "RespuestaLinea" además del nodo "DatosPresentacion". Esta respuesta indica que la Aeat no se ha enterado de nada, fallo en comunicación, no hay Internet, endponit inccesible, ausencia de certificado, certificado no apto para autenticación sobre línea segura...) y el error lo devuelve el protocolo de comunicaciones. Los posibles errores que te vas a encontrar son "System.ServiceModel.EndpointNotFoundException", "System.ServiceModel.CommunicationException", "System.Security.Cryptography.CryptographicException", "System.ServiceModel.ProtocolException" . Debes proceder informando del error y volviendo a reenviar el mensaje.

Escenario 2, has llegado al servidor de Aeat, el objeto Respuesta tiene a Nothing la propiedad "RespuestaLinea" además del nodo "DatosPresentacion". Esta respuesta indica que la Aeat se ha enterado de que le ha llegado algo pero no entiende qué es, debido a que el modelo tiene algún tipo de fallo en su construcción, falta algún nodo, o el certificado que estás utilizando no lo reconoce. El típico error que recibirás es "System.ServiceModel.FaultException". En este caso, el reenvío no va a solucionar nada, debes informar al cliente que tiene que ponerse en contacto con su Servicio Técnico.

Escenario 3, has llegado al servidor de la Aeat, la propiedad "RespuestaLinea" del objeto Respuesta tiene contenido. El servicio te ha aceptado el mensaje con sus Registros de Facturación indicando en cada línea el estado de cada registro, Aceptado, Aceptado con Errores, Incorrecto. Informarás al cliente de lo que hay que subsanar o rectificar

Gracias sglorka, en el caso de hoy que el servidor estaba caído, no había respuesta, no había un el objeto Respuesta, saltaba una excepción (yo programo en c# .net).
Pero igualmente supongo que seria el escenario 1, informar que ha fallado la conexión y volver a intentar enviar.

Lo que yo preguntaba era si el mensaje lo redacta el programador, por ejemplo: "ha fallado la conexión" o cogéis el texto de la excepción "Error al recibir la respuesta HTTP a https://prewww1.aeat.es/wlpl/TIKE-CO.../VerifactuSOAP. Puede deberse a que el enlace del extremo de servicio no usa el protocolo HTTP. También puede deberse a que el servidor anula un contexto de solicitud HTTP (posiblemente por el cierre del servicio)." por ejemplo.
Si mostramos el segundo mensaje, el usuario es probable que no lo entienda

Última edición por rci fecha: 17-10-2024 a las 19:21:02.
  #3  
Antiguo 17-10-2024
sglorka sglorka is offline
Miembro
 
Registrado: mar 2017
Ubicación: Tenerife
Posts: 563
Poder: 10
sglorka Va por buen camino
Cita:
Empezado por rci Ver Mensaje
Gracias sglorka, en el caso de hoy que el servidor estaba caído, no había respuesta, no había un el objeto Respuesta, saltaba una excepción (yo programo en c# .net).
Pero igualmente supongo que seria el escenario 1, informar que ha fallado la conexión y volver a intentar enviar.

Si te fijas en el mensaje de error que has puesto en la primera línea pone "System.ServiceModel.CommunicationException",esto es lo que te hace ver que es un error de comunicaciones

Lo que yo preguntaba era si el mensaje lo redacta el programador, por ejemplo: "ha fallado la conexión" o cogéis el texto de la excepción "Error al recibir la respuesta HTTP a https://prewww1.aeat.es/wlpl/TIKE-CO.../VerifactuSOAP. Puede deberse a que el enlace del extremo de servicio no usa el protocolo HTTP. También puede deberse a que el servidor anula un contexto de solicitud HTTP (posiblemente por el cierre del servicio)." por ejemplo.
Si mostramos el segundo mensaje, el usuario es probable que no lo entienda
Yo creo que si tienes claro cúal es el error y puedes dar al usuario un procedimiento de solución debes exponer esa información, por ejemplo en este caso, detectas que el problema es de comunicaciones, "System.ServiceModel.CommunicationException", podrías informar al usuario con algo así "No hay conexión con la Aeat. Verifique que tiene conexión a Internet. Se reintentará la operación de envío en unos instantes. "
Si no tienes claro cuál es el error y por ende tampoco la solución, informarías del error y pondrías la coletilla... póngase en contacto con su Servicio Técnico.
  #4  
Antiguo 17-10-2024
jguarda jguarda is offline
Miembro
 
Registrado: feb 2008
Posts: 27
Poder: 0
jguarda Va por buen camino
duda

He buscado donde presentar la declaración responsable para comenzar a hacer pruebas, no he consguido encontrar donde entregar esto, alguien sabe donde se hace ?
  #5  
Antiguo 17-10-2024
edari edari is offline
Miembro
 
Registrado: jun 2021
Posts: 340
Poder: 6
edari Va por buen camino
Y en caso que esté caído su servidor, qué pasa con el husohorario que generamos en el envío fallido?
  #6  
Antiguo 17-10-2024
antoine0 antoine0 is offline
Miembro
 
Registrado: oct 2021
Posts: 260
Poder: 6
antoine0 Va por buen camino
Cita:
Empezado por edari Ver Mensaje
Y en caso que esté caído su servidor, qué pasa con el husohorario que generamos en el envío fallido?
¿Dónde está el problema?
Si no sabes en qué huso horario estas o qué hora es porque se ha caído un servidor de tu entorno que normalmente te suministra la información, o la máquina que ha facturado no se recuerda de dónde está (GPS offline) o una cosa similar, entonces generas el hora de tu sistema (que se supone estará dentro de los márgenes) y lo apuntas el huso horario Z (GMT) o el huso local de tu sistema, dependiendo de si recuperas la hora UTc o la hora local, y la AEAT debe ser contenta (¡por eso sirven los husos horarios!)

La AEAT compara las fechas-horas en la escala UTc, es decir independientemente de los husos horarios y de su efecto sobre las horas «locales».
Es por esto que al principio algunos tenían problemas con las horas, no indicaban el huso correspondiente con la hora que suministraban por tanto había un descuadre.
Pero si conservas juntas la información de la hora y del huso horario en el cual se lee esta hora, no habrá problema.

Ejemplo práctico: dentro de semana y media vamos a dormir una hora más por el fin del horario de verano. Entonces después de las 02:59:59 serán las 02:00:00 (en la península). Pero no es ningún problema si se conserva los husos horarios: después de las 02:59:59+02:00 serán las 02:00:00+01:00. Y es univoco. En horario UTc (él que usa la AEAT y nuestro ordenadores internamente), los relojes pasan de 00:59:59Z a 01:00:00Z; lógico y sin problema.
  #7  
Antiguo 18-10-2024
edari edari is offline
Miembro
 
Registrado: jun 2021
Posts: 340
Poder: 6
edari Va por buen camino
Cita:
Empezado por antoine0 Ver Mensaje
¿Dónde está el problema?
Si no sabes en qué huso horario estas o qué hora es porque se ha caído un servidor de tu entorno que normalmente te suministra la información, o la máquina que ha facturado no se recuerda de dónde está (GPS offline) o una cosa similar, entonces generas el hora de tu sistema (que se supone estará dentro de los márgenes) y lo apuntas el huso horario Z (GMT) o el huso local de tu sistema, dependiendo de si recuperas la hora UTc o la hora local, y la AEAT debe ser contenta (¡por eso sirven los husos horarios!)

La AEAT compara las fechas-horas en la escala UTc, es decir independientemente de los husos horarios y de su efecto sobre las horas «locales».
Es por esto que al principio algunos tenían problemas con las horas, no indicaban el huso correspondiente con la hora que suministraban por tanto había un descuadre.
Pero si conservas juntas la información de la hora y del huso horario en el cual se lee esta hora, no habrá problema.

Ejemplo práctico: dentro de semana y media vamos a dormir una hora más por el fin del horario de verano. Entonces después de las 02:59:59 serán las 02:00:00 (en la península). Pero no es ningún problema si se conserva los husos horarios: después de las 02:59:59+02:00 serán las 02:00:00+01:00. Y es univoco. En horario UTc (él que usa la AEAT y nuestro ordenadores internamente), los relojes pasan de 00:59:59Z a 01:00:00Z; lógico y sin problema.

En realidad me refería a la etiqueta FechaHoraHusoGenRegistro que mandamos en el fichero con la fecha de creación y que ya he podido comprobar en mis propias pruebas que si no cumple el margen de tiempo que estás obligado te devuelve el error

<tikR:CodigoErrorRegistro>2004</tikR:CodigoErrorRegistro>
<tikRescripcionErrorRegistro>El valor del campo FechaHoraHusoGenRegistro debe ser la fecha actual del sistema de la AEAT, admitiéndose un margen de error de: 120 segundos.</tikRescripcionErrorRegistro>

Mi duda en que si yo genero este valor a las 9:00 de hoy según estoy haciendo el envío y su servidor está out media hora, cuando vuelva a subir el fichero me dará este error o que se supone que habrá que hacer

A eso iba




  #8  
Antiguo 17-10-2024
edari edari is offline
Miembro
 
Registrado: jun 2021
Posts: 340
Poder: 6
edari Va por buen camino
Cita:
Empezado por jguarda Ver Mensaje
He buscado donde presentar la declaración responsable para comenzar a hacer pruebas, no he consguido encontrar donde entregar esto, alguien sabe donde se hace ?
Que yo sepa la declaración responsable no hace falta para hacer pruebas
Tema Cerrado



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 04:22:41.


Powered by vBulletin® Version 3.6.8
Copyright ©2000 - 2026, Jelsoft Enterprises Ltd.
Traducción al castellano por el equipo de moderadores del Club Delphi
Copyright 1996-2007 Club Delphi