Control de riesgos y ciclo de vida de los pedidos.

Este capítulo le ayudará a comprender dos cosas: por qué a veces los pedidos «no se procesan»; y por qué, incluso después de haberlos terminado, a veces quedan «parcialmente terminados». La diferencia clave es entre rechazo de orden de control de riesgo y rechazo de contraorden: estos son los errores más comunes en la resolución de problemas en vivo.

Estimado usuario, «no operar» en el comercio simulado no siempre significa que la estrategia no esté enviando una señal. Podría ser que el control de riesgos local lo haya bloqueado, o podría ser que la correduría simulada no esté aceptando la orden. Explicaremos estos dos caminos por separado para que no piense erróneamente que el rechazo del control de riesgos significa que «la correduría no funciona correctamente».

0. 适用场景

Ahora puede ejecutar en vivo, pero necesita determinar exactamente qué sucedió en los casos «no vendidos/rechazados/cancelados».
Quiere vincular las indicaciones de la interfaz, los registros y el estado del pedido en una misma cadena explicable.

1. 核心概念：两条「拒单」路径

Muchos usuarios, cuando se encuentran con pedidos rechazados por primera vez, asumen que «todos han sido rechazados por las firmas de corretaje». En qteasy, primero aclare:

                    ┌─ 风控拒单：复核台打回，委托单未入库、未递柜台
策略信号 → 订单意图 ─┤
                    └─ 柜台受理拒单：已入库，券商同步回复「不收」，status=rejected
                              ↓（若受理成功）
                         异步成交回报 → partial-filled → filled

En el subsistema en vivo, una orden pasa por varias etapas desde la señal de estrategia hasta la ejecución final: RiskManager (opcional) → Creación de orden local → Procesamiento del corredor → Informe de ejecución. La siguiente tabla resume tres resultados posibles: al solucionar problemas, primero haga coincidir la categoría con la columna «Tipo», luego haga clic en «Primero verifique qué parte» para abrir el registro correspondiente.

Significados de las columnas: Tipo es el nombre de la ruta; Lo que verá es la característica de interfaz/valor de retorno; ¿Hay algún registro en la tabla de pedidos? indica si se ha agregado una nueva fila al sys_op_trade_orders local; Dónde comprobar primero es la primera prueba de la sugerencia.

Cómo utilizar: Cuando la CLI muestre «Pedido rechazado por regla de riesgo», seleccione la línea «Rechazo de riesgo» y marque «risk_log». Si la lista de pedidos contiene «rechazado» y ningún número de corredor, seleccione la línea «Contrarrechazo».

Tipo	¿Qué verás?	¿Hay algún registro en el formulario de pedido?	Dónde buscar primero
Rechazo de pedido por control de riesgos	motivo de rechazo de CLI (inglés); El resultado del envío está vacío `{}`	No hay líneas nuevas	`risk_log`、`<RISK REJECTED>`
Servicio de mostrador para pedidos rechazados	Hay una línea de orden con `status=rejected` y el número de corredor está vacío.	tener	Formulario de pedido, seguimiento
Solicitud exitosa	`submitted` etc., puede ir seguido de una transacción.	Sí, y normalmente tiene un `broker_order_id`.	Tabla de pedidos, trade_log

Para ver la tabla comparativa completa, consulte:doc:6-trader-snapshot-gate.

El RiskManager actúa como un panel de revisión antes de realizar un pedido: verifica el OrderIntent y el AccountSnapshot secuencialmente de acuerdo con la cadena de reglas que haya reunido (lista blanca, límite de transacción única, período de transacción, etc.); si alguna regla falla, genera una RiskDecision: un rechazo, acompañado de los ingleses reason y rule_id.

Si se aprueba, qteasy procederá a crear y verificar el pedido y lo enviará a la función submit_with_ack del Broker para ver si el mostrador lo acepta.

2. 风控如何工作（用户视角）

Antes de realizar una orden durante las operaciones en vivo, si ha configurado RiskManager para Trader:

Qteasy reúne instantáneas de cuentas basadas en el libro mayor actual
Envíe el «pedido a realizar» a la cadena de reglas para su evaluación.
Rechazo: las órdenes no se escriben en la tabla de órdenes y la orden no se ingresa en la cola de corretaje; Los rechazos en inglés se deben a que se escriben en el registro del sistema y en risk_log.
Aprobación: Continuar enviando como hasta ahora, sin control de riesgos.

Si no pasa RiskManager, se omitirá la cadena de reglas local y el proceso de creación y envío del pedido continuará directamente; el comportamiento se acerca más a la versión anterior.

2.1 Ejemplo de regla (para una comprensión más sencilla de los umbrales)

RiskManager evalúa la cadena de reglas antes de que un Trader envíe un pedido, como marcar elementos en una lista de verificación en un escritorio de revisión. La siguiente tabla enumera los tipos de reglas comunes y los resultados visibles para el usuario para ayudarlo a comprender rule_id y los motivos de rechazo; no es una lista completa de reglas integradas (las reglas las crea usted en Python).

El significado de cada columna: Escenario se refiere al contexto empresarial; Las reglas que usted establece se refieren a la semántica de las reglas; Qué pasará se refiere a la actuación en la sesión en vivo.

Cómo utilizar: Compare el risk_log o el rule_id (por ejemplo, MAX_ORDER_QTY) en el motivo de rechazo en inglés de la CLI para encontrar escenarios similares y luego ajuste el umbral o la lista blanca.

Ejemplo: Rechazo debido a MAX_ORDER_QTY → fila correspondiente «Cantidad de transacción única» → reduce el número de delegados o aumenta el límite de la regla.

Escena	Las reglas que estableces	lo que sucede
lista blanca	Sólo se permite `000001.SZ`.	Pedido realizado para `000300.SZ` → Rechazado, el registro indica que no está en la lista.
Número de transacciones por transacción	Máximo 500 acciones	Solicitud de compra de 501 acciones → Rechazada; 500 acciones y otras solicitudes aprobadas → Procedido
Horario de negociación	Sólo de 9:30 a 11:30 y de 13:00 a 15:00	Pedidos realizados durante la pausa del almuerzo → Rechazado
Volumen de transacciones diarias	Total acumulado diario + Esta transacción excede el límite	Rechazado; No excedido → Liberado

Método de ensamblaje: antes de crear Trader, construya RiskManager([Rule 1, Rule 2, ...]) en Python y páselo; de lo contrario, cierre la cadena de reglas local. Consulte :doc:2-configuration-and-run y el tutorial para obtener más detalles.

2.2 Ejemplo de motivo de rechazo en inglés visible para el usuario

CLI/TUI mostrará algo como:

Order rejected by risk rule [MAX_ORDER_QTY]: order quantity exceeds limit

Significado: Regla de control de riesgos MAX_ORDER_QTY indica que la cantidad ha excedido el límite. Busque en risk_log. Verifique los detalles.

3. 订单状态生命周期

Después de un procesamiento exitoso, el pedido pasará por estados típicos en Live (que puede ver en la CLI orders o en los registros):

submitted → partial-filled → filled

También es posible que:

submitted → canceled

Después de un procesamiento exitoso, el pedido pasará por varios estados en la sesión en vivo (visible a través de CLI orders o registros). Estos estados describen «dónde avanza la orden por parte del corredor», lo cual es diferente del rechazo de control de riesgo (donde la orden nunca se envió). La siguiente tabla cubre los estados más comunes; una enumeración completa está sujeta a la salida real durante el tiempo de ejecución.

El significado de cada columna: Estado es el nombre del estado en inglés; El significado es la semántica de inversión; A lo que debes prestar atención son a los puntos de control para investigación o confirmación.

Cómo utilizar: Si está atrapado en un determinado estado durante mucho tiempo → marque la línea «¿A qué debe prestar atención?» → si es necesario, vaya al script D/E:doc:5-artifacts-and-troubleshooting.

Estado	Significado	¿A qué deberías prestarle atención?
submitted	El mostrador ha recibido las órdenes, pero no se han completado todas las transacciones.	¿Tiene un `broker_order_id`?
partial-filled	Transacciones parciales completadas, volumen acumulado <volumen de pedido.	¿Está aumentando el volumen de operaciones acumulado?
filled	El volumen acumulado de transacciones alcanzó el volumen de pedidos.	¿Se han actualizado sus tenencias y saldos de efectivo?
canceled	Orden cancelada	Estado final tras el cierre del mercado o cancelación manual de la orden
Often `rejected`	Rechazo durante la etapa de servicio en mostrador	El número del corredor suele estar vacío; Esto no es un rechazo de una orden de control de riesgos.

Enfoque de investigación:

«No se enviaron envíos» → Primero verifique el control de riesgos y la verificación previa al envío (Tabla §1)
«Siempre parcialmente lleno» → Verifique si las devoluciones de transacciones llegan continuamente (§4)

4. 分批成交与全部成交

Cuando un pedido grande se divide en varias transacciones, el estado inicialmente permanecerá en parcialmente completado, como «Solo se ha completado una parte del pedido». Una vez que el volumen de transacciones acumuladas alcance la cantidad de pedido objetivo, Qteasy actualizará el estado a completado. Si ve un período prolongado de estado completado parcialmente, compare los datos de la transacción con la cantidad objetivo; a veces simplemente significa que las condiciones del mercado o la comparación de demostración aún no han completado el pedido completo.

5. 收盘后未成交订单

Después del cierre del mercado, qteasy utilizará la tarea post_close para cerrar todas las órdenes pendientes del día.

**submitted / partial-filled: Indica que la orden fue enviada al mostrador y el monto restante fue retirado al cierre. El estado final es **canceled (puede haber registros de transacciones de cancelación).
created: Esto se considera un borrador local de un pedido fallido (por ejemplo, un proceso de colocación de pedido interrumpido o un problema heredado). Está establecido en rejected al cierre de la negociación. No debe confundirse con los rechazos de pedidos intradía ni debe incluirse en los resultados de la transacción de cancelación.

Para usted: después del cierre del mercado, verifique los registros post_close y los resultados de conciliación reconcile para confirmar si las órdenes en tránsito se han cerrado de acuerdo con las reglas, sin tener que recordar los nombres de API internos.

6. 遇到异常时建议顺序

CLI/TUI Indicaciones instantáneas en inglés (Anote primero rule_id o su número de pedido)
risk_log: ¿Existe? (Ruta de control de riesgos)
Registros de pedidos y transacciones: secuencia de estado, si se reescribe broker_order_id.

Para obtener un árbol de decisiones más sistemático, consulte §3 de :doc:5-artifacts-and-troubleshooting.

7. 快速判定清单

¿Este pedido ha entrado en el proceso de envío (se puede encontrar en la tabla de pedidos o en los registros)?
Si no se envía: ¿Puedes encontrar rule_id / reason en risk_log o en la interfaz?
Si se envía: ¿Hay resultados de transacción correspondientes? ¿El estado es consistente con el monto acumulado?
¿Se distinguen claramente los tipos de rechazo de órdenes: Control de Riesgos (línea sin orden) vs. Contador (línea rechazada)?

8. 相关跳转

Configuración y ejecución: :doc:2-configuration-and-run
Manual de solución de problemas: :doc:5-artifacts-and-troubleshooting
Detalles de control de acceso y rechazo de pedidos: :doc:6-trader-snapshot-gate
Comando CLI: :doc:8-cli-trader-capability-matrix
Tutorial de ruta dual: tutorials/8-live-trade-risk-and-broker-walkthrough.md