De la pantalla al registro de una operación

Suena una alerta en la gráfica. Volteas a la cuenta y no aparece ninguna posición. No necesariamente hay un error: entre detectar una condición y registrar una operación existen varios pasos distintos. Continuamos el mapa de quién hace qué en tu pantalla. Ahora seguiremos los mensajes entre herramientas, usando ejemplos esquemáticos. No representan una interfaz oficial ni suponen que todas las plataformas se vean iguales. TradingView permite consultar gráficos y configurar alertas. Una condición es una regla que puede

cumplirse, como alcanzar un nivel. Cuando se cumple, el aviso comunica ese hecho; por sí solo no acredita una ejecución. Paper Trading es un entorno simulado para practicar. Permite ensayar instrucciones y revisar registros sin confundirlos con una cuenta real. Que una práctica funcione no garantiza el mismo comportamiento fuera de la simulación. Tradovate cumple funciones de plataforma y broker. Para usar una conexión necesitas una cuenta compatible y conexiones autorizadas. Ver una gráfica no confirma que esa cuenta esté vinculada ni

que sea el destino seleccionado. Lucid es una empresa de evaluación con reglas propias que pueden cambiar. Antes de usar una cuenta, consulta sus condiciones vigentes. Mencionar estas herramientas no implica una alianza, patrocinio ni compatibilidad automática entre ellas. Antes del ejemplo, fijemos el recorrido. El cálculo evalúa una condición; la alerta avisa; la instrucción expresa qué se solicita. Ninguno de esos tres pasos demuestra todavía que exista una posición en la cuenta. Después viene la aceptación: la orden fue admitida

para su procesamiento. La ejecución ocurre cuando se concreta una cantidad. Finalmente, la posición registrada refleja lo ejecutado. Una orden aceptada todavía puede estar sin ejecutar. Nuestro caso será simulado y usará el contrato micro del Nasdaq del CME, que llamaremos eme, ene, cu. Partimos sin posición y planteamos comprar dos contratos. Primero revisamos entorno, conexión y cuenta de destino. El cálculo detecta que se cumple la condición elegida y aparece una alerta. Hasta aquí solamente hay información. La solicitud de compra sigue sin

enviarse y la posición del ejemplo continúa en cero contratos. Revisamos instrumento, lado de compra, cantidad y destino antes de enviar. La instrucción solicita dos contratos en la cuenta simulada seleccionada. Ahora existe una solicitud enviada, pero todavía esperamos la respuesta sobre su aceptación. Llega primero la aceptación de la orden. Después, en este escenario, se confirma la ejecución de los dos contratos. Son mensajes diferentes y ocurren en ese orden; no convertimos el primero en prueba del segundo.

El registro permite comprobar la secuencia: partimos de cero, se ejecutó una compra de dos contratos y quedó una posición compradora de dos. Guardamos esos estados, no solamente una imagen del aviso inicial. Abrimos un escenario separado: la alerta aparece, pero la conexión seleccionada no corresponde al destino previsto. No enviamos la instrucción. Revisamos entorno y cuenta; la gráfica visible no resuelve por sí sola esa discrepancia. En otro escenario separado, enviamos la solicitud y recibimos un rechazo. Esa respuesta no es aceptación

ni ejecución. Leemos el motivo reportado antes de corregir algo; reenviar a ciegas no sustituye entender el problema. Un tercer escenario comienza nuevamente sin posición. Solicitamos dos contratos, la orden es aceptada y solamente se ejecuta uno. Eso se llama llenado parcial: la cantidad ejecutada es menor que la cantidad solicitada. En ese llenado parcial, el registro muestra una posición compradora de un contrato, no de dos. El contrato restante sigue pendiente en este ejemplo. Su estado debe consultarse; no lo contamos

como ejecución futura segura. Nuevo ejercicio simulado: comenzaste sin posición, enviaste una compra de dos contratos y recibiste únicamente el mensaje de orden aceptada. No mostramos mensajes posteriores. Con esa información, ¿qué puedes afirmar ahora sobre la posición? La respuesta es que falta confirmar la ejecución. Aceptada significa admitida, no necesariamente ejecutada. Tampoco hay evidencia de rechazo. Aunque después se ejecutaran los dos contratos, ese dato futuro no estaba disponible al decidir. Para aprender del recorrido, registra entorno y

cuenta, instrumento y cantidad solicitada, mensajes recibidos y cantidad ejecutada. Agrega fecha y hora. Así puedes localizar dónde se detuvo el proceso sin depender de tu memoria. La pregunta práctica no es solamente si sonó una alerta, sino cuál fue el último estado confirmado. Revisa la solicitud, su respuesta, las ejecuciones y la posición registrada. Si algo no coincide, investiga antes de continuar. Tu siguiente práctica es reconstruir una operación simulada desde el aviso hasta el registro, incluyendo un caso sin envío. En la videoteca

gratuita de T.A.P.A.M. puedes seguir aprendiendo desde cero. Consulta el siguiente paso en tapam.pro.