GitLab

Cuando un CFDI no se cancelaba de manera inmediata se quedaba en estado pendiente de cancelar y
nunca cambiaba por errores en la lógica

La función `unlink_cfdi` trataba de optimizar una función que en la mayoría de los casos no es
requerida: borrar la relación entre un documento y su CFDI, por lo mismo se elimina para evitar que
se utilice en el código.

Closes #113

aun si el cfdi ya esta cancelado, esto por que aveces el cfdi se cancela pero la factura se queda
en pendiente por cancelar

close #111

aun si el cfdi ya esta cancelado, esto por que aveces el cfdi se cancela pero la factura se queda en
pendiente por cancelar

111

La función `action_consult_cancellation_status` regresaba una variable que no se tenía la certeza de
que siempre estuviera definida.

uuid no encontrado

se agrega sf_consult para consultar el estado del cfdi, y en la cancelacion se verifica que el
estatus sea 200(cancelada) o 211 (en proceso)

primero verificamos el estatus de cancelacion, despues el estatus del cfdi

se sigue el mismo patron que el timbrado y la cancelacion para mandar a
llamar la funcion que consulta el estado de cancelacion de un cfdi de
los pac.

se crean las funciones:
\t`action_consult_cancellation_status()`: que es la que se manda a llamar
para ver el estatus de cancelacion.
\t`consult_cancellation_status_sat()`:que es la que manda a
llamar la consulta con los pac configurados

se crea la funcion `consult_cfdi_cancellation_status()` que consulta el estatus de cancelacion del
cfdi relacionado al documento

feat(pac_answer): se crea clase `PacConsultAnswer` para homogenizar la respuesta de los pac en la co

se crean las funciones:
\t`consult_xpd_cfdi()`: para consultar el estado de un
cfdi
\t`cancel_xpd_cfdi()`: para cancelar un cfdi

cambia la logica en check_status_cancel

se crea la funcion undo_waiting_state(), si al verificar un cfdi en estado waiting y la cancelacion
es negada por el cliente, entonces regresa del estado waiting a done o signed