Automatizar pagos con flujos

Todo lo que hace la pantalla de pago se basa en registros, así que Salesforce Flow también puede manejarlo. Una automatización puede crear una Pay Order y hacer que REDA Pay la procese en segundo plano, pagar a un propietario cuando se publica un estado de cuenta, enviar por correo un enlace de pago en cuanto se crea o avisar a finanzas cuando se devuelve un pago. Este artículo enumera los puntos de enganche que REDA Pay expone a los flujos y las reglas que necesita cada uno. No hace falta código; para Apex, consulta API de Apex para desarrolladores.

Enganche 1: Process Pay Order: cobrar una orden creada por una automatización

Una Pay Order guardada con la casilla Process Pay Order marcada la procesa REDA Pay en segundo plano, exactamente como si se hubiera pulsado Pay en pantalla. La orden debe estar completa y ser válida:

Guarda el registro; un proceso por lotes empieza en unos instantes y la orden recibe su Pay Transaction y su Processed Datetime. Si la orden ya está procesada, guardarla con la marca se rechaza con "Pay Order is already processed." Un fallo genera una transacción failed bajo la orden, como un pago fallido en pantalla. Las comisiones se calculan al guardar a partir de los Fee Setups de la cuenta, como en pantalla.

Marca una orden por operación. El procesamiento en segundo plano está diseñado para registros individuales: marca las órdenes de una en una (una entrevista de flujo, un registro), no de forma masiva desde una carga de datos. Marcar muchas órdenes en un solo guardado no se admite en esta versión.

Un patrón de flujo: un flujo desencadenado por registro sobre tu registro de facturación (una factura, un cargo, un estado de cuenta de propietario) que, cuando vence, obtiene el Pay Customer de la cuenta, obtiene el Default Pay Method del cliente, crea una Pay Order con los campos anteriores y define Process Pay Order como verdadero.

Enganche 2: Default Pay Method (Disbursement): saber adónde pagar

REDA Pay mantiene Default Pay Method (Disbursement) de la cuenta, el contacto y el prospecto alineado con el método predeterminado del Pay Customer siempre que el cliente admite desembolsos. Un flujo de pagos salientes lee esa búsqueda en la cuenta, comprueba que no esté vacía y la usa como Pay Method de la Pay Order. Los proveedores la completan ellos mismos mediante Solicitar datos bancarios a un proveedor.

Enganche 3: Attribute 1–4: llevar tu referencia

Las órdenes tienen cuatro campos de texto libre Attribute, que definen los ajustes del componente de pago, los parámetros de URL rpay__att1 a rpay__att4 y también tu flujo cuando crea la orden. Úsalos para llevar el número de factura, el contrato, la propiedad o el tipo de cargo, para que un flujo sobre la Pay Transaction resultante sepa qué se pagó.

Enganche 4: flujos desencadenados por registros de REDA Pay

Los registros cambian de formas previsibles; crea flujos sobre ellos:

Cuando un flujo lee Attribute 1–4 o la cuenta, el contacto y el prospecto relacionados de la orden, sabe para qué era el pago.

Enganche 5: la acción Update Payload Customer

Flow Builder ofrece una acción llamada Update Payload Customer (una acción de Apex del paquete REDA Pay). Pásale un Id de Pay Customer y envía a Payload el nombre, el correo y el teléfono actuales del cliente, y guarda el identificador de cliente de Payload si faltaba. El propio flujo de REDA Pay la llama cuando cambian los datos de un cliente; llámala desde tu flujo después de actualizar un Pay Customer mediante una automatización.

Los flujos propios de REDA Pay se pueden reemplazar

Los quince flujos de REDA Pay (valores predeterminados en órdenes nuevas, selección de comisiones, activación de enlaces, creación de clientes a partir de un registro principal, propagación del método predeterminado, notificaciones, las pantallas de revocación y de agregar métodos) están marcados como reemplazables. Un administrador puede desactivar uno y reemplazarlo por su propia versión, por ejemplo para enviar una notificación distinta. Hazlo solo cuando lo necesites; una actualización de REDA Pay no revierte tu reemplazo, así que debes conciliar tú mismo los cambios después de cada actualización.

Ejemplo práctico: pagar a los propietarios el día 5

Un administrador de propiedades paga a cada propietario sus ganancias netas el día 5 de cada mes.

1. Un flujo desencadenado por programación se ejecuta el día 5 sobre los registros Owner Statement con saldo positivo.
2. Para cada uno: obtiene la cuenta del propietario; se detiene si Default Pay Method (Disbursement) está vacío (y crea una tarea para solicitar los datos bancarios); obtiene el Pay Customer de la cuenta en el perfil.
3. Crea una Pay Order: Pay Profile, Pay Customer, Processing Account (la cuenta operativa), Pay Method (el método de desembolso predeterminado), Transfer Type Disbursement, Order Type Immediate, Principal Amount = saldo, Attribute 1 = el número de estado de cuenta, Process Pay Order = verdadero.
4. Un segundo flujo sobre Pay Transaction (Status processed, Type credit) marca el estado de cuenta como pagado usando Attribute 1.

Como hay desembolsos, el flujo se ejecuta como un usuario con la casilla REDA Pay - Enable Disbursements marcada.

Errores que debes evitar

Preguntas frecuentes

Qué sigue

• API de Apex para desarrolladores
• Enviar un desembolso