1
00:00:00,267 --> 00:00:03,133
Suena una alerta en la gráfica. Volteas a

2
00:00:03,133 --> 00:00:06,433
la cuenta y no aparece ninguna posición. No

3
00:00:06,433 --> 00:00:09,267
necesariamente hay un error: entre detectar una

4
00:00:09,267 --> 00:00:12,900
condición y registrar una operación existen varios

5
00:00:12,900 --> 00:00:13,733
pasos distintos.

6
00:00:14,933 --> 00:00:18,000
Continuamos el mapa de quién hace qué en

7
00:00:18,000 --> 00:00:21,200
tu pantalla. Ahora seguiremos los mensajes entre

8
00:00:21,200 --> 00:00:25,000
herramientas, usando ejemplos esquemáticos. No

9
00:00:25,000 --> 00:00:28,267
representan una interfaz oficial ni suponen que

10
00:00:28,267 --> 00:00:30,767
todas las plataformas se vean iguales.

11
00:00:32,100 --> 00:00:36,067
TradingView permite consultar gráficos y configurar

12
00:00:36,067 --> 00:00:39,567
alertas. Una condición es una regla que puede

13
00:00:39,567 --> 00:00:43,533
cumplirse, como alcanzar un nivel. Cuando se cumple,

14
00:00:43,933 --> 00:00:47,033
el aviso comunica ese hecho; por sí solo

15
00:00:47,333 --> 00:00:48,700
no acredita una ejecución.

16
00:00:49,667 --> 00:00:52,667
Paper Trading es un entorno simulado para practicar.

17
00:00:53,133 --> 00:00:56,533
Permite ensayar instrucciones y revisar registros

18
00:00:56,533 --> 00:00:59,800
sin confundirlos con una cuenta real. Que una

19
00:00:59,800 --> 00:01:02,433
práctica funcione no garantiza el mismo

20
00:01:02,433 --> 00:01:04,733
comportamiento fuera de la simulación.

21
00:01:05,667 --> 00:01:09,233
Tradovate cumple funciones de plataforma y broker.

22
00:01:10,000 --> 00:01:12,533
Para usar una conexión necesitas una cuenta

23
00:01:12,533 --> 00:01:16,600
compatible y conexiones autorizadas. Ver una gráfica

24
00:01:16,600 --> 00:01:19,500
no confirma que esa cuenta esté vinculada ni

25
00:01:19,500 --> 00:01:20,967
que sea el destino seleccionado.

26
00:01:22,433 --> 00:01:25,100
Lucid es una empresa de evaluación con reglas

27
00:01:25,100 --> 00:01:27,867
propias que pueden cambiar. Antes de usar una

28
00:01:27,867 --> 00:01:31,867
cuenta, consulta sus condiciones vigentes. Mencionar

29
00:01:31,867 --> 00:01:34,367
estas herramientas no implica una alianza,

30
00:01:34,633 --> 00:01:37,533
patrocinio ni compatibilidad automática entre ellas.

31
00:01:38,900 --> 00:01:43,033
Antes del ejemplo, fijemos el recorrido. El cálculo

32
00:01:43,033 --> 00:01:46,433
evalúa una condición; la alerta avisa; la

33
00:01:46,433 --> 00:01:49,733
instrucción expresa qué se solicita. Ninguno de esos

34
00:01:49,733 --> 00:01:52,567
tres pasos demuestra todavía que exista una posición

35
00:01:52,567 --> 00:01:53,133
en la cuenta.

36
00:01:54,300 --> 00:01:57,733
Después viene la aceptación: la orden fue admitida

37
00:01:57,733 --> 00:02:01,133
para su procesamiento. La ejecución ocurre cuando se

38
00:02:01,133 --> 00:02:04,567
concreta una cantidad. Finalmente, la posición

39
00:02:04,567 --> 00:02:08,600
registrada refleja lo ejecutado. Una orden aceptada

40
00:02:08,933 --> 00:02:10,767
todavía puede estar sin ejecutar.

41
00:02:11,700 --> 00:02:14,867
Nuestro caso será simulado y usará el contrato

42
00:02:14,867 --> 00:02:18,100
micro del Nasdaq del CME, que llamaremos eme,

43
00:02:18,100 --> 00:02:22,567
ene, cu. Partimos sin posición y planteamos comprar

44
00:02:22,567 --> 00:02:27,133
dos contratos. Primero revisamos entorno, conexión y

45
00:02:27,133 --> 00:02:28,067
cuenta de destino.

46
00:02:28,967 --> 00:02:31,500
El cálculo detecta que se cumple la condición

47
00:02:31,500 --> 00:02:35,433
elegida y aparece una alerta. Hasta aquí solamente

48
00:02:35,433 --> 00:02:38,967
hay información. La solicitud de compra sigue sin

49
00:02:38,967 --> 00:02:42,133
enviarse y la posición del ejemplo continúa en

50
00:02:42,133 --> 00:02:42,933
cero contratos.

51
00:02:44,067 --> 00:02:47,833
Revisamos instrumento, lado de compra, cantidad y

52
00:02:47,833 --> 00:02:51,500
destino antes de enviar. La instrucción solicita dos

53
00:02:51,500 --> 00:02:55,600
contratos en la cuenta simulada seleccionada. Ahora

54
00:02:55,600 --> 00:02:59,367
existe una solicitud enviada, pero todavía esperamos

55
00:02:59,367 --> 00:03:01,100
la respuesta sobre su aceptación.

56
00:03:02,133 --> 00:03:05,900
Llega primero la aceptación de la orden. Después,

57
00:03:06,533 --> 00:03:09,600
en este escenario, se confirma la ejecución de

58
00:03:09,600 --> 00:03:13,667
los dos contratos. Son mensajes diferentes y ocurren

59
00:03:13,667 --> 00:03:17,200
en ese orden; no convertimos el primero en

60
00:03:17,200 --> 00:03:18,067
prueba del segundo.

61
00:03:19,033 --> 00:03:22,567
El registro permite comprobar la secuencia: partimos

62
00:03:22,567 --> 00:03:25,100
de cero, se ejecutó una compra de dos

63
00:03:25,100 --> 00:03:28,200
contratos y quedó una posición compradora de dos.

64
00:03:29,467 --> 00:03:32,667
Guardamos esos estados, no solamente una imagen del

65
00:03:32,667 --> 00:03:33,267
aviso inicial.

66
00:03:34,300 --> 00:03:37,433
Abrimos un escenario separado: la alerta aparece,

67
00:03:37,867 --> 00:03:40,467
pero la conexión seleccionada no corresponde al

68
00:03:40,467 --> 00:03:43,500
destino previsto. No enviamos la instrucción.

69
00:03:44,233 --> 00:03:48,167
Revisamos entorno y cuenta; la gráfica visible no

70
00:03:48,167 --> 00:03:50,367
resuelve por sí sola esa discrepancia.

71
00:03:51,267 --> 00:03:56,133
En otro escenario separado, enviamos la solicitud y

72
00:03:56,133 --> 00:04:00,633
recibimos un rechazo. Esa respuesta no es aceptación

73
00:04:00,633 --> 00:04:04,800
ni ejecución. Leemos el motivo reportado antes de

74
00:04:04,800 --> 00:04:08,800
corregir algo; reenviar a ciegas no sustituye

75
00:04:08,800 --> 00:04:09,833
entender el problema.

76
00:04:11,067 --> 00:04:14,433
Un tercer escenario comienza nuevamente sin

77
00:04:14,433 --> 00:04:18,300
posición. Solicitamos dos contratos, la orden es

78
00:04:18,300 --> 00:04:22,100
aceptada y solamente se ejecuta uno. Eso se

79
00:04:22,100 --> 00:04:25,700
llama llenado parcial: la cantidad ejecutada es

80
00:04:25,700 --> 00:04:27,400
menor que la cantidad solicitada.

81
00:04:28,633 --> 00:04:32,200
En ese llenado parcial, el registro muestra una

82
00:04:32,200 --> 00:04:35,367
posición compradora de un contrato, no de dos.

83
00:04:36,167 --> 00:04:38,700
El contrato restante sigue pendiente en este

84
00:04:38,700 --> 00:04:42,800
ejemplo. Su estado debe consultarse; no lo contamos

85
00:04:42,800 --> 00:04:44,500
como ejecución futura segura.

86
00:04:45,433 --> 00:04:49,033
Nuevo ejercicio simulado: comenzaste sin posición,

87
00:04:49,667 --> 00:04:52,800
enviaste una compra de dos contratos y recibiste

88
00:04:52,800 --> 00:04:56,000
únicamente el mensaje de orden aceptada. No

89
00:04:56,000 --> 00:04:59,467
mostramos mensajes posteriores. Con esa información,

90
00:05:00,167 --> 00:05:02,500
¿qué puedes afirmar ahora sobre la posición?

91
00:05:09,800 --> 00:05:12,833
La respuesta es que falta confirmar la ejecución.

92
00:05:13,433 --> 00:05:16,733
Aceptada significa admitida, no necesariamente

93
00:05:16,733 --> 00:05:20,700
ejecutada. Tampoco hay evidencia de rechazo. Aunque

94
00:05:20,700 --> 00:05:23,633
después se ejecutaran los dos contratos, ese dato

95
00:05:23,633 --> 00:05:26,033
futuro no estaba disponible al decidir.

96
00:05:26,900 --> 00:05:30,533
Para aprender del recorrido, registra entorno y

97
00:05:30,533 --> 00:05:34,767
cuenta, instrumento y cantidad solicitada, mensajes

98
00:05:34,767 --> 00:05:39,433
recibidos y cantidad ejecutada. Agrega fecha y hora.

99
00:05:40,033 --> 00:05:43,033
Así puedes localizar dónde se detuvo el proceso

100
00:05:43,033 --> 00:05:44,667
sin depender de tu memoria.

101
00:05:45,667 --> 00:05:48,600
La pregunta práctica no es solamente si sonó

102
00:05:48,600 --> 00:05:51,233
una alerta, sino cuál fue el último estado

103
00:05:51,233 --> 00:05:55,333
confirmado. Revisa la solicitud, su respuesta, las

104
00:05:55,333 --> 00:05:59,000
ejecuciones y la posición registrada. Si algo no

105
00:05:59,000 --> 00:06:01,500
coincide, investiga antes de continuar.

106
00:06:02,833 --> 00:06:05,867
Tu siguiente práctica es reconstruir una operación

107
00:06:05,867 --> 00:06:08,600
simulada desde el aviso hasta el registro,

108
00:06:08,900 --> 00:06:11,967
incluyendo un caso sin envío. En la videoteca

109
00:06:11,967 --> 00:06:14,867
gratuita de T.A.P.A.M. puedes seguir aprendiendo

110
00:06:14,867 --> 00:06:18,900
desde cero. Consulta el siguiente paso en tapam.pro.
