| Version objetivo | DIMO EMPRESA - inicio |
| Funcionalidad | DimoEmpresa |
| Estado del documento |
|
| Elaborado por | Hugo Diaz |
| Analistas | Arturo Sosa |
| Solicitantes | Juan Almada |
| Fecha |
|
Objetivos
Desarrollar un Backoffice DIMO EMPRESAS que permita procesar transacciones de pagos de salarios, desembolsos, pago de servicios, transferencias y otros.
Antecedentes
- 0003991: BackOffice DIMO Empresa [#P220]
Supuestos
- Los requisitos están ordenados de la sgte manera:
- Columna Funcionalidades: Están englobados las funcionalidades, acciones o grupo de requerimientos similares.
- Descripción: Lo que se definió a hacerse después de la confirmación con el dueño del producto.
- Importancia: Si la funcionalidad tiene alguna prioridad para su desarrollo, de lo contrario se toma por orden.
- Notas: Algún comentario relevante en relación a esa funcionalidad.
- Comentarios: Sugerencia de cambios, modo de funcionamiento de parte del Analista para el dueño del producto.
Requisitos
| Nro. | Funcionalidades | Descripción | Importancia | Notas | Comentarios |
|---|---|---|---|---|---|
| 1.1 | Creación de Afinidades && Código Promotor |
|
| Realizar un análisis en conjunto con el producto de DimoDebito para unificar la necesidad de estos procesos de alta, personalización y mantenimiento de las afinidades y datos asociados. | |
| 1.2 | Proceso de Embozado | Se necesita actualizar la app de Embozado y los procesos de embozado de la 115 para permitir:
**APLICAR CARGOS A REIMPRESION Y RENOVACION |
| La idea principal de la App de Embozado es facilitar al dpto de OperacionesDimo con la gestión de las solicitudes de embozado de las tarjetas prepaga de DIMO y la trazabilidad de estas tarjetas físicas dentro de sus controles internos y los controles para/con el currier que las entrega al usuario. | Levantar con OperacionesDimo los requerimientos para un update más completo de la app de Embozado. |
| 1.3 | Usuarios DIMO con RUC | Se necesita verificar el flujo de registro, el flujo transaccional, facturación y consultas para un usuario con ruc en el dato de CI. |
| Verificar el funcionamiento de la app (si algún lugar se rompe la app) por procesar el campo ci como no numérico. | |
| 2.1 | Autogestión de Alta | Persona jurídica o persona física que desea utilizar el servicio debe gestionar el registro del mismo a través de una interfaz donde le permita cargar los datos que permitan identificarlo correctamente. Primer Proceso de Registro
Segundo Proceso – Digitalización de Documentos
Asignar el Codigo Promotor |
|
| |
| 2.2 | Validar datos para la activacion de la cuenta | El área de Operaciones dimo debe realizar la revisión de la documentación recibida, analizar, y definir un límite transaccional debe ser parametrizable según el análisis de riesgo. |
| ||
| 2.3 | Activación de la cuenta DIMO Empresa | Una vez validado por Operaciones DIMO, se crea la cuenta DIMO con el ruc de la Empresa y con una prepaga Afinidad DIMO con el NOMBRE DE FANTASIA, con las funcionalideades de DIMO:
***Activacion de la TP desde el backoffice |
| ||
| 2.4 | Monetización del producto / Comisiones | La parametrización de comisiones debe tener la posibilidad de aplicar un costo fijo por transacción y porcentaje de volumen de la transacción o la combinación de ambas. Es parametrización se debe aplicar a todas las transaccionales salientes con la posibilidad de no aplicar algunas. Ejemplo. Aplica cargo fee + % a acreditaciones. Aplica cargo solo % a transferencias. No aplica cargo a pago de servicio. ***Se va a aplicar el cargo a fin de mes, como parte del proceso de facturación de Administración. |
|
| |
| 2.5 | Roles de Usuarios por Empresa | Se necesita definir los roles que se tienen que crear para la operativa del Backoffice de DimoEmpresa y las actividades que van a tener permiso de realizar. |
| Se necesita disponibilizar la opción de recuperar contraseña para las cuentas del backoffice y si se va a utilizar el GAM (lo que quedaría en cancha de operacionesDimo la gestión de las cuentas) o se desarrollaria un módulo nuevo. | Se sugiere crear como mínimo 2, en un esquema de Autorizadores, Operadores. Que por ejemplo el Operador pueda programar los pagos, pero que solo con la autorización de los autorizadores se disparen las acreditaciones. Esto se podría definir y respetar esos roles.. ya que seria más parametrizaciones para los operadores de OperacionesDimo. |
| 2.6 | Control de limites transaccionales | Este límite estará definido previó análisis de la documentación proveeida en el momento del alta de la cuenta. La funcionalidad debe permitir parametrizar el volumen total que la cuenta puede recibir y la cantidad y volumen de las acreditaciones que puede realizar – debemos poder asignar también límites para transferencias. |
| Se definió que sea parametrizable el límite por acreditaciones, diaria o mensual. | |
| 2.7 | Fondeo de DIMO Empresa |
|
|
| Muchos de estos flujos no van a poder estar atados a la confirmación de OperacionesDimo antes de que la empresa pueda hacer acreditaciones. Solamente cuando es un Ajuste por ceibo, tendrían el control. Limitados también por el limite transaccional de Bancard. |
| 2.8 | Alta de funcionarios/usuarios Dimo Empresa |
Para crear sentido de pertenencia una Dimo Empresa podrá tener un código identificador/promotor (misma funcionalidad de la Gran Lógia) en ese momento se crea una dimo virtual con el diseño del plástico de la empresa.
La empresa podrá dar el alta de un usuario con la información necesaria para realizar la acreditación a la nueva cuenta. La empresa será responsable de dicha alta y al momento de realizar el primer login a Dimo deberá solicitar la confirmación de los datos, la aceptación de los términos y condiciones y por último el usuario definirá una contraseña. |
| En el Alta de Empresa
***Se crea la cuenta del usuario, con una contraseña x y se le envia un link por sms a la pantalla de olvide mi contraseña para que el usuario cambie su contraseña atravez del otp. | Quien estará cargo de la gestión de cuentas de estos usuarios? ATC por el CRM actual? |
| 2.9 | Acreditación masiva a funcionarios/usuarios | Las acreditaciones de Dimo empresa a usuarios Dimo. Debe contar con la funcionalidad de poder exportar de un archivo Excel. Los siguientes datos, número de CI, número de tarjeta Dimo y monto. Al momento de procesar el archivo de validar que la CI corresponda al número de tarjeta. También debe contar con la funcionalidad de acreditar 1 a 1. Con los mismos datos. |
|
**Controlar el archivo antes de ejecutar las acreditaciones. **Avisar al Operador sin cortar el flujo. | Seria interesante crear un participante Interno de Cabal contra quien se pueda hacer reversos, depósitos desde ventanilla, extracciones de ventanilla para que OperacionesDimo pueda gestionar de forma autonoma las acreditaciones, debitos y reversos transaccionales desde el SICOOP. |
| 2.10 | Conciliación de Acreditaciones, errores, reversos y débitos. | Se necesita incluir estas transacciones en el proceso de conciliación. |
| Se necesita definir si se necesita agregar también estas transacciones en el proceso de distribución de comisiones. **COMPRAS CON POS, QR, PRONET, INFONET | |
| 2.11 | Workflow de autorizaciones | Debe contar con flujo de autorizaciones de acuerdo al monto, que sea parametrizables las combinaciones. Ejemplo para montos superior a 100.000.000 debe contar con 2 autorizaciones y 1 operador carga. Gerente Administrativo verifica y aprueba, Gerente General aprueba y procede a la acreditación. |
|
| Este es un mundo de parametrizaciones.. es posible, pero OperacionesDimo va a tener otro producto con más parámetros. Se podria hacer uno general y no por empresa. |
| 2.12 | Informes y Reportes | no especificado |
| Se necesitaría definir los reportes. | Estaria bueno un dashboard para cada empresa, un dashboard interno del producto para OperacionesDimo y Gerencia. |
| 3.1 | Autorizaciones desde DIMO |
| |||
| 3.2 | Transferencias individuales desde DIMO |
| |||
| 3.3 | Visualizar reportes en DIMO |
|
Preguntas
| Nro. | Pregunta | Resultado |
|---|---|---|
| 1.0 | Tendrían cargos exclusivos para las cuentas de DimoEmpresa? | Proceso de facturación para calcular. A definir que mas costos se tendrán |
| 1.1 | Hasta que información de los usuarios hay que mostrarle a los administradores de DImoEmpresa? hasta donde se marca la linea de privacidad de usuarios? | Nombre, Ci y nro tarjeta. Sin datos de informaciones maximo fecha de acreditaciones. |
| 1.2 | Un funcionario/usuario puede pertenecer a más de una empresa? | Si puede, debe tener todas las afinidades dentro de Dimo. |
| 1.3 | Se va a poder aplicar ajustes débitos a los funcionarios? cómo débitos automáticos? ... reversos? etc? | |
| 1.4 | Las acreditaciones solo va a tener como destino la prepaga de esa empresa? o se va a poder acreditar a la cuenta de una cooperativa en el caso de que el funcionario lo prefiera? | También las cooperativas |
| 1.5 | Un usuario dimo, tendrá solamente 1 prepaga? en el caso de que se de de alta por dimo empresa, tendrá la prepaga de la empresa. Si el usuario ya existia y se le vincula a una empresa, se reemplazaria la prepaga? o tendría 2? | |
| 1.6 | El tema de afinidad/codigoPromotor, solo seria para usuarios nuevos? y aplicaria para usuarios antiguos tmb? | va a seguir con la otra afinidad |
| 1.7 | Tendría implicancia en el proceso de incidencia, embozado etc de la cuenta de sus funcionarios? Una experiencia similar a la transferencias de usuarios que no tienen dimo? O un registro “mínimo” para crear la tp y cuenta dimo (esto sería similar al registro normal hasta el punto de validar otp)? | |
| 1.8 | Si la empresa no cuenta con esos usuarios administradores del BackOffices? Esos usuarios deben tener cuenta dimo? O usuarios administrativos del backoffices? | |
| 1.9 | Si se generan comisiones por las transacciones, se distribuirán a las empresas?... Pago de Servicios, compras con QR... | |
| 1.10 |
Solución
| Nro. | Tarea | Propuesta de solución | Impacto |
|---|---|---|---|
| 1.0 | Embozado | Agregar funcionalidades que permitan gestionar las solicitudes, creación y mantenimientos de Afinidades (Altas, reposiciones, reimpresiones, bajas, etc). | Proceso de Embozado de Ceibo [ PL/SQL ] |
| 1.2 | App Embozado | Agregar las funcionalidades del punto anterior a la interfaz para que OperacionesDimo pueda autogestionarse. | Aplicación de Embozado [ GX ] Preferentemente para Agregar OperacionesDimo [ GX ] y unificar las aplicaciones. |
| 1.3 | Flujo de CI con RUC | Pruebas y ajustes de lo necesario para que Dimo pueda aceptar RUC en los campos donde se ingresan CI. | DIMO FrontEnd y BackEnd |
| 2.0 | BackOffice DimoEmpresa | Nuevo módulo para el uso de las Empresas. | NUEVO [ GX ] |
| 2.n | Roles de Usuarios | Modificación del GAM para permitir vincular Usuarios de empresas con sus roles y empresas correspondientes. | GAM [ GX ] |
| 2.n | Limite Transaccional | Módulo nuevo para el control de límites transaccionales. | NUEVO [ JAVA ] |
| 3.0 | Funciones nuevas para cuentas de empresas | Agregar las nuevas funcionalidades a la app de DIMO. | DIMO FrontEnd [ REACT ] |
Presupuesto
| Nro. | Tarea | Recurso | Analisis (hs) | Desarrollo (hs) | Pruebas (hs) | Doc. (hs) | Sub-Total (hs) |
|---|---|---|---|---|---|---|---|
| 1.0 | |||||||
| 1.1 | |||||||
| 1.2 | |||||||
| TOTAL FINAL (hs) | |||||||
| TOTAL FINAL (dias) | |||||||