Tres agentes de Joule para aplicar cobros en SAP S/4HANA: un arquitecto ordena candidatos, espera a una persona y nunca compensa solo

En dos frases

Un arquitecto de SAP que construye agentes de Joule para clientes explica, con capturas y una larga lista de errores, cómo dividió la aplicación de cobros de S/4HANA en tres agentes que ordenan candidatos, esperan a una persona y se paran un paso antes de compensar. Es un relato de diseño detallado y de primera mano, no un resultado medido: no nombra a ningún cliente, las opiniones están parafraseadas y la empresa del autor vende este tipo de trabajo.

Por qué importa este caso

Aplicar cobros es la tarea menos vistosa de cuentas a cobrar y una de las que más consecuencias tiene. Un cobro imputado al cliente equivocado acaba en una carta de reclamación injusta, un bloqueo de crédito, una llamada tensa y una conciliación de la que nadie se fía el viernes. Casi todos los equipos tienen ya reglas de emparejamiento y, si trabajan con SAP, muchas veces SAP Cash Application, que aprende de lo que los contables emparejaron antes y propone o compensa solo por encima de un umbral. Lo que queda es el residuo: cobros con avisos de pago desordenados, sin número de cliente e importes parciales.

En ese residuo la IA generativa tienta y asusta a la vez, porque un modelo de lenguaje lee bien un concepto de transferencia escrito como una lista de la compra y admite mal que no sabe. El caso sirve porque el autor empezó por la versión peligrosa (una puntuación de confianza y aplicación automática por encima del 90 %), vio cómo una responsable de cuentas a cobrar la desmontaba con una sola pregunta y la rehízo con la idea contraria. Además, hay pocos relatos tan detallados de un agente a medida de Joule Studio para finanzas, y llega cuando SAP vende con fuerza la «empresa autónoma» (en SAP Connect, el 6 de octubre de 2026, Nestlé dijo que su Accounts Receivable Assistant prioriza los cobros pendientes).

Quién lo hace

Satyavir Singh firma como arquitecto principal de SAP Business AI, Joule y SAP BTP, y dice que todo lo que cuenta sale de trabajos con clientes reales. Su perfil público de LinkedIn indica que trabaja en Wipro, cuyo equipo ha publicado agentes de Joule en SAP Discovery Center. El artículo no menciona a Wipro, no nombra a ningún cliente y no da volúmenes. Léelo, por tanto, como el patrón de un implantador: está bien situado para saber qué se rompió en las pruebas de aceptación, y tiene un motivo comercial para presentar bien el diseño.

Herramientas y arquitectura

Todo es SAP a propósito. Joule es la ventana de conversación; en Joule Studio, dentro de SAP Build, se definen cada agente, sus skills, límites y prompts; SAP BTP aporta la ejecución, la identidad y la extensibilidad; el Generative AI Hub de SAP AI Core sirve los modelos; y S/4HANA Finance es la única fuente de verdad de interlocutores, datos bancarios, partidas abiertas, preregistro, contabilización y compensación. El autor dejó fuera las herramientas de terceros porque los clientes de finanzas quieren saber adónde van sus datos y quedarse dentro de SAP acortó las conversaciones con seguridad, auditoría e informática.

La descripción oficial del constructor de agentes explica por qué es posible: cada agente tiene un nombre y una descripción con los que Joule decide a quién enviar cada petición, un bloque de experiencia e instrucciones, y herramientas que pueden ser skills de Joule (pasos deterministas), grupos de documentos para fundamentar respuestas, servidores MCP, una calculadora u otros agentes como subagentes. Los agentes se ejecutan con propagación de identidad, de modo que los permisos de SAP del usuario se aplican a cada llamada, y SAP dice que la supervisión humana viene activada por defecto en las decisiones críticas.

Los tres agentes, paso a paso

1. Identificación: ordenar, explicar y esperar

El primer agente empieza por la lista de problemas: líneas del extracto bancario sin cliente resuelto. Al abrir una, junta en una sola tarjeta los datos del banco, la fecha, el importe y el concepto, lo que ahorra saltar entre varias aplicaciones Fiori. Después lee el aviso de pago, extrae posibles referencias y las cruza con los datos maestros de interlocutores, y enseña una lista ordenada en la que cada candidato se puede rastrear hasta algo del texto o del maestro. Si un emparejamiento no se puede justificar, no aparece. Al lado propone qué hacer después, por ejemplo avisar al equipo de datos maestros de una regla, algo que añadió tras oír «vale, ¿y ahora qué?» en una demo.

No se escribe nada hasta que el usuario elige el cliente y confirma. Después, el sistema vuelve a validar el interlocutor, y en las pruebas eso cazó clientes con un bloqueo o un estado que el usuario no había visto. Solo entonces el agente llama a la acción que actualiza el cobro, y da el éxito por bueno cuando S/4HANA lo devuelve, no cuando se envió la llamada.

2. Preregistrar o contabilizar: preguntar antes a SAP

El segundo agente existe para evitar el desastre clásico: una contabilización duplicada porque el agente no se dio cuenta de que el primer intento había funcionado. Antes de nada lee en SAP el estado de contabilización en vivo. Si un preregistro anterior falló, dice por qué; si ya existe un documento, lo dice. Luego propone preregistrar con valores concretos, contabilizar o retener con un motivo, explica el plan en lenguaje llano y solo llama a la acción tras la confirmación. Éxito significa un número de documento devuelto por SAP.

Hay una decisión que el autor defiende por encima de todas: para preregistrar y contabilizar usó las acciones validadas de SAP, no llamadas OData propias envueltas en una skill a medida. Un compañero quería más control sobre los mensajes de error; el autor respondió que el código propio que escribe en finanzas es deuda de gobierno, porque hay que mantenerlo en cada cambio de la API y explicárselo a cada auditor.

3. Cruce a tres bandas: un veredicto, no un botón

Los usuarios le pidieron que el tercer agente compensara solo y el autor se negó. El agente confirma el cliente, enseña su situación financiera, trae de SAP las facturas y los cobros abiertos, incorpora el aviso de pago y la confirmación bancaria, calcula totales, descuentos por pronto pago y diferencias (cada cifra se puede rastrear hasta SAP) y lista los bloqueos sin rodeos, como un pago parcial o una factura con una reclamación en una línea, cada uno con un siguiente paso concreto. Después devuelve uno de tres veredictos, completado, listo para compensar o no listo, y se para. Compensar sigue siendo una decisión de negocio.

Lo que hizo que funcionara

Tres lecciones de implantación valen más que las capturas. Primera: las descripciones de las skills son prompts; una frase vaga hacía que Joule llamara a la skill de contexto del cobro para preguntas de conciliación, y reescribirla con entradas, salidas y una condición exacta de uso limpió el enrutado. Segunda: fundamentar con una lista corta; pasarle al modelo un bloque enorme de interlocutores provocó números de cliente inventados en producción, así que la búsqueda pasó a ser un recurso del sistema y el modelo solo ordena y explica lo que el sistema ya filtró. Tercera: el contexto de sesión; cuando cada agente volvía a resolver el cliente a partir del último mensaje, el identificador a veces se desviaba (su ejemplo: el 100234 convertido en 100324), así que el cliente, el cobro y el documento confirmados se fijan una vez y se heredan. También separó modelos por tarea, uno potente para el texto de los avisos de pago y otro más pequeño y rápido para enrutar y resumir, lo que según él redujo bastante los tiempos de respuesta y el coste.

Cópialo y adáptalo

El autor no publicó configuración, prompts ni código, así que todo lo que sigue es nuestro, escrito a partir de su descripción y del formato público de los ejemplos de SAP. Adapta los nombres a tu sistema y mantén los controles humanos. El código va en inglés, como en la versión inglesa.

Requisitos previos

• SAP S/4HANA Finance con tratamiento de extractos bancarios y gestión de partidas abiertas; mejor si SAP Cash Application ya resuelve los emparejamientos fáciles.
• Joule desplegado y Joule Studio disponible; según SAP, lo tienen los clientes con Joule (AI Units de pago o el SKU gratuito Joule Base) y un acuerdo BTPEA, CPEA o pago por uso.
• Identidad configurada con SAP Cloud Identity Services, para que la propagación aplique los permisos de cuentas a cobrar del propio usuario.
• Una persona responsable de cuentas a cobrar que participe en las pruebas y sepa decir que no.

1. El formato que usa SAP para definir un agente (ejemplo oficial, Apache-2.0)

El repositorio de ejemplos de SAP documenta los agentes creados en el constructor de Joule Studio con descripción, experiencia, instrucciones, contexto adicional, configuración del modelo, pasos de ejecución, herramientas y salida. Este fragmento breve del Escalation Assistant muestra cómo redacta SAP una regla de supervisión humana (todo borrador de correo se enseña al usuario para que lo apruebe antes de enviarlo):

