Page tree
Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 26 Next »

Version objetivoDIMO EMPRESA
FuncionalidadDimoEmpresa - BackOffice
Estado del documento
  • BORRADOR
  • FINAL
Elaborado por
Arturo Sosa
AnalistasArturo Sosa
SolicitantesJuan 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.
    • Sugerencia: Sugerencia de cambios, modo de funcionamiento de parte del Analista para el dueño del producto.

Requisitos

Nro.FuncionalidadesDescripciónImportanciaNotasSugerencia
0.1Creación de Afinidades && Código Promotor
  • OperacionesDimo necesita un portal para crear afinidades y donde pueda personalizar cada afinidad de la 115.
  • Esta afinidad debe estar asociada a un código promotor, con la posibilidad de la creación personalizada.
  • Esta afinidad y código promotor, deben estar vinculadas entre sí y ser vinculadas posteriormente a la cuenta de la empresa y sus funcionarios.


Recomiendo 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.
0.2Proceso de Embozado

Se necesita actualizar la app de Embozado y los procesos de embozado de la 115 para permitir:

  • Embozar las tarjetas dinámicamente.
  • Reimpresión de tarjetas. (reposición).
  • Baja de tarjetas y alta de nuevas.(Ej: al funcionario se le extravió la tarjeta física).
  • Cambio de estado a esas tarjetas. Disponible para OperacionesDimo y para el Usuario final.

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.
0.3Usuarios DIMO con rucSe necesita verificar el flujo de registro, el flujo transaccional, facturación y consultas para un usuario con ruc en el dato de CI.



Verificar si algún lugar se rompe la app por procesar el campo ci como numérico
1.0Autogestió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

  • NOMBRE DE FANTASÍA

  • Razón social

  • Ruc

  • Dirección

  • Contacto / tres espacios de números de teléfonos

  • Correo institucional

  • Cantidad de Funcionarios (???)

  • Datos del Titular / Responsable

  • Número de documento de identidad

  • Dirección contacto

  • Correo electrónico

  • Prever 2 responsables

Segundo Proceso – Digitalización de Documentos

  • Estatutos Sociales – Escritura

  • Acta última Asamblea

  • Últimas tres IVA

  • Certificado de cumplimiento tributario

Asignar el Codigo Promotor


  • La app será un Backoffice hecho en Genexus.
  • Tendrá cierta personalización para permitir mostrar a la empresa su logo.. COLOR??
  • El usuario DIMO Empresa debe tener la capacidad de modificar datos y reemplazar archivos. ????
  • OperacionesDimo deberá tener un Backoffice para el backoffice donde tendrá acceso a los sgtes puntos: 
    • Validación de cuenta
    • modificación de datos
    • bloqueos
    • limites etc
    • gestión general de las cuentasEmpresas

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.
3- Una vez que se dio de Alta, se puede enviar otp a los mails y números de correos con el instructivo del primer login.

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 manualmente 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.1Validar 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.


  • Consultar si va a ser un limite desde DimoEmpresas o uno general para el sicoop
Ver si se puede aplicar al motor de limite transaccional del SIcoop.
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:

  • Gestiones: Bloqueo de cuenta. No es necesario que la cuenta de dimo empresa tenga un plástico

  • Histórico de Movimiento

  • Mis Facturas

  • Histórico de acreditaciones: Debe detallar las acreditaciones realizadas incluir todos los datos de destinatario.




1.3Monetización del producto

  • Se necesita definir si se aplicarán cargos a las cuentas empresa o a los funcionarios asociados a esa empresa.
  • Se necesita definición para la facturación de esos costos si son necesarios.

1.4Roles de Usuarios por EmpresaSe 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 sugiere crear como mínimo 2, en un esquema de Administrador, Operador. Que por ejemplo el Operador pueda programar los pagos, pero que solo con la autorización del administrador, se disparen las acreditaciones.
1.5Control 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.


  • Control por dia, semana y mes ???

1.6Fondeo de DIMO Empresa
  • Ajustes créditos desde Operaciones Dimo
  • Recargas desde Bocas de Cobranza
  • Transferencias Bancarias

  • Gestion y control de depósitos Bancarios. Disparar incidencia para control de la boleta de deposito.
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.7Alta de funcionarios/usuarios Dimo Empresa
  • Alta por Usuario:

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.

  • Alta de 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

  • Envio de contrasenha temporal por SMS al nro. de telefono ingresado por la empresa.
  • El usuario ingresa normalmente con la contrasenha temporal y completa los datos faltantes.
  • Alta masiva por archivo


  • Gestion de funcionarios (alta, baja, modificacion)
Quien estará cargo de la gestión de cuentas de estos usuarios? ATC por el CRM actual?
1.8Acreditació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.


  • Valizar que el nro. de documento pertence a la empresa ??
  • Capacidad de reprocesar archivos.
  • Reversa individual (desde donde ?)
  • Destino siempre una cuenta DIMO ?
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.9Workflow 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.


  • Mostrar resumen a acreditar.
  • Se recomienda liberar la cantidad de autorizaciones requeridas y que quede a criterio de la empresa.
  • Agregar en DIMO el formulario de aprobación del workflow.
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.10Comisiones

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.Gestión de usuarios y roles Usuario administrador, y operadores.
  • Un administrador (propietario) y multiples operadores, autorizadores.
  • Usuario = correo electronico
  • Recuperacion de contraseñas
Esto se podria definir y respetar esos roles.. ya que seria más parametrizaciones para los operadores de OperacionesDimo
1.10Informers y Reportes??
??Estaria bueno un dashboard para cada empresa, un dashboard interno del producto para OperacionesDimo y genrencia


Preguntas

Nro.PreguntaResultado
1.0Tendrían cargos exclusivos para las cuentas de DimoEmpresa?
1.1Hasta 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 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?

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?

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?






  • No labels