|
Duda envío RF cuando ha habido incidencia
Hola de nuevo.
Se me presenta la siguiente duda: Mi sistema permite generar facturas (y por tanto, sus correspondientes RF), aunque, p.e., no haya internet. El usuario genera 3 facturas y sus correspondientes RFs. Como no hay internet, los RFs no se envían. Cuando se restaura internet, genera otras 3 facturas+RF y se envían los 6 RFs. Como los 3 primeros RFs no se enviaron en su momento, hay que informar de incidencia (<Incidencia>S</Incidencia>), pero el resto en realidad no han tenido ningún tipo de incidencia. Entonces, todos van marcados como incidencia, o no los puedo enviar juntos? Yo entiendo que la incidencia debería informarse a nivel de registro, no de cabecera. O para variar, me estoy haciendo un lío? De hecho, en el SuministroInformacion.xsd habla de registro. Código:
<!-- Identificador que especifica si la generación del registro de facturación se ha realizado durante algún tipo de incidencia --> |
Cita:
*NOTA*: La marca de INCIDENCIA se calcula en el momento de enviar. Como el tiempo de espera entre paquetes por defecto es 60 sg. y el margen de envío para incidencia es de 240 sg. el segundo paquete saldrá sin incidencia. |
Cita:
Claro, yo también estoy calculando el estado "incidencia" en el momento del envio. Pero imagino que al leer el XSD de marras, leí lo de incidencia en el registro y me he encontrado con el problema a la hora de implementarlo. Haré como vosotros, total, tengo marcados los RFs que no se pudieron enviar en su momento. Gracias de nuevo. |
Cita:
Quiere decir que, aunque en principio no se envió el primer paquete, si se consiguen enviar antes de esos 240 sg., no se marca como incidencia el envío de dicho paquete? |
Cita:
Si tú al enviar un RF no puedes porque hay un corte de conexión, pero este se recupera en 45 sg. y lo vuelves a enviar, como no han pasado los 240, ese envío no irá con la marca de incidencia. |
La norma general es que se envian en el paquete, marcandoño como incidencia, los realmente afectados por incidencia, e inmediatamente puedes mandar los restantes no afectados en un paquete sin incidemcia, no hace falta esperar ñls 60 segundos desde el envio del paquete de incidencia hasta el siguiente que tengas acumulado si se han generado dentro del tiempo permitido.
Pero como digo, eso es la norma general, pero si lo envias todos junto en el mismo lote por incidencias puntuales, tampoco pasa nada, de hecho yo siempre barro lo quw quede pendiente y no tengo en cuenta despues de una incidencia cual está dentro de los 240 segundos para wnviarla en otro envio. Es una pregunta que ya formulé, y como tampoco está recogida la respuesta en el real decreto, como quieras |
Cita:
Precisamente en la reunión del pasado lunes, se comentó que unos de los principales errores que se está encontrando Hacienda en la actualidad es que los SIF no se esperan la demora que se les indica en la última respuesta que han dado al último envío del SIF. Y yo cambiaría eso de 'norma' por 'costumbre hoy en día'; eso de los 240 segundos lo pueden cambiar cuando quieran. Creo que incluso en el listado de errores, el mensaje de este error no especifica la cifra de segundos. |
Cita:
Te pongo un ejemplo: Tienes un registro pendiente de enviar, generado a las 13.00.00, cuando intentas enviar hay un corte de suministro de internet y reintentas reintentas hasta que se sale de tiempo y lo marcas como incidencia, a las 13.05.00 generas un segundo registro y sigue sin haber conexión, vuelve internet a las 13.08.05, envias el que tienes en incidencia, y aquí esta el kit de la cuestión, te esperas 60segundos para el que generaste a las 13.05.00 como comentas, o por el contrario lo envias inmediatamente. Como ves, si esperas, un registro que aún tenias dentro de tiempo, no estás cumpliendo, por un lado se deberian de enviar antes de que llegue el tiempo y por otro tienes que esperar. Como conocen ese "fallo" de diseño del control de flujos, pues te dejan un poco que decidas lo que quieras. |
Cita:
Y gracias al resto por los comentarios. Yo sí, o sí, voy a respetar lo de los 60 segundos entre envíos, bueno, o el tiempo que devuelva la respuesta. En cualquier caso, mucho trabajo para un único cliente:) Pero, y lo bien que lo estamos pasando;) Gracias nuevamente. |
Cita:
Pues yo estoy con Carlos, tienes que esperar los segundos correspondientes. Y mi respuesta también es con fundamento, me lo han dicho ellos. Se ve que a ti te han dicho una cosa y a mi la contraria :eek: En tu ejemplo, el segundo registro también iría como incidencia porque lo envías cuando ya han pasado los 240 segundos. |
En nuestro caso esperamos y el segundo saldrá con incidencia:
13:00:00 - Generar RF 1 - Intentar envío, sin intennet - Intentar envío, sin intennet - Intentar envío, sin intennet - ... 13:05:00 - Generar RF 2 - Intentar envío, sin intennet 13:08:05 - Vuelve internet 13:08:05 - Enviar RF 1 - (diff entre 13:00:00 y 13:08:00 > 240 sg. => con incidencia) - Esperar 60 sg. 13:09:05 - Enviar RF 2 - (diff entre 13:05:00 y 13:09:05 > 240 sg. => con incidencia) Pero tal vez en el segundo envío no haga falta esperar. Habría que probarlo... |
Cita:
|
Nostros hacemos eso también. Se lo hemos preguntado y nos lo han confirmado.
Pero seguramente si lo envíes al momento entre también correcto |
Pongo aquí la pregunta que hice y la respuesta que me dieron:
Cita:
Cita:
Me lo dejaron bien claro :) Luego les pregunté que pasaba si por el hecho de esperar 60 segundos esos registros "nuevos" se pasaban de los 240 segundos y me dijeron que había que enviarlos como incidencia (evidentemente) |
también pongo esa segunda pregunta y su respuesta:
Cita:
Cita:
|
La conclusion es que te van a validar cualquier metodo que uses para estos casos, tanto si lo envias juntos,separados(con nueva incidencia)... yo no me preocuparia, te contestan segun lo que expongas para no marearte mucho, de forma afirmativa.
Otra cosa es lo que expone Carlos, que en Febrero empiecen a banear a los que manden sin usar estrictamente el control de flujos principal por que estén saturados y elproblema es que si deciden cortar, no van a filtrar por que te has saltado el control de flujos aunque sea una situación atípica y fuera de la lógica del control definido. |
Cita:
Para que no te baneen en Febrero es mejor tenerlo como dicen. Y dicen que entre envío y envío hay que esperar x segundos. |
Cita:
Tu consulta a Verifactu te 'salvará' a ti cuando te pregunten (si lo hacen), a mi no, por tanto debo ceñirme a la normativa publicada, estas consultas no son vinculantes y son a un CallCenter, eso también se debe tener en cuenta. |
Cita:
|
Yo lo voy a mandar jutnos todos los que tenga, y os explico por que:
Si tienes una incidencia puntual y no puedes enviar, no tienea que estar reintentandolo un numero indefinido de veces dentro dr los 240 segundos. Con lo cual, en el 99,99999% de los casos, esos 2 registroa, una vez pasados los 60 segundos lo has podido ya intentar una o dos vecea y se pueden marcar como incidencia, os recuerdo que lo de los 240 segundos es algo interno, no publicado oficialmente y si yo detecto que no se puede enviar lo puedo marcar. Lo que puede daros lugar a confusion son los registroa que aun no han llegqdo al tiempo de espera de 60 segundos, esos sí hay que mandarlos en otro envio, insisto en que el resto, al menos, o podeis mandar en el mismo paquete No me bajo, lo siento |
| La franja horaria es GMT +2. Ahora son las 19:53:29. |
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