- Every e-mail message you draft must be presented to the end-user for approval before sending it to the customer: the user can provide feedback on the contents of the message until its finally approved.

Fuente: SAP-samples/btp-agentic-ai-use-cases, ESCALATION_ASSISTANT.md, commit 421ad2f. Copyright 2026 SAP SE or an SAP affiliate company and btp-agentic-ai-use-cases contributors, con licencia Apache-2.0.

2. Definiciones de los tres agentes (plantilla de Agents Finance basada en el diseño de Satyavir Singh)

# Agent: Payment Identification Assistant
## Description
Finds incoming bank payments with no identified customer in S/4HANA, shows a ranked
shortlist of Business Partners with evidence, and updates the payment only after the
user confirms one candidate and the backend validation passes.

## Expertise
You are an accounts receivable specialist for cash application in SAP S/4HANA.
You read remittance text and explain matches. You never decide on your own.

## Instructions
1. List unidentified payments using the "Get Unidentified Payments" skill.
2. For the chosen payment, call "Get Payment Context" once and show bank, date,
   amount, currency and remittance text in one card.
3. Call "Get BP Candidates" with the extracted references. Rank only the candidates
   it returns. For each, show the evidence (reference found, amount match, name).
   If there is no evidence, say "no candidate" and suggest a master data follow-up.
4. Ask the user to pick a candidate. Wait. Never pick for the user.
5. Call "Validate Business Partner". If it reports a block or status, stop and say so.
6. Call the standard update action. Report success only if SAP returns success.
7. Store payment_id and bp_id in session context and hand over to the
   Parking and Posting Agent.

## Never
- Apply a payment above any confidence score.
- Show a Business Partner number that did not come from a skill result.
- Re-resolve a customer already confirmed in this session.

# Agent: Parking and Posting Agent
## Description
For a payment whose customer is confirmed in session context, reads the live posting
status, proposes park, post or hold with values, and calls the SAP-validated action
only after the user confirms.

## Instructions
1. Read payment_id and bp_id from session context. Do not ask the model to infer them.
2. Call "Get Posting Status" before anything else. If a document exists, report its
   number and stop. If an earlier park failed, show the SAP message.
3. Propose exactly one of: PARK (with values), POST (with values), HOLD (with reason).
4. Show the plan in plain language and ask for confirmation. Wait.
5. Call the SAP-validated park or post action. Success = a document number from SAP.
6. Store document_no in session context and hand over to the Reconciliation Agent.

## Never
- Retry a failed or uncertain action without reading the status again.
- Use a custom write skill when a validated SAP action exists.

# Agent: Three-Way Match Readiness Agent
## Description
For a confirmed customer, compares open invoices, open payments and remittance from
S/4HANA and returns COMPLETED, READY_FOR_CLEARING or NOT_READY_FOR_CLEARING with
blockers. It never clears.

## Instructions
1. Read bp_id, payment_id and document_no from session context.
2. Show the customer overview (balance, overdue, disputes) first.
3. Pull open invoices and open payments with skills; take remittance and bank
   confirmation from SAP, never from a spreadsheet.
4. Compute totals, cash discounts and differences with the calculator tool. Every
   figure must cite the SAP document it comes from.
5. List each blocker with a concrete next step, e.g. "invoice X has a dispute on
   line 3: resolve or exclude before clearing".
6. Return the verdict and stop. Clearing is done by a person in SAP.

3. Descripciones de skills como reglas de enrutado (plantilla de Agents Finance)

La lección del autor llevada a la práctica: una descripción vaga frente a otra que dice cuándo usarla, con qué entradas y qué devuelve.

# Too vague: Joule also picked it for reconciliation questions
- name: Get Payment Context
  description: Gets payment information.

# Routing rule: when, with what, returning what, and when not
- name: Get Payment Context
  description: >-
    Use only when a bank payment ID is known and its posting status has not yet
    been retrieved in this session. Input: payment_id. Returns bank account, value
    date, amount, currency, payer name and remittance text for that one payment.
    Do not use for open items, customer balances or reconciliation.
- name: Get BP Candidates
  description: >-
    Use after Get Payment Context, to shortlist Business Partners for one payment.
    Input: payment_id and extracted references (document numbers, names, customer
    numbers). Returns at most 5 Business Partners filtered by the backend, each with
    the evidence that matched. The model may rank these only; never add others.
- name: Get Posting Status
  description: >-
    Use before any park, post or hold proposal. Input: payment_id. Returns the live
    status in S/4HANA: no document, parked (document number), posted (document
    number) or failed (SAP message). Never use cached results.

4. Contexto de sesión que pasa de un agente a otro (plantilla de Agents Finance)

Los campos fijados tras una confirmación humana son de solo lectura para los agentes siguientes.

{
  "session_id": "AR-2026-10-27-0142",
  "confirmed_by": "user-id-from-identity-service",
  "payment_id": "BNK-0001",
  "bp_id": "100234",
  "bp_confirmed_at": "2026-10-27T09:14:05Z",
  "bp_validation": "passed",
  "document_no": null,
  "posting_status": "not_posted",
  "rule": "Fields set after a human confirmation are read-only for every later agent."
}

5. Comprobaciones deterministas junto a los agentes (plantilla de Agents Finance, MIT-0)

Un script para ejecutar sobre exportaciones CSV durante el piloto: prepara la lista corta de candidatos con sus pruebas, que es lo que debería ver el agente de identificación, y calcula por su cuenta el veredicto del cruce a tres bandas, para comparar la respuesta del agente con una determinista. Nunca contabiliza ni compensa.

#!/usr/bin/env python3
# Agents Finance template based on Satyavir Singh's cash application design
# (SAP Community, 28 Jul 2026). Licence: MIT-0. Not SAP code. Read-only:
# it never posts, parks or clears anything; it only prepares evidence.
"""Two deterministic checks to run beside a cash application agent.

candidates: shortlist Business Partners for each unidentified bank payment,
            with the evidence behind each candidate (the LLM ranks only this).
match:      three-way match (open invoices, open payments, remittance) for a
            customer a human has already confirmed. Returns a verdict:
            COMPLETED, READY_FOR_CLEARING or NOT_READY_FOR_CLEARING.
Inputs are CSV exports (for example from S/4HANA open-item and bank-statement
reports). Amounts use a dot as decimal separator.
"""
import argparse, csv, json, re, sys
from decimal import Decimal
from difflib import SequenceMatcher

def read(path):
    with open(path, newline="", encoding="utf-8") as f:
        return list(csv.DictReader(f))

def dec(x):
    return Decimal((x or "0").strip() or "0")

def norm(s):
    return re.sub(r"[^a-z0-9 ]", " ", (s or "").lower()).split()

def candidates(args):
    payments, bps, items = read(args.payments), read(args.partners), read(args.open_items)
    out = []
    for p in payments:
        text = " ".join([p.get("payer_name", ""), p.get("remittance_text", "")])
        tokens, amount = set(norm(text)), dec(p["amount"])
        found = []
        for bp in bps:
            ev, score = [], 0
            if bp["bp_id"] in tokens:
                ev.append("BP number in remittance text"); score += 50
            for d in [i for i in items if i["bp_id"] == bp["bp_id"]]:
                if d["doc_no"] in tokens or (d.get("reference") and d["reference"].lower() in tokens):
                    ev.append(f"open item {d['doc_no']} quoted in text"); score += 40
                if dec(d["amount"]) == amount:
                    ev.append(f"amount equals open item {d['doc_no']}"); score += 20
            names = [bp["name"]] + [a for a in bp.get("aliases", "").split("|") if a]
            sim = max(SequenceMatcher(None, " ".join(norm(n)), " ".join(norm(p.get("payer_name", "")))).ratio() for n in names)
            if sim >= 0.8:
                ev.append(f"payer name similar to '{bp['name']}' ({sim:.2f})"); score += int(sim * 20)
            if ev:
                warn = ["BP is BLOCKED: do not apply without the master data team"] if bp.get("blocked", "").lower() in ("x", "yes", "true", "1") else []
                found.append({"bp_id": bp["bp_id"], "name": bp["name"], "score": score, "evidence": ev, "warnings": warn})
        found.sort(key=lambda c: -c["score"])
        out.append({"payment_id": p["payment_id"], "amount": str(amount), "candidates": found[: args.top],
                    "note": "no candidate with evidence: leave unidentified" if not found else "human must pick and confirm"})
    json.dump(out, sys.stdout, indent=2); print()

def match(args):
    inv = [i for i in read(args.invoices) if i["bp_id"] == args.bp]
    pay = [p for p in read(args.open_payments) if p["bp_id"] == args.bp]
    rem = [r for r in read(args.remittance) if r["payment_id"] in {p["payment_id"] for p in pay}]
    tol, blockers = dec(args.tolerance), []
    if not inv and not pay:
        print(json.dumps({"bp_id": args.bp, "verdict": "COMPLETED", "blockers": []}, indent=2)); return
    open_docs = {i["doc_no"]: i for i in inv}
    for r in rem:
        d = open_docs.get(r["doc_no"])
        if d is None:
            blockers.append(f"remittance cites {r['doc_no']}, which is not an open invoice of {args.bp}")
            continue
        if d.get("dispute", "").lower() in ("x", "yes", "true", "1"):
            blockers.append(f"invoice {r['doc_no']} has an open dispute: resolve or exclude before clearing")
        due = dec(d["amount"]) - dec(r.get("discount"))
        if abs(due - dec(r["amount_paid"])) > tol:
            blockers.append(f"invoice {r['doc_no']}: paid {r['amount_paid']} vs {due} due after discount (partial or short payment)")
    paid = sum(dec(p["amount"]) for p in pay)
    applied = sum(dec(r["amount_paid"]) for r in rem)
    if abs(paid - applied) > tol:
        blockers.append(f"payments {paid} vs remittance lines {applied}: {paid - applied} unexplained")
    verdict = "NOT_READY_FOR_CLEARING" if blockers else "READY_FOR_CLEARING"
    print(json.dumps({"bp_id": args.bp, "verdict": verdict, "payments_total": str(paid),
                      "remittance_total": str(applied), "blockers": blockers,
                      "next": "a person clears in SAP; this script never clears"}, indent=2))

ap = argparse.ArgumentParser(description=__doc__, formatter_class=argparse.RawDescriptionHelpFormatter)
sub = ap.add_subparsers(required=True)
c = sub.add_parser("candidates"); c.set_defaults(fn=candidates)
c.add_argument("--payments", required=True); c.add_argument("--partners", required=True)
c.add_argument("--open-items", required=True); c.add_argument("--top", type=int, default=5)
m = sub.add_parser("match"); m.set_defaults(fn=match)
m.add_argument("--bp", required=True); m.add_argument("--invoices", required=True)
m.add_argument("--open-payments", required=True); m.add_argument("--remittance", required=True)
m.add_argument("--tolerance", default="0.00")
a = ap.parse_args(); a.fn(a)

Ficheros de entrada (datos ficticios) y cómo ejecutarlo:

payment_id,amount,currency,value_date,payer_name,remittance_text
BNK-0001,1180.00,EUR,2026-10-05,ACME IBERICA SL,PAGO FRA 90001234 Y 90001240
BNK-0003,2400.00,EUR,2026-10-06,NORTHWIND TRADING,INV 90001301 cust 100324

bp_id,doc_no,amount,due_date,reference,dispute
100234,90001234,700.00,2026-10-01,PO-77,
100234,90001240,500.00,2026-10-10,PO-78,x
100324,90001301,2400.00,2026-10-03,,

python3 cash_app_checks.py candidates --payments bank_payments.csv \
  --partners partners.csv --open-items open_items.csv
python3 cash_app_checks.py match --bp 100234 --invoices open_items.csv \
  --open-payments open_payments.csv --remittance remittance.csv --tolerance 0.00

6. Plan de pruebas antes de que lo vea ningún usuario (plantilla de Agents Finance)

Cada caso debe acabar con el comportamiento indicado tras la flecha.

UAT — cash application agents (each case must end with the expected behaviour)
[ ] Confident and wrong: remittance names customer A, the amount matches customer B
    -> both shown with their evidence, nothing applied
[ ] No evidence at all ("thanks for everything") -> "no candidate", master data follow-up
[ ] Blocked Business Partner chosen by the user -> backend validation stops the update
[ ] Earlier park failed -> agent shows the SAP message and does not retry blindly
[ ] Document already posted -> agent reports the number, proposes nothing
[ ] Timeout on the update call -> agent re-reads status before any new attempt
[ ] Customer number drift (100234 vs 100324) -> later agents read session context
[ ] Partial payment and cash discount -> NOT_READY with the exact difference
[ ] Invoice with an open dispute -> NOT_READY, "resolve or exclude" next step
[ ] User without clearing authorisation -> principal propagation blocks the action
[ ] Every figure in the summary opens the SAP document it came from

Un ejemplo concreto (ficticio)

Llega una transferencia de 1.180,00 € de «ACME IBERICA SL» con el concepto «PAGO FRA 90001234 Y 90001240». El agente de identificación enseña un candidato, el interlocutor 100234, con tres pruebas: los dos números de factura aparecen en el texto y el nombre del pagador coincide. La técnica de cuentas a cobrar lo confirma, la validación del sistema pasa y S/4HANA actualiza el cobro. El agente de contabilización lee el estado, no encuentra documento, propone contabilizar y, tras la confirmación, devuelve el número de documento de SAP. El agente de cruce descubre entonces que la factura 90001234 (700,00 €) se pagó con 14,00 € de descuento por pronto pago, pero que la 90001240 (500,00 €) recibió 494,00 € y tiene una reclamación abierta. Veredicto: no lista para compensar, con dos bloqueos y dos siguientes pasos. La técnica llama al cliente; no se ha compensado nada a ojo.

Resultados que declara la fuente

El autor parafrasea a sus clientes: los cobros ya no se aplican mal desde el origen, se acabaron las contabilizaciones duplicadas gracias a la consulta del estado en vivo, la conciliación pasó de las hojas de cálculo del viernes a las cifras de SAP, el director financiero se fía del saldo de caja del día y las auditorías son más tranquilas porque cada acción tiene una confirmación de usuario y un número de documento de SAP. La única medición que cita es que las excepciones se resuelven ahora en horas y no en días, medido por un cliente durante seis semanas. No da punto de partida, volúmenes, porcentajes de acierto ni costes, y nada de esto lo ha comprobado un tercero.

Limitaciones y riesgos

• Clientes sin nombre e interés comercial. No hemos podido verificar ninguna implantación. La empresa del autor construye agentes de Joule, y el artículo funciona como escaparate.
• Coste. Los agentes propios de Joule Studio se pagan por consumo a través de los acuerdos de BTP (cómputo, memoria, ejecución de flujos y tokens), y los agentes estándar de Joule consumen AI Units por acción. SAP no publica el precio de la AI Unit, así que con información pública no se puede estimar el coste por cobro.
• Solapamiento con lo que quizá ya tienes. SAP Cash Application y el agente estándar Receivables and Payables Clearing Agent ya proponen emparejamientos y compensaciones. Un agente a medida tiene sentido para el residuo que dejan, no como sustituto.
• Fatiga de confirmación. El diseño depende de que la gente lea lo que confirma. Con una cola larga, el botón de confirmar se convierte en un sello de goma; mide cuántas veces el usuario descarta el primer candidato.
• El modelo sigue leyendo texto libre. La lista corta que filtra el sistema evita interlocutores inventados, pero la extracción de referencias del aviso de pago puede fallar o leer mal; lo que te protege es la columna de pruebas.

Errores comunes

• Construir primero un agente y pensar después en los traspasos; el autor insiste en diseñar el ciclo antes de dividirlo.
• Aplicar automáticamente por encima de un umbral de confianza: el emparejamiento seguro y equivocado es el caso caro.
• Darle al modelo todo el maestro de clientes en vez de una lista corta filtrada.
• Escribir en finanzas con skills propias cuando existe una acción validada de SAP.
• Dejar que cada agente vuelva a identificar al cliente a partir del último mensaje.
• Dar por buena una llamada a la API enviada en vez de esperar al número de documento de SAP.
• Conciliar contra un libro exportado en lugar de contra las partidas abiertas en vivo.

Conclusiones

No es la historia de un agente que compensa cuentas a cobrar solo; es justo lo contrario, y por eso merece la pena. Lo útil se puede llevar a cualquier ERP: el sistema filtra y el modelo explica, cada cambio espera a una persona, el éxito es lo que dice el sistema contable, lo ya confirmado no se vuelve a deducir y el último paso da un veredicto en vez de pulsar el botón. Si trabajas con SAP, empieza donde termina Cash Application y dale a tu responsable de cuentas a cobrar el plan de pruebas de arriba. Si no, el mismo patrón funciona con un conector MCP y el script de esta entrada. En ambos casos, pide las mediciones que el artículo no da: cuántas veces se descarta el primer candidato, la antigüedad de las excepciones y las contabilizaciones duplicadas antes y después.