# Guion del vídeo, para comentar o para lo que necesites.
# Es una PROYECCIÓN del nuestro: lleva el contenido —qué se dice, qué se ve, en
# qué orden y cuánto dura— y no la maquinaria que lo convierte en vídeo.
id: productos-acuerdo-de-pago
title: El acuerdo de liquidación, a fondo
audience: Desarrollador que va a crear sus acuerdos y necesita el detalle de cada campo
objetivo: >
  Al terminar, el espectador sabe qué declara un destino campo a campo, por qué `split` es un
  booleano y dónde va la distribución de verdad, y se lleva el requisito de diseño que más caro sale
  si se salta: guardar el `agreement_id`, porque no hay forma de recuperarlo ni de modificar un
  acuerdo.
cta: 'Siguiente: ''Split'', si vas a repartir, o ''Ciclo de vida de la sesión''.'
target_duration_s: 193
storyboard:
  - 'n': 1
    on_screen: Antes del primer pago
    narracion: >-
      Antes de recibir tu primer pago tienes que decidir una cosa: a dónde va a llegar el dinero.
      Eso es un destino, y en la API se llama acuerdo de liquidación. Es un juego de reglas que dice
      cómo recibes: a qué cuenta bancaria tuya se acredita, qué métodos de pago aceptas, y si lo que
      llegue ahí se reparte con otros.
    visual: 'Una pregunta sobre la mesa antes de cualquier código: a dónde llega el dinero.'
    duracion_s: 24
  - 'n': 2
    on_screen: Uno por cada forma de recibir
    narracion: >-
      Se define una vez y se reutiliza en muchas sesiones. Y puedes tener tantos como te hagan
      falta: un negocio con una sola cuenta tendrá uno; uno que separa ingresos por sucursal o por
      línea de producto, o que reparte con socios en unos casos y no en otros, tendrá varios. Uno
      por caso.
    visual: Un acuerdo y muchas sesiones colgando de él; al lado, varios acuerdos para casos distintos.
    duracion_s: 21
  - 'n': 3
    on_screen: Guarda el identificador
    visual: Lámina de sección, sin voz.
    duracion_s: 3
  - 'n': 4
    on_screen: No hay forma de recuperarlo
    narracion: >-
      Y antes de los campos, un requisito de diseño que si te saltas te quedas sin acuerdo. No
      existe ninguna operación para listar acuerdos ni para consultar uno: el contrato no declara
      ninguna ruta que lo haga. Tampoco hay listado de partners. La única entidad que se puede
      enumerar es la Parada.
    visual: El catálogo de rutas del contrato, con el hueco donde estaría un listado de acuerdos.
    duracion_s: 20
  - 'n': 5
    on_screen: Guárdalo al crearlo, junto al tuyo
    narracion: >-
      Así que guarda el identificador del acuerdo en tu sistema en el mismo momento en que lo creas,
      junto al identificador de tu lado: tu cliente, tu contrato, tu sucursal. Si lo pierdes, el
      único camino es crear otro. Y por lo mismo: modificar un acuerdo tampoco está disponible, así
      que si necesitas cambiar métodos o cuenta de destino, creas uno nuevo y eliges el que toca en
      cada sesión.
    visual: El identificador guardándose en el sistema propio en el mismo momento de crearse.
    duracion_s: 27
  - 'n': 6
    on_screen: Los campos
    visual: Lámina de sección, sin voz.
    duracion_s: 3
  - 'n': 7
    on_screen: Cuatro obligatorios
    narracion: >-
      Cuatro campos son obligatorios por contrato: el título, los métodos de pago, la cuenta
      bancaria por defecto y el reparto. Y de los métodos, ojo con un detalle que devuelve un
      cuatrocientos si lo saltas: son tres booleanos y los tres son obligatorios dentro del objeto,
      aunque los pongas en falso. Débito inmediato, cripto y pago móvil. Y aceptar cripto no cambia
      la moneda: la liquidación siempre ocurre en bolívares.
    visual: Los cuatro campos obligatorios del acuerdo, con los tres booleanos de métodos abiertos.
    duracion_s: 27
  - 'n': 8
    on_screen: '`split` es un booleano: solo habilita'
    narracion: >-
      Y sobre el reparto, la confusión más habitual de toda la API. En el acuerdo, el reparto es un
      booleano: solo habilita. Si está en falso, tú recibes el cien por cien. Si está en verdadero,
      permite reparto por sesión — pero la distribución concreta, quién recibe cuánto, no va aquí:
      va en el objeto de reparto de cada sesión de pago.
    visual: El campo split como un simple interruptor, sin ningún detalle de reparto dentro.
    duracion_s: 24
  - 'n': 9
    on_screen: Un reparto se arma en tres sitios
    narracion: >-
      De hecho, un reparto se arma en tres sitios distintos, y confundirlos es el error más
      habitual. En el acuerdo de recepción de cada receptor, que dice quién puede recibir y a qué
      cuenta. En tu acuerdo de liquidación con el reparto habilitado. Y en cada sesión de pago,
      donde dices quién recibe cuánto en esa transacción concreta.
    visual: >-
      Los tres sitios donde se arma un reparto: el acuerdo de recepción, el acuerdo con reparto
      habilitado, y la sesión.
    duracion_s: 22
  - 'n': 10
    on_screen: Cuántos destinos necesitas
    narracion: >-
      Y con eso puedes contar cuántos destinos necesitas: uno por cada combinación distinta de
      cuatro cosas. Si se reparte o no. Qué métodos aceptas. A qué cuenta llega. Y cómo se enruta
      según el banco del pagador — ese último con el campo de reglas, que el contrato marca En
      Desarrollo, así que déjalo para cuando esté.
    visual: Cierre de marca; las cuatro cosas que varían entre un destino y otro.
    duracion_s: 22