1.
When an order is created, the system will first verify the validity of the price. If the price is valid, the order will proceed to the "to_be_paid" status. If not, it will enter the "reviewing" stage.
2.
During the "reviewing" stage, our team will manually check the order. If we discover an alternative method for issuing the ticket, the order will be moved back to the "to_be_paid" status. Otherwise, it will be marked as "failed".
3.
While an order is in either the "reviewing" or "to_be_paid" status, users have the option to cancel the order. Once canceled, the order's status will be updated to "canceled".
4.
When an order reaches the "to_be_paid" status, a final payment deadline will be set. If this deadline is not met, the order will automatically transition to the "closed" status.
5.
During the "to_be_paid" status, users may proceed with payment. If the price remains valid, the order will move to the "proceeding" stage. However, if the price is invalid, the order will be marked as "failed".
6.
In the "proceeding" stage, once the ticket is successfully issued, the order's status will update to "issued". If the supplier is unable to issue the ticket, the order will shift to the "failed_reimbursing" status. After the refund process is completed, the order's status will finally update to "failed_reimbursed".
1.
Upon submission of a change request, a change order is promptly generated and transitions into the "chg_reviewing" phase.
2.
In the "chg_reviewing" phase, our supplier meticulously examines the order. If the change is deemed feasible, they assign the change fee, advancing the order to the "chg_to_be_paid" status. If not, the order is flagged as "chg_rejected".
3.
While the order is in either the "chg_reviewing" or "chg_to_be_paid" status, users have the flexibility to cancel the order. Cancellation updates the order's status to "canceled."
4.
Once an order attains the "chg_to_be_paid" status, a definitive payment deadline is established. Failure to meet this deadline automatically shifts the order to the "closed" status.
5.
During the "chg_to_be_paid" status, users may proceed with payment. If the price remains valid, the order seamlessly transitions to the "chg_proceeding" phase. Conversely, an invalid price marks the order as "failed."
6.
In the "chg_proceeding" phase, successful ticket issuance updates the order's status to "changed." If the supplier is unable to issue the ticket, the order shifts to the "failed_reimbursing" status. Upon completion of the refund process, the order's status is finally updated to "failed_reimbursed," marking the end of the process.
1.
Upon submission of a refund request, a refund order is instantly created and transitions to the "rfd_reviewing" phase.
2.
In the "rfd_reviewing" phase, our supplier thoroughly examines the order. If the refund is deemed viable, they assign the refund amount and move the order to the "rfd_to_be_confirm" status. If not, the order is labeled as "rfd_rejected".
3.
While the order is in either the "rfd_reviewing" or "rfd_to_be_confirm" status, users have the option to cancel the order. Cancellation updates the order's status to "canceled."
4.
Once an order reaches the "rfd_to_be_confirm" status, a specific confirmation deadline is set. Failure to meet this deadline automatically changes the order's status to "closed."
5.
During the "rfd_to_be_confirm" status, users may proceed with confirmation. If the refund fee remains valid, the order smoothly transitions to the "rfd_proceeding" phase. Conversely, results in the order being marked as "failed."
6.
In the "rfd_proceeding" phase, a successful refund ticket updates the order's status to "refunded_reimbursing." If the supplier is unable to process the refund, the order shifts to the "failed" status.
7.
In the "refunded_reimbursing" phase, upon the completion of the refund process, the order's status is updated to "refunded_reimbursed," indicating the end of the refund process.
