Version objetivo | DIMO EMPRESA - Inicio |
Funcionalidad | DIMO EMPRESA |
Estado del documento |
|
Elaborado por | Hugo A. Diaz Parra |
Analistas | Arturo Sosa |
Solicitantes | Juan Almada - Oscar Barrios |
Fecha |
|
Objetivos
Desarrollar un Backoffice DIMO EMPRESAS que permita procesar transacciones de pagos de salarios, desembolsos, pago de servicios, transferencias y otros.
Antecedentes
Supuestos
Requisitos
Nro. | Caso de Uso | Resultado | Importancia | Notas | Sugerencia |
---|---|---|---|---|---|
Creación de Afinidades y Código Promotor | OperacionesDimo necesita un portal para crear afinidades y códigos promotor | ||||
Usuarios DIMO con ruc | Se necesita verificar el flujo de creación de usuarios de Dimo para certificar el correcto funcionamiento de un usuario con ruc envés de ci | ||||
Embozado de las DimoEmpresas | Se necesita modificar/actualizar el proceso de embozado de ceibo para permitir el embozado de afinidades dinámicamente | ||||
1.0 | 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
Generacion del Codigo Promotor |
| 1- Que la solicitud de Alta de una cuenta Empresa, sea por formulario firmado. Creo que seria más acorde a la realidad de las necesidades. 2- Luego que se reciba el formulario de Alta. Un operador puede cargar todos los datos de la empresa. 4- El usuario de la empresa, podria levantar los documentos restantes para esperar la validación de operacionesDimo o El operador de OperacionesDimo puede cargar esos documentos si los recibe por correo antes de validar la cuenta empresa. 5- El operador Puede generar manuealmente el Código Promotor, que será mostrado en el Login del usuarioEmpresa o notificado por mail o sms. Este no deberia de poder cambiarse, para evitar complicaciones en la creación de las DIMO asociadas a esta empresa | |
1.1 | 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. |
| ||
1.2 | 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:
|
| Sistemas: Para este punto se debe tener resuelto la posibilidad de la creación de N afinidades para dimo y su inclusión en el proceso de Embozado. Administración: Flujo de facturación para este servicio nuevo. | |
1.3 | 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. |
| ||
1.4 | 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. | |
1.5 | 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
| Quien estará cargo de la gestión de cuentas de estos usuarios? ATC por el CRM actual? | |
1.6 | 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. |
| 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. | |
1.7 | 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. | |
1.8 | 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. | Esto es posible siempre que se disparen desde dimoEmpresa. pero Estaria demasiado complicado hacerlo desde dimo solamente para funcionarios de una dimoEmpresa Hay que ver como conciliar estas transacciones Y si se va a distribuir de alguna forma estas comisiones | ||
1.9 | Gestión de usuarios y roles | Usuario administrador, y operadores. |
| Esto se podria definir y respetar esos roles.. ya que seria más parametrizaciones para los operadores de OperacionesDimo | |
1.10 | Informers y Reportes | ?? | ?? | Estaria bueno un dashboard para cada empresa, un dashboard interno del producto para OperacionesDimo y genrencia |
Preguntas
Nro. | Pregunta | Resultado |
---|---|---|
1.0 | Tendrían cargos exclusivos para las cuentas de DimoEmpresa? | |
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? | |
1.2 | Un funcionario/usuario puede pertenecer a más de una empresa? | |
Se va a poder emitir débitos a los funcionarios? cómo débitos automáticos? ..reversos? etc? | ||
Las acreditaciones solo van a ser para usuarios dimo? no se va a poder acreditar a la cuenta de una cooperativa en el caso de que el funcionario no quiera crear su cuenta dimo? | ||
El tema de afinidad/codigoPromotor, solo seria para usuarios nuevos? y aplicaria para usuarios antiguos tmb? | ||
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)? | ||
Si la empresa no cuenta con esos usuarios administradores del BackOffices? Esos usuarios deben tener cuenta dimo? O usuarios administrativos del backoffices? |