Skip to content

test #1

@barspi

Description

@barspi

Background

Un CardProduct tiene 3 accounts: issuedAccount, feeAccount, externalAccount.

anda a impl

Desde el QI, al momento de crear un nuevo CardProduct, te pide rellenar esas cuentas, pero solo te deja elegir cuentas preexistentes (te pone un ! rojo si la cuenta no existe). Por eso, lo único lógico que podemos hacer es, elegir las cuentas de "received money" y "earned fees" del Issuer. (ver NOTA 1, al final) Entonces, finalmente terminan todos los CardProducts colgados e impactando la misma y única cuenta del Issuer... todo "amontonado".

Necesitamos

Para algunos clientes necesitamos que cada CardProduct tenga sus propias cuentas de issuedAccount (que vendría a ser el "received money") y de feeAccount ("earned fees") . NOTA 2

La lógica en los participants RESTAPI/Wallet ya parecen soportar eso (8583 y tarjetas también?), porque al momento de hacer las operaciones debit/credit, hay código tipo wallet.getCardProduct().getIssuedAccount() y wallet.getCardProduct().getFeeAccount(). (NOTA 3)

Implementar

En el QI, en la pantalla de /cardproducts/new: al momento de ingresar los account codes, si la cuenta no exisdte te avisa (como ahora), pero aparezca al lado un checkbox que diga [x] Create Account (o algo similar). Entonces cuando se le hace [save], ya se crean las cuentas correspondientes, y así tenemos unos CardProducts felices, cada uno con sus cuentas.

Bonus points:

Más sencillo todavía (para el usuario): Si se determina una nomenclatura estándar (NOTA 4) para las cuentas de un CardProduct, el checkbox de [x] Create Account debería limpiar y deshabilitar el TextField asociado, prellenando con esos valores precalculados, y las cuentas "issued" y "fees" se crearán usando esa nomenclatura estándar.

NOTA 1: Así como hay control de que las cuentas ingresadas existan, no hay ningún control de que pertenezca realmente al Issuer dueño del CardProduct que estamos creando...

NOTA 2: Constantino meciona que hasta podríamos necesitar más de una cuenta de fees para cada CardProduct, pero no compliquemos por ahora...

NOTA 3: tendría que debuguear bien caso por caso, para ver si aplica en todo lo que queremos, además aparecen agents y otras complejidades que no vamos a usar, pero tiene que ser todo coherente.

NOTA 4: Cuál podría ser la nomenclatura para una cuenta de un CardProduct? Supongamos que están bajo 11.001: Issuer 001. El CardProduct tiene un nombre de fantasía (que puede tener espacios y caracteres raros), y tiene un id autogenerado en la base que es impredecible y frágil.
No existe nada como CardProduct.code que en cuyo caso pongamos que fuera 1234, entonces se podrían crear las cuentas 11.001.1234.00 y 31.001.1234.00 para "received money" y "earned fees" respectivamente (edited)

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions