Sobre este proyecto
it-programming / mobile-development
Abierto
App conjuntos
especificación técnica:
se requiere una app móvil inicialmente para plataformas android y ios para todas las funcionalidades, el lenguaje de programación es a elección del proponente no se tiene restricción en este punto, lo que se debe de tener en cuenta es que al app debe poder hacer notificaciones push en el dispositivo (tipo twitter, facebook o whatpsapp), acceder al gps del dispositivo para hacer georeferenciación de mi ubicación actual con el comercio cercano y debe de soportar el api de zoom (especificado más adelante) para ejecutar reuniones. Adicionalmente se requiere una aplicación web responsive (panel administrador y modulo para comercio) en alguna de las siguientes tecnologías (.net Core 3, java 8 o Ruby On Rails) la parte FrontEnd debe ser adaptativa a diferentes dispositivos (Web Responsive) y debe hacer uso de los siguientes componentes HTML5, CSS3, Bootstrap, JQuery. Ambas aplicaciones (Móvil y Web) deben hacer uso de una única base de datos es decir el modelo relacional debe de estar totalmente integrado, las opciones para la BD relacional: Sql server, mysql o Postgresql, al momento de elección de la bd se debe garantizar una estrategia óptima para el almacenamiento de archivos (word, pdf, image) el manejo de campos tipo blob en un campo de una tabla no son válidos.
La arquitectura de solución y/o diseño debe estar pensada para hacer el despliegue en Cloud (Azure o AWS). Se busca un producto costo fijo por aplicación terminada, de la cual se deberá entregar el código fuente para futuras modificaciones, así como la documentación técnica en donde se explique cómo se encuentra distribuido el desarrollo y cuáles fueron las estrategias de desarrollo utilizadas (se entregará anexo técnico de requisitos solicitados) este anexo es una parte fundamental e igual de importante que el desarrollo . No se debe hacer uso de librerías encriptadas y/o propias, y en caso de usarlas también se debe hacer entrega de dicho código fuente.
Se solicita hacer uso del repositorio de trabajo “Azure DevOps” cuyo espacio de trabajo será proporcionado para su uso. Sobre esta plataforma se hará seguimiento a las actividades y servirá como canal de comunicación en caso de dudas de negocio o técnicas. Se espera que cada 2 semanas se realice una DEMO de las funcionalidades terminadas y desplegadas para iniciar las correspondientes pruebas funcionales.
El desarrollo debe ser escalable para multitenant y orientado a soportar despliegues en la nube tipo azure/aws. Se solicita plantear y exponer cuál será la estrategia de performance de la App móvil, se sugieren estrategias como llamadas asíncronas a la Base de datos, sin embargo se esperan más propuestas para este item. Con respecto a la concurrencia de usuarios se proporcionara un estimado de cantidad de usuarios y concurrentes del mismo, para este item se solicita utilizar alguna herramienta de LOAD que stresse la App y se vea como es su comportamiento bajo cierta carga.
Los dos Items anteriores load y performance son muy importantes al momento del desarrollo porque se estima que los usuarios de la app serán miles, pues cada nuevo conjunto residencial aportará cientos de nuevos usuarios (existen conjuntos hasta con 400 apartamentos, es decir, 400 usuarios solo por 1 conjunto).
Se espera tener en la parte administrativa/panel módulos tales como (Creación usuarios, creación propiedades, cuentas de acceso) donde las mismas podrán ser creadas individualmente como masivamente por medio de Excel. La aplicación deberá contar con la respectiva auditoría de las acciones que lleven a cabo los usuarios (CreateBy, CreteDate, ModifyBy, ModifyDate) eso podrá ser manejado normalmente en las Tablas de la bd, adicionalmente se espera que se modelen tablas tipo log para identificar posibles excepciones en los endpoints donde se pueda ver info de request, response, endpoint llamado, user, fechas, excepcion, etc. Se suministrarán los mockups y el logo de modo que se entregue con la aplicación el diseño de la misma.
En el front end se busca una interfaz dinámica y similar a rappi con iconos nombrados y de que sea de fácil navegación.
Se requiere que el desarrollo se lleve a cabo en un PAAS (Platform as a service), se debe tener en cuenta los aspectos de seguridad de AWS.
Para el módulo de Autenticación, se debe de manejar estilo SSO, es decir un único user para la App y el Web Site. Adicionalmente se debe de contar con las opciones de Crear Cuenta, Recordar Clave, Cambiar Clave (todo estos para los casos en los que el user desee crear una cuenta exclusiva en nuestra BD), pero también se debe de otorgar la opción de Crear Cuenta por medio de Login Federado (gmail, facebook). Para todos los casos se debe de contar con el CAPTCHA strategy.
Para los usuarios creados por procesos masivos (Excel) se enviará un email con una URL de activación del la cuenta y asignación de la primera clave.
El anexo tecnico debe tener un apartado muy preciso de como es el despliegue en cada uno de los distintos ambientes: Android, iOS, Web.
La app móvil deberá mostrar un contacto (email) general de soporte de usuarios para reporte de bugs, soporte sobre la App o cualquier evento relacionado con la misma.
Se debe entregar código fuente completo sin dll encriptadas (en caso de necesitar alguna, deberá ser aprobada previamente), base de datos, anexos técnicos, usuarios, claves, configuraciones, acceso a AWS y todo lo relacionado a las Apps (movil y Web).
El tiempo de garantía de funcionamiento de las aplicaciones será de 30 días luego de la entrega total del producto y que será aceptada por las partes, esta última etapa (garantía) se encontrara sujeta al último pago del proyecto, es decir, que después de solucionados TODOS los bugs encontrados (estos bugs son los de garantía y los de las entregas parciales) se realizará el último pago. Adicionalmente se debe de garantizar que las entregas parciales realizadas puedan ser testeables, asi el proceso de pruebas será mas eficaz, en caso de no garantizar esta última parte (entregas testeables), el tiempo de garantia debera ser incrementado, pues no se tendría el tiempo suficiente para probar las aplicaciones de manera completa, este item será acordado por cada entrega parcial, pues de cada entrega dependerá el tiempo total de garantía.
Al completar el 80% del proyecto, se desea tener una cotización para soporte del producto con asignación medio tiempo.
MVP:
La aplicación va dirigida a conjuntos residenciales, edificios, condominios, locales de centro comerciales, con el fin de gestionar aspectos propios de la administración de los inmuebles y espacios comunes, se dividen en módulos y funcionalidades, así:
(Móvil) Módulo Servicios virtualizados: Asamblea y votación virtual: Asistencia virtual a las asambleas (Zoom API) que se celebran en cada unidad residencial y votación virtual parametrizable.
(Web&Movil) Módulo Link Pago admon: Linkear el banco que utilice cada conjunto para el pago de administración
(Web&Movil) Módulo Comercio/Profesionales: Permitir que los comerciantes del sector puedan publicar promociones y clasificados de sus negocios en la app y que los usuarios visualicen dicha información comercial (por sector).
(Móvil) Módulo Comunicaciones (Clasificados, novedades, comunicaciones y notificaciones): Parametrizar y publicar clasificados internos de los inmuebles, información general, novedades y notificaciones
(Móvil) Modulo Boton de panico para los conjuntos residenciales
(Móvil) Funcionalidad Manejo de aceptación de habeas data
(Móvil) Modulo Link para acceso a la aplicación Trymi ride
(Móvil) Módulo Chat con vigilancia o portería del conjunto
(Web&Movil) Funcionalidad Pagos por servicios de la app. (Accesos Free, Premium, Total dondes se activan o desactivan funcionalidades)
ROLES:
(Web&Movil) Usuario para rol administrador conjunto
(Web&Movil) Usuario para rol propietario de inmueble
(Web&Movil) Usuario para rol profesionales, es decir personas que ofrecen servicios varios (plomero, carpintero, etc)
(Web&Movil) Usuario para rol comercio, el cual desea publicar clasificados comerciales.
(Web&Movil) Usuario para rol dueño aplicación (admin).
NOTA: El Rol 3 y 4 podría ser el mismo, solo se diferencian en el tipo de venta (uno vende servicios el otro vende productos)
Detalle módulos
MODULO: Servicios virtualizados: Asambleas y votación virtual
FUNCIONALIDADES:
Dos sub-módulos: 1. Asambleas virtuales y 2. Votación virtual
sub-modulo: asambleas virtuales:
los siguientes usuarios podrán tener acceso a este módulo:
*usuario administrador conjunto
*usuario propietario de inmueble
*usuario dueño aplicación (admin).
Detalle:
*(Web&Movil) Registro de asistentes a reunión (al inicio y final de la asamblea) usando firma digital (Por cada inmueble de la unidad residencial).
*(Web) Resguardo de información (actas, asistencias y resultados votación) antes y posterior a la reunión.
*(Web) Generador de actas o memorias.
*(Móvil) Embeber servicio zoom para reuniones virtuales.
Cada unidad residencial tiene un propio acceso y privacidad de su información en relación a la de otros conjuntos.
La aplicación deberá tener estas funcionalidades:
El rol “Administrador de conjunto”, tendrá la opción CRUD para Complejo (se proporcionará diccionario de datos).
nit (pk)
razón social
nombre representante legal, paola romero (aqui debe de haber una relación con usuarios)
conjunto residencial: jardines del retiro
dirección
teléfono
firma digital
valor mínimo admon: $300.000
Valor máximo admon: $350.000
Attachments
Habeas Data F. ( Manejo de aceptación de habeas data).
Nombre Banco pago Administración
Parámetro Link: Banco administración
Plan Acceso I. Funcionalidad Pagos por servicios de la app. (Accesos Free, Premium, Total dondes se activan o desactivan funcionalidades)
Campos de Auditoria (CreatedOn, CreateBy, ModifiedOn, ModifiedBy)
Los roles “”, “”, tendrán la opción CRUD de Propiedad (se proporcionará diccionario de datos).
Conjunto residencial: Jardines del retiro, campo por default y readOnly, debe traer el conjunto al que pertenece al momento de la creación
Tipo de propiedad, [Apartamento, casa, lote, local] - tabla tipo parámetro (id, codigo, nombre, descripcion, is Enable)
Casa/Apartamento 301
Interior/Bloque 4
Manzana
Propietario: Relacion con Usuario
Rol: Un user account podrá estar asociada con varios inmuebles y por cada uno se tiene su rol independiente, el diferenciador será el conjunto
Otro?
Los roles “”, “”, tendrán la opción CRUD de Usuario (se proporcionará diccionario de datos).
Tipo Documento
Documento
Nombres, Paola
Apellidos, Romero
Firma digital
Teléfono
Celular
Correo electrónico
Attachments (cedula, otros)
Campos de Auditoria (CreatedOn, CreateBy, ModifiedOn, ModifiedBy)
Inmuebles asociados
Tipo de relación con inmueble, [Propietario, arrendatario, apoderado]
Permitir CRUD de transmisión de reuniones. Para ello es necesario embeber una aplicación de streaming existente, en este caso se utilizará zoom que cuenta con Api https://marketplace.zoom.us/docs/guides, https://devforum.zoom.us/, con esta opción se deberá poder embeber url’s que asigne la herramienta sin que el usuario pueda compartir/visualizar su url o credenciales de acceso, por el contrario el usuario del sistema ingresará directamente a la video llamada gracias a un token/credencial de acceso asignado previamente al conjunto completo (revisar plataforma openenglish que cuenta con este funcionalidad).
El servicio de transmisión de reuniones estará asociado a un conjunto residencial, fecha y título del espacio donde se almacenará la información de la sesión o reunión a celebrar, a manera de una biblioteca, (máximo 20 atributos, se proporcionará diccionario de datos)
Título: Asamblea extraordinaria;
Fecha;
Estado sesión: [Abierta, en curso, cerrada];
Agenda: espacio de texto abierto enriquecido (se podrá aplicar formatos, justificación, numerales, tipo letra, etc )
Código Zoom reunión
Tiempo almacenamiento
GeneraCosto
Costo Session Adicional
Relación con el acta de asistencia (también va la relación con los poderes de representación)
Attachment: Información que requieran en word, pdf, imágenes.
El espacio de la sesión o reunión debe ser uniforme a la App, a pesar de contar con un servicio externo de streaming, se debe de diseñar en UI de tal manera que otorgue la sensación de ser un único componente.
Por otra parte es necesario poder parametrizar el costo del servicio de streaming a los propietarios (para el pago se utilizara una pasarela de pagos que por ahora debe sólo mostrar el logo, se establecerá rangos de montos de admon para calcular el cobro, esto lleva una fórmula interna para el cálculo (ejemplo: 0.04% del promedio del rango)). Ver Módulo I. Del presente documento.
Manejo de historial de reuniones:
Se requiere manejar el historial de cada servicio de streaming que se generó, es decir el administrador de la reunión puede guardar la grabación (por un tiempo específico y previamente parametrizado), el cual también dependiendo del plan contratado tendrá un costo el contar con dicho acceso a la grabación de la asamblea. Ver módulo I. Del presente documento, El modo de visualización de los datos del historial de reuniones es.
PREVIO A la reunión:
opción de diligenciamiento de datos de la reunión para almacenamiento:
reunión: sesión 1
fecha: 20 de agosto de 2019
adjuntos: ej. Reglamento conjunto, balance año anterior, etc
post reunión:
fecha 20 de agosto de 2019
actas y minuta generadas (adjuntos)
grabación (se parametriza el tiempo de almacenamiento, luego se borra automáticamente dependiendo el plan elegido por el usuario)
nota: el diccionario de datos podria variar en relación a la definición de los datos de acuerdo al afinamiento del requerimiento que se lleve a cabo semana a semana con el desarrollador
sub-módulo votaciones:
permitir crud de parametrizar votaciones
encabezado:
motivo votación: elegir presidente de junta, debe poder modificar los nombres de postulados
attachments adjuntar imagen o archivo
votos: relación de cada usuario que se conecte.
Resultado votación
Permitir votación de usuarios que no tienen la aplicación instalada: Desde otro dispositivo se podrá ingresar al portal web y en la sala de votación activa poder ver también las votaciones en curso y finalmente poder realizar la votación.
Cuenta Usuario
Conjunto
Apoderado (si/no)
Número apartamento/casa asociado a la cuenta de usuario en ese conjunto.
Para los resultados de la votación, se deberá contar al final con los datos y rankear los resultados de las opciones que se parametricen, visualizando los resultados por medio de dos opciones graficas (barras o torta).
Cada reunión contará con un registro de asistencia el cual estará asociado a cada usuario que ingrese a la sala de reunión y que estará firmado digitalmente por la persona como asistente, desde este registro de asistencia, se podrán generar las actas de asistencia y contenido de la asamblea a modo plantilla, dicha generación de actas tendrá modificable título, logo, asunto, firma del conjunto y/o apoderado. Adicionalmente una cuenta de usuario puede tener asociados más propiedades en esa reunión (poderes de representación). Dicho poder se genera por medio de una autorización generada por el propietario del inmueble y será dirigida al administrador del conjunto, con copia a la persona asignada de poder, quién será el representante en asamblea, dicho poder podrá diligenciarse y enviarse con firma digital.
NOTA:
*La aplicación deberá permitir hacer registro seguro enviando correo electrónico para garantizar que la autenticidad de la persona.
B. MODULO: Link pago administración:
Los siguientes usuarios podrán tener acceso a este módulo
*TODOS
Detalle:
La aplicación deberá permitir Linkear el banco que utilice cada conjunto para el pago de administración además puede modificarse el texto de la descripción de dicha opción.
Ejemplo: Para poder hacer el pago de la administración, realizalo por banco hola mundo y puedes utiliza el link: www.BANCOHOLAMUNDO.COM. (Ver CRUD Conjuntos)
C. MÓDULO: Comercio:
Los siguientes usuarios podrán tener acceso a este módulo
*Usuario Comercio
*Usuario Profesionales
*Usuario dueño aplicación
*Usuario administrador conjunto
*Usuario propietario de inmueble
Se deben tener dos submódulos: Comercio y Profesionales
SUB-Módulo: comercio
registro de usuario comercial con atributos específicos (el diccionario de datos será definido en el desarrollo) para usuario comercio.
Chat privado entre comerciante y cliente, para solicitud de domicilios o información de despacho o servicios. Para todos los usuarios debe existir en el chat la anotación de no envío de datos personales de contacto como teléfono o email, de ser así se debe notificar al usuario dueño de aplicación para bloqueo de usuario. La comunicación comercial entre usuarios debe ser por el chat, lo permitido será enviar datos de direccion para envio de domicilios.
Parametrización Guia de clasificados de la zona y chat al comercio: Por geo referenciación que cuando acceda al logo del comercio me muestre el dato del local y al picar allí redirija al chat para centralizar pedidos. La parametrización podrá visualizarse si el comerciante realiza el pago del servicio. Ver condiciones del presente documento en modulo I.
Métodos de Pagos por acceso a los módulos de la app. La visualización del comercio y proporciones por georeferenciación podrá hacerse por todos los usuarios. Debe con una opción de búsqueda para que el usuario final pueda validar si determinado tipo de comercio disponible en el mapa.
Debe tener la opción por medio google maps de ubicar al usuario en como llegar al comercio.
Puja/Subasta de clasificados por pop con promociones, esta funcionalidad solo está habilitada para comerciantes inscritos. Para usuario comercio y Usuario dueño aplicación
El usuario podrá generar pago de publicidad usando pasarela de pago para estar en comercio sugerido. Esta funcionalidad solo está habilitada para usuario comercio si se encuentra inscrito.
Linea de anuncios con nombres de comercios parametrizable y que sea visualizada por propietarios de los inmuebles de los conjuntos. Esto va para todos los usuarios dependiendo la georeferenciacion.
SUB-Módulo: profesionales
registro de usuario profesional con atributos específicos (el diccionario de datos será definido en el desarrollo) para usuario profesional y dueño de aplicación.
Chat privado entre profesional y cliente (comercio o usuario estándar), para solicitud de domicilios o información de servicios. Para todos los usuarios debe existir en el chat la anotación de no envío de datos personales de contacto como teléfono o email, de ser así se debe notificar al usuario dueño de aplicación para bloqueo de usuario. La comunicación de profesionales con usuarios debe ser por el chat, lo permitido será enviar datos de direccion para envio de domicilios.
Lista de profesionales: Se de contar con un listado maestro con los profesionales q se inscriban a la aplicación, para dicha inscripción se debe contar con máximo campos que se definira su diccionario de datos en el desarrollo de la aplicacion que se definirán acorde lo requerido. Posterior al diligenciamiento el profesional deberá pagar un monto o suscripción a la app que utiliza la pasarela de pago que se defina.
Puja/Subasta de clasificados por push con promociones, esta funcionalidad solo está habilitada para profesionales inscritos. Para usuario comercio y Usuario dueño aplicación.
El usuario profesional podrá generar pago de publicidad usando pasarela de pago para estar en comercio sugerido. Esta funcionalidad solo está habilitada para usuario inscritos.
D. MÓDULO: Comunicaciones del conjunto (Clasificados, novedades, comunicados y notificaciones):
Los siguientes usuarios podrán tener acceso a este módulo
*Usuario administrador conjunto
*Usuario propietario de inmueble
*Usuario dueño aplicación.
Detalle:
Podrá contar con 4 opciones editables que deberán mostrarse tipo push como nuevas notificaciones en el móvil del usuario, estos son:
Novedades: Máximo 2000 caracteres,con posibilidad de adjuntar archivos pdf o imágenes ej: El dia de mañana 20 de febrero habrá un corte de agua por 3 horas.
Notificaciones: Máximo 2000 caracteres, con posibilidad de adjuntar archivos como pdf o imagenes ej.Se iniciara desde mañana la contratación de la empresa de vigilancia del conjunto
Clasificados: Máximo 3000 caracteres con posibilidad de adjuntar archivos como imágenes ej1: Se vende apartamento 3 alcobas, 2 baños, valor 260.000.000. Ej2: Se busca plomero para revisar la tubería del conjunto.
Comunicados: Máximo 3000 caracteres con posibilidad de adjuntar archivos como PDF. En caso de comunicados a personas morosas debe llegar notificación a su móvil y a su correo electrónico. Se podrá enviar citación a asambleas adjuntando los pdf que se requieran.
E. MODULO: Boton de panico para los conjuntos residenciales
Dirigido a los siguientes usuarios
Usuario administrador conjunto
Usuario propietario de inmueble
Usuario comercio
Usuario dueño aplicación
Detalle:
Se debe contar con la posibilidad de oprimir un botón que permita parametrizar el motivo del llamado a pánico, ya sea un evento natural como terremoto o algún evento que ponga en peligro la seguridad del conjunto. Se requiere que la persona al oprimir pánico acepte la anotación que generaría el sistema donde se recuerde la responsabilidad de oprimir el botón y si considera que es un suceso de alta prioridad por favor continúe, posteriormente debe especificar algunos campos que se solicitarían como por ejemplo:
Descripción breve del suceso,
Prioridad: lista desplegable desplegable describiendo prioridad 1, 2 , 3,
Descripción: Detalle de lo ocurrido,
Contacto cuadrante: mostrará el número del cuadrante de la zona.
Contacto de quien genera: Campo opcional.
Para los conjuntos:
Cuando se envíe el estado de pánico a los usuarios del conjunto debe aparecer q usuario y de qué apto reporta, con esto se deberá enviar una notificación push a todos los usuarios adscritos al conjunto y la administración del mismo donde se genere un sonido de sirena para dicha notificación.
Para el comercio: Se enviará estado de pánico a otros comercios cercanos, deberá mostrar la dirección y usuario quien reporta con sonido de sirena para dicha notificación.
Para todos los casos se tendrá la opción de reportar por otros usuarios si se considera que alguien ha hecho uso inadecuado de la funcionalidad, de ser así la administración podrá bloquear la funcionalidad al usuario reportado.
F. MODULO: Manejo de aceptación de habeas data
Dirigido a los siguientes usuarios
Usuario administrador conjunto
Usuario propietario de inmueble
Usuario comercio
Detalle:
Al momento de obtener la solicitud de registro a la aplicación de un nuevo usuario (Aplica para todos los usuarios que sean creados), el sistema debe mostrar las anotaciones con las condiciones de habeas data las cuales serán parametrizables (CRUD), dichas condiciones son obligatorias y se deberán aceptar para poder continuar con el proceso de creación y/o acceso a la App. Esta aceptación del usuario deberá poder rastrearse en la auditoría de la aplicación y adicionalmente debe de quedar un registro por correo electrónico de dicha aceptación.
G. MODULO: Link para acceso a la aplicación Trymi ride
Dirigido a los siguientes usuarios
Usuario administrador conjunto
Usuario propietario de inmueble
Usuario dueño aplicación
Debe permitir linkear la aplicación a otra app y en este caso será Trymi ride. Se podrá modificar el texto de la descripción y el link de dicha opción (solo administrador del sistema).
H. MÓDULO: Chat con portería del conjunto
Dirigido a los siguientes usuarios
Usuario administrador conjunto
Usuario propietario de inmueble
Usuario dueño aplicación
Detalle:
Se podrá tener un chat directo a la portería donde por este medio se notificará entrega de paquetes, autorizar ingreso de personal con los soportes, o temas de seguridad de baja prioridad del conjunto.
I. MÓDULO: Métodos de Pagos por acceso a los módulos de la app.
(Elección entre Tres modalidades de pago donde se activan o desactivan funcionalidades)
Dirigido a los siguientes usuarios
Usuario administrador conjunto
Usuario comercio
Usuario propietario de inmueble
Usuario dueño aplicación
Para los conjuntos:
Este método de acceso a la aplicación se elige en el momento de la creación del usuario “Administrador de conjunto”, estas podrían modificarse en caso de requerir variaciones en los accesos y precios:
Forma de pago 1 para acceso a la app (Full access): Permite acceso ilimitado a todas las funcionalidades:
*Link Pago admon: Linkear el banco que utilice cada conjunto para el pago de administración
*Comercio: Visualización de comercio de la zona y promociones.
*Clasificados, novedades, comunicados y notificaciones: Para administración podrá parametrizar y publicar clasificados internos de los inmuebles, información general, novedades y notificaciones. Para los propietarios: Podrán publicar clasificados sin costo.
*Boton de panico para los conjuntos residenciales
* Link para acceso a la aplicación Trymi ride
*Chat con vigilancia o portería del conjunto
En el caso de el modulo de Asambleas y votación virtual:
*Permite acceso a 4 asambleas en 1 año, entonces la app deberá tener un contador interno donde se especifique cuántas asambleas se han realizado en ese periodo de tiempo, en caso de llegar a la 4a y queriendo usar una 5a, se deberá mostrar la opción de pago usando la pasarela que se determine.
*Almacenamiento permanente de historial de asambleas virtuales y consolidado resultados de votaciones
Forma de pago 2 para acceso a la app (Medium access):
*Link Pago admon: Linkear el banco que utilice cada conjunto para el pago de administración
*Comercio: Visualización de comercio de la zona y promociones.
*Clasificados, novedades, comunicados y notificaciones: Para administración podrá parametrizar y publicar clasificados internos de los inmuebles, información general, novedades y notificaciones. Para los propietarios: Podrán publicar clasificados sin costo.
*Boton de panico para los conjuntos residenciales
* Link para acceso a la aplicación Trymi ride
*Chat con vigilancia o portería del conjunto
En el caso de el modulo de Asambleas y votación virtual:
*Permite acceso a 2 asambleas en 1 año, entonces la app deberá tener un contador interno donde se especifique cuántas asambleas se han realizado en ese periodo de tiempo, en caso de llegar a la 2a y queriendo usar una 3a, se deberá mostrar la opción de pago usando la pasarela que se determine.
*Almacenamiento historial de asambleas virtuales y consolidado resultados de votaciones por un tiempo de 2 meses, después de este tiempo tendrá cobro y se parametrizar en el transcurso del desarrollo.
Forma de pago 3 (Open access for demain):
Acceso ilimitado:
*Link Pago admon: Linkear el banco que utilice cada conjunto para el pago de administración
*Comercio: Visualización de comercio de la zona y promociones.
*Boton de panico para los conjuntos residenciales
*Link para acceso a la aplicación Trymi ride
*Chat con vigilancia o portería del conjunto
Acceso limitado:
Clasificados, novedades, comunicados y notificaciones:
*Para administración: Se podrán generar 4 envíos mensuales en total entre notificaciones, novedades, comunicados y clasificados remitidos por la administración, entonces la app deberá tener un contador interno donde se especifique cuántas envíos se han realizado en ese periodo de tiempo, en caso de llegar a la 4o envío y queriendo usar un 5to envío, se deberá mostrar la opción de pago usando la pasarela que se determine.
*Para los propietarios de inmuebles: Podrán publicar clasificados pero en la acción se mostrar la opción de pago acorde la pasarela que se estime usar.
En el caso de el modulo de Asambleas y votación virtual:
*Permite acceso a 2 asambleas en 1 año, entonces la app deberá tener un contador interno donde se especifique cuántas asambleas se han realizado en ese periodo de tiempo, en caso de llegar a la 2a y queriendo usar una 3a, se deberá mostrar la opción de pago usando la pasarela que se determine.
*Almacenamiento historial de asambleas virtuales y consolidado resultados de votaciones que tendrá cobro y se parametrizar en el transcurso del desarrollo.
Para el comercio/profesionales:
Acceso limitado: A todas los y se requiere cobro para acceder a la plataforma específicamente a la funcionalidad de Comercio.
especificación técnica:
se requiere una app móvil inicialmente para plataformas android y ios para todas las funcionalidades, el lenguaje de programación es a elección del proponente no se tiene restricción en este punto, lo que se debe de tener en cuenta es que al app debe poder hacer notificaciones push en el dispositivo (tipo twitter, facebook o whatpsapp), acceder al gps del dispositivo para hacer georeferenciación de mi ubicación actual con el comercio cercano y debe de soportar el api de zoom (especificado más adelante) para ejecutar reuniones. Adicionalmente se requiere una aplicación web responsive (panel administrador y modulo para comercio) en alguna de las siguientes tecnologías (.net Core 3, java 8 o Ruby On Rails) la parte FrontEnd debe ser adaptativa a diferentes dispositivos (Web Responsive) y debe hacer uso de los siguientes componentes HTML5, CSS3, Bootstrap, JQuery. Ambas aplicaciones (Móvil y Web) deben hacer uso de una única base de datos es decir el modelo relacional debe de estar totalmente integrado, las opciones para la BD relacional: Sql server, mysql o Postgresql, al momento de elección de la bd se debe garantizar una estrategia óptima para el almacenamiento de archivos (word, pdf, image) el manejo de campos tipo blob en un campo de una tabla no son válidos.
La arquitectura de solución y/o diseño debe estar pensada para hacer el despliegue en Cloud (Azure o AWS). Se busca un producto costo fijo por aplicación terminada, de la cual se deberá entregar el código fuente para futuras modificaciones, así como la documentación técnica en donde se explique cómo se encuentra distribuido el desarrollo y cuáles fueron las estrategias de desarrollo utilizadas (se entregará anexo técnico de requisitos solicitados) este anexo es una parte fundamental e igual de importante que el desarrollo . No se debe hacer uso de librerías encriptadas y/o propias, y en caso de usarlas también se debe hacer entrega de dicho código fuente.
Se solicita hacer uso del repositorio de trabajo “Azure DevOps” cuyo espacio de trabajo será proporcionado para su uso. Sobre esta plataforma se hará seguimiento a las actividades y servirá como canal de comunicación en caso de dudas de negocio o técnicas. Se espera que cada 2 semanas se realice una DEMO de las funcionalidades terminadas y desplegadas para iniciar las correspondientes pruebas funcionales.
El desarrollo debe ser escalable para multitenant y orientado a soportar despliegues en la nube tipo azure/aws. Se solicita plantear y exponer cuál será la estrategia de performance de la App móvil, se sugieren estrategias como llamadas asíncronas a la Base de datos, sin embargo se esperan más propuestas para este item. Con respecto a la concurrencia de usuarios se proporcionara un estimado de cantidad de usuarios y concurrentes del mismo, para este item se solicita utilizar alguna herramienta de LOAD que stresse la App y se vea como es su comportamiento bajo cierta carga.
Los dos Items anteriores load y performance son muy importantes al momento del desarrollo porque se estima que los usuarios de la app serán miles, pues cada nuevo conjunto residencial aportará cientos de nuevos usuarios (existen conjuntos hasta con 400 apartamentos, es decir, 400 usuarios solo por 1 conjunto).
Se espera tener en la parte administrativa/panel módulos tales como (Creación usuarios, creación propiedades, cuentas de acceso) donde las mismas podrán ser creadas individualmente como masivamente por medio de Excel. La aplicación deberá contar con la respectiva auditoría de las acciones que lleven a cabo los usuarios (CreateBy, CreteDate, ModifyBy, ModifyDate) eso podrá ser manejado normalmente en las Tablas de la bd, adicionalmente se espera que se modelen tablas tipo log para identificar posibles excepciones en los endpoints donde se pueda ver info de request, response, endpoint llamado, user, fechas, excepcion, etc. Se suministrarán los mockups y el logo de modo que se entregue con la aplicación el diseño de la misma.
En el front end se busca una interfaz dinámica y similar a rappi con iconos nombrados y de que sea de fácil navegación.
Se requiere que el desarrollo se lleve a cabo en un PAAS (Platform as a service), se debe tener en cuenta los aspectos de seguridad de AWS.
Para el módulo de Autenticación, se debe de manejar estilo SSO, es decir un único user para la App y el Web Site. Adicionalmente se debe de contar con las opciones de Crear Cuenta, Recordar Clave, Cambiar Clave (todo estos para los casos en los que el user desee crear una cuenta exclusiva en nuestra BD), pero también se debe de otorgar la opción de Crear Cuenta por medio de Login Federado (gmail, facebook). Para todos los casos se debe de contar con el CAPTCHA strategy.
Para los usuarios creados por procesos masivos (Excel) se enviará un email con una URL de activación del la cuenta y asignación de la primera clave.
El anexo tecnico debe tener un apartado muy preciso de como es el despliegue en cada uno de los distintos ambientes: Android, iOS, Web.
La app móvil deberá mostrar un contacto (email) general de soporte de usuarios para reporte de bugs, soporte sobre la App o cualquier evento relacionado con la misma.
Se debe entregar código fuente completo sin dll encriptadas (en caso de necesitar alguna, deberá ser aprobada previamente), base de datos, anexos técnicos, usuarios, claves, configuraciones, acceso a AWS y todo lo relacionado a las Apps (movil y Web).
El tiempo de garantía de funcionamiento de las aplicaciones será de 30 días luego de la entrega total del producto y que será aceptada por las partes, esta última etapa (garantía) se encontrara sujeta al último pago del proyecto, es decir, que después de solucionados TODOS los bugs encontrados (estos bugs son los de garantía y los de las entregas parciales) se realizará el último pago. Adicionalmente se debe de garantizar que las entregas parciales realizadas puedan ser testeables, asi el proceso de pruebas será mas eficaz, en caso de no garantizar esta última parte (entregas testeables), el tiempo de garantia debera ser incrementado, pues no se tendría el tiempo suficiente para probar las aplicaciones de manera completa, este item será acordado por cada entrega parcial, pues de cada entrega dependerá el tiempo total de garantía.
Al completar el 80% del proyecto, se desea tener una cotización para soporte del producto con asignación medio tiempo.
MVP:
La aplicación va dirigida a conjuntos residenciales, edificios, condominios, locales de centro comerciales, con el fin de gestionar aspectos propios de la administración de los inmuebles y espacios comunes, se dividen en módulos y funcionalidades, así:
(Móvil) Módulo Servicios virtualizados: Asamblea y votación virtual: Asistencia virtual a las asambleas (Zoom API) que se celebran en cada unidad residencial y votación virtual parametrizable.
(Web&Movil) Módulo Link Pago admon: Linkear el banco que utilice cada conjunto para el pago de administración
(Web&Movil) Módulo Comercio/Profesionales: Permitir que los comerciantes del sector puedan publicar promociones y clasificados de sus negocios en la app y que los usuarios visualicen dicha información comercial (por sector).
(Móvil) Módulo Comunicaciones (Clasificados, novedades, comunicaciones y notificaciones): Parametrizar y publicar clasificados internos de los inmuebles, información general, novedades y notificaciones
(Móvil) Modulo Boton de panico para los conjuntos residenciales
(Móvil) Funcionalidad Manejo de aceptación de habeas data
(Móvil) Modulo Link para acceso a la aplicación Trymi ride
(Móvil) Módulo Chat con vigilancia o portería del conjunto
(Web&Movil) Funcionalidad Pagos por servicios de la app. (Accesos Free, Premium, Total dondes se activan o desactivan funcionalidades)
ROLES:
(Web&Movil) Usuario para rol administrador conjunto
(Web&Movil) Usuario para rol propietario de inmueble
(Web&Movil) Usuario para rol profesionales, es decir personas que ofrecen servicios varios (plomero, carpintero, etc)
(Web&Movil) Usuario para rol comercio, el cual desea publicar clasificados comerciales.
(Web&Movil) Usuario para rol dueño aplicación (admin).
NOTA: El Rol 3 y 4 podría ser el mismo, solo se diferencian en el tipo de venta (uno vende servicios el otro vende productos)
Detalle módulos
MODULO: Servicios virtualizados: Asambleas y votación virtual
FUNCIONALIDADES:
Dos sub-módulos: 1. Asambleas virtuales y 2. Votación virtual
sub-modulo: asambleas virtuales:
los siguientes usuarios podrán tener acceso a este módulo:
*usuario administrador conjunto
*usuario propietario de inmueble
*usuario dueño aplicación (admin).
Detalle:
*(Web&Movil) Registro de asistentes a reunión (al inicio y final de la asamblea) usando firma digital (Por cada inmueble de la unidad residencial).
*(Web) Resguardo de información (actas, asistencias y resultados votación) antes y posterior a la reunión.
*(Web) Generador de actas o memorias.
*(Móvil) Embeber servicio zoom para reuniones virtuales.
Cada unidad residencial tiene un propio acceso y privacidad de su información en relación a la de otros conjuntos.
La aplicación deberá tener estas funcionalidades:
El rol “Administrador de conjunto”, tendrá la opción CRUD para Complejo (se proporcionará diccionario de datos).
nit (pk)
razón social
nombre representante legal, paola romero (aqui debe de haber una relación con usuarios)
conjunto residencial: jardines del retiro
dirección
teléfono
firma digital
valor mínimo admon: $300.000
Valor máximo admon: $350.000
Attachments
Habeas Data F. ( Manejo de aceptación de habeas data).
Nombre Banco pago Administración
Parámetro Link: Banco administración
Plan Acceso I. Funcionalidad Pagos por servicios de la app. (Accesos Free, Premium, Total dondes se activan o desactivan funcionalidades)
Campos de Auditoria (CreatedOn, CreateBy, ModifiedOn, ModifiedBy)
Los roles “”, “”, tendrán la opción CRUD de Propiedad (se proporcionará diccionario de datos).
Conjunto residencial: Jardines del retiro, campo por default y readOnly, debe traer el conjunto al que pertenece al momento de la creación
Tipo de propiedad, [Apartamento, casa, lote, local] - tabla tipo parámetro (id, codigo, nombre, descripcion, is Enable)
Casa/Apartamento 301
Interior/Bloque 4
Manzana
Propietario: Relacion con Usuario
Rol: Un user account podrá estar asociada con varios inmuebles y por cada uno se tiene su rol independiente, el diferenciador será el conjunto
Otro?
Los roles “”, “”, tendrán la opción CRUD de Usuario (se proporcionará diccionario de datos).
Tipo Documento
Documento
Nombres, Paola
Apellidos, Romero
Firma digital
Teléfono
Celular
Correo electrónico
Attachments (cedula, otros)
Campos de Auditoria (CreatedOn, CreateBy, ModifiedOn, ModifiedBy)
Inmuebles asociados
Tipo de relación con inmueble, [Propietario, arrendatario, apoderado]
Permitir CRUD de transmisión de reuniones. Para ello es necesario embeber una aplicación de streaming existente, en este caso se utilizará zoom que cuenta con Api https://marketplace.zoom.us/docs/guides, https://devforum.zoom.us/, con esta opción se deberá poder embeber url’s que asigne la herramienta sin que el usuario pueda compartir/visualizar su url o credenciales de acceso, por el contrario el usuario del sistema ingresará directamente a la video llamada gracias a un token/credencial de acceso asignado previamente al conjunto completo (revisar plataforma openenglish que cuenta con este funcionalidad).
El servicio de transmisión de reuniones estará asociado a un conjunto residencial, fecha y título del espacio donde se almacenará la información de la sesión o reunión a celebrar, a manera de una biblioteca, (máximo 20 atributos, se proporcionará diccionario de datos)
Título: Asamblea extraordinaria;
Fecha;
Estado sesión: [Abierta, en curso, cerrada];
Agenda: espacio de texto abierto enriquecido (se podrá aplicar formatos, justificación, numerales, tipo letra, etc )
Código Zoom reunión
Tiempo almacenamiento
GeneraCosto
Costo Session Adicional
Relación con el acta de asistencia (también va la relación con los poderes de representación)
Attachment: Información que requieran en word, pdf, imágenes.
El espacio de la sesión o reunión debe ser uniforme a la App, a pesar de contar con un servicio externo de streaming, se debe de diseñar en UI de tal manera que otorgue la sensación de ser un único componente.
Por otra parte es necesario poder parametrizar el costo del servicio de streaming a los propietarios (para el pago se utilizara una pasarela de pagos que por ahora debe sólo mostrar el logo, se establecerá rangos de montos de admon para calcular el cobro, esto lleva una fórmula interna para el cálculo (ejemplo: 0.04% del promedio del rango)). Ver Módulo I. Del presente documento.
Manejo de historial de reuniones:
Se requiere manejar el historial de cada servicio de streaming que se generó, es decir el administrador de la reunión puede guardar la grabación (por un tiempo específico y previamente parametrizado), el cual también dependiendo del plan contratado tendrá un costo el contar con dicho acceso a la grabación de la asamblea. Ver módulo I. Del presente documento, El modo de visualización de los datos del historial de reuniones es.
PREVIO A la reunión:
opción de diligenciamiento de datos de la reunión para almacenamiento:
reunión: sesión 1
fecha: 20 de agosto de 2019
adjuntos: ej. Reglamento conjunto, balance año anterior, etc
post reunión:
fecha 20 de agosto de 2019
actas y minuta generadas (adjuntos)
grabación (se parametriza el tiempo de almacenamiento, luego se borra automáticamente dependiendo el plan elegido por el usuario)
nota: el diccionario de datos podria variar en relación a la definición de los datos de acuerdo al afinamiento del requerimiento que se lleve a cabo semana a semana con el desarrollador
sub-módulo votaciones:
permitir crud de parametrizar votaciones
encabezado:
motivo votación: elegir presidente de junta, debe poder modificar los nombres de postulados
attachments adjuntar imagen o archivo
votos: relación de cada usuario que se conecte.
Resultado votación
Permitir votación de usuarios que no tienen la aplicación instalada: Desde otro dispositivo se podrá ingresar al portal web y en la sala de votación activa poder ver también las votaciones en curso y finalmente poder realizar la votación.
Cuenta Usuario
Conjunto
Apoderado (si/no)
Número apartamento/casa asociado a la cuenta de usuario en ese conjunto.
Para los resultados de la votación, se deberá contar al final con los datos y rankear los resultados de las opciones que se parametricen, visualizando los resultados por medio de dos opciones graficas (barras o torta).
Cada reunión contará con un registro de asistencia el cual estará asociado a cada usuario que ingrese a la sala de reunión y que estará firmado digitalmente por la persona como asistente, desde este registro de asistencia, se podrán generar las actas de asistencia y contenido de la asamblea a modo plantilla, dicha generación de actas tendrá modificable título, logo, asunto, firma del conjunto y/o apoderado. Adicionalmente una cuenta de usuario puede tener asociados más propiedades en esa reunión (poderes de representación). Dicho poder se genera por medio de una autorización generada por el propietario del inmueble y será dirigida al administrador del conjunto, con copia a la persona asignada de poder, quién será el representante en asamblea, dicho poder podrá diligenciarse y enviarse con firma digital.
NOTA:
*La aplicación deberá permitir hacer registro seguro enviando correo electrónico para garantizar que la autenticidad de la persona.
B. MODULO: Link pago administración:
Los siguientes usuarios podrán tener acceso a este módulo
*TODOS
Detalle:
La aplicación deberá permitir Linkear el banco que utilice cada conjunto para el pago de administración además puede modificarse el texto de la descripción de dicha opción.
Ejemplo: Para poder hacer el pago de la administración, realizalo por banco hola mundo y puedes utiliza el link: www.BANCOHOLAMUNDO.COM. (Ver CRUD Conjuntos)
C. MÓDULO: Comercio:
Los siguientes usuarios podrán tener acceso a este módulo
*Usuario Comercio
*Usuario Profesionales
*Usuario dueño aplicación
*Usuario administrador conjunto
*Usuario propietario de inmueble
Se deben tener dos submódulos: Comercio y Profesionales
SUB-Módulo: comercio
registro de usuario comercial con atributos específicos (el diccionario de datos será definido en el desarrollo) para usuario comercio.
Chat privado entre comerciante y cliente, para solicitud de domicilios o información de despacho o servicios. Para todos los usuarios debe existir en el chat la anotación de no envío de datos personales de contacto como teléfono o email, de ser así se debe notificar al usuario dueño de aplicación para bloqueo de usuario. La comunicación comercial entre usuarios debe ser por el chat, lo permitido será enviar datos de direccion para envio de domicilios.
Parametrización Guia de clasificados de la zona y chat al comercio: Por geo referenciación que cuando acceda al logo del comercio me muestre el dato del local y al picar allí redirija al chat para centralizar pedidos. La parametrización podrá visualizarse si el comerciante realiza el pago del servicio. Ver condiciones del presente documento en modulo I.
Métodos de Pagos por acceso a los módulos de la app. La visualización del comercio y proporciones por georeferenciación podrá hacerse por todos los usuarios. Debe con una opción de búsqueda para que el usuario final pueda validar si determinado tipo de comercio disponible en el mapa.
Debe tener la opción por medio google maps de ubicar al usuario en como llegar al comercio.
Puja/Subasta de clasificados por pop con promociones, esta funcionalidad solo está habilitada para comerciantes inscritos. Para usuario comercio y Usuario dueño aplicación
El usuario podrá generar pago de publicidad usando pasarela de pago para estar en comercio sugerido. Esta funcionalidad solo está habilitada para usuario comercio si se encuentra inscrito.
Linea de anuncios con nombres de comercios parametrizable y que sea visualizada por propietarios de los inmuebles de los conjuntos. Esto va para todos los usuarios dependiendo la georeferenciacion.
SUB-Módulo: profesionales
registro de usuario profesional con atributos específicos (el diccionario de datos será definido en el desarrollo) para usuario profesional y dueño de aplicación.
Chat privado entre profesional y cliente (comercio o usuario estándar), para solicitud de domicilios o información de servicios. Para todos los usuarios debe existir en el chat la anotación de no envío de datos personales de contacto como teléfono o email, de ser así se debe notificar al usuario dueño de aplicación para bloqueo de usuario. La comunicación de profesionales con usuarios debe ser por el chat, lo permitido será enviar datos de direccion para envio de domicilios.
Lista de profesionales: Se de contar con un listado maestro con los profesionales q se inscriban a la aplicación, para dicha inscripción se debe contar con máximo campos que se definira su diccionario de datos en el desarrollo de la aplicacion que se definirán acorde lo requerido. Posterior al diligenciamiento el profesional deberá pagar un monto o suscripción a la app que utiliza la pasarela de pago que se defina.
Puja/Subasta de clasificados por push con promociones, esta funcionalidad solo está habilitada para profesionales inscritos. Para usuario comercio y Usuario dueño aplicación.
El usuario profesional podrá generar pago de publicidad usando pasarela de pago para estar en comercio sugerido. Esta funcionalidad solo está habilitada para usuario inscritos.
D. MÓDULO: Comunicaciones del conjunto (Clasificados, novedades, comunicados y notificaciones):
Los siguientes usuarios podrán tener acceso a este módulo
*Usuario administrador conjunto
*Usuario propietario de inmueble
*Usuario dueño aplicación.
Detalle:
Podrá contar con 4 opciones editables que deberán mostrarse tipo push como nuevas notificaciones en el móvil del usuario, estos son:
Novedades: Máximo 2000 caracteres,con posibilidad de adjuntar archivos pdf o imágenes ej: El dia de mañana 20 de febrero habrá un corte de agua por 3 horas.
Notificaciones: Máximo 2000 caracteres, con posibilidad de adjuntar archivos como pdf o imagenes ej.Se iniciara desde mañana la contratación de la empresa de vigilancia del conjunto
Clasificados: Máximo 3000 caracteres con posibilidad de adjuntar archivos como imágenes ej1: Se vende apartamento 3 alcobas, 2 baños, valor 260.000.000. Ej2: Se busca plomero para revisar la tubería del conjunto.
Comunicados: Máximo 3000 caracteres con posibilidad de adjuntar archivos como PDF. En caso de comunicados a personas morosas debe llegar notificación a su móvil y a su correo electrónico. Se podrá enviar citación a asambleas adjuntando los pdf que se requieran.
E. MODULO: Boton de panico para los conjuntos residenciales
Dirigido a los siguientes usuarios
Usuario administrador conjunto
Usuario propietario de inmueble
Usuario comercio
Usuario dueño aplicación
Detalle:
Se debe contar con la posibilidad de oprimir un botón que permita parametrizar el motivo del llamado a pánico, ya sea un evento natural como terremoto o algún evento que ponga en peligro la seguridad del conjunto. Se requiere que la persona al oprimir pánico acepte la anotación que generaría el sistema donde se recuerde la responsabilidad de oprimir el botón y si considera que es un suceso de alta prioridad por favor continúe, posteriormente debe especificar algunos campos que se solicitarían como por ejemplo:
Descripción breve del suceso,
Prioridad: lista desplegable desplegable describiendo prioridad 1, 2 , 3,
Descripción: Detalle de lo ocurrido,
Contacto cuadrante: mostrará el número del cuadrante de la zona.
Contacto de quien genera: Campo opcional.
Para los conjuntos:
Cuando se envíe el estado de pánico a los usuarios del conjunto debe aparecer q usuario y de qué apto reporta, con esto se deberá enviar una notificación push a todos los usuarios adscritos al conjunto y la administración del mismo donde se genere un sonido de sirena para dicha notificación.
Para el comercio: Se enviará estado de pánico a otros comercios cercanos, deberá mostrar la dirección y usuario quien reporta con sonido de sirena para dicha notificación.
Para todos los casos se tendrá la opción de reportar por otros usuarios si se considera que alguien ha hecho uso inadecuado de la funcionalidad, de ser así la administración podrá bloquear la funcionalidad al usuario reportado.
F. MODULO: Manejo de aceptación de habeas data
Dirigido a los siguientes usuarios
Usuario administrador conjunto
Usuario propietario de inmueble
Usuario comercio
Detalle:
Al momento de obtener la solicitud de registro a la aplicación de un nuevo usuario (Aplica para todos los usuarios que sean creados), el sistema debe mostrar las anotaciones con las condiciones de habeas data las cuales serán parametrizables (CRUD), dichas condiciones son obligatorias y se deberán aceptar para poder continuar con el proceso de creación y/o acceso a la App. Esta aceptación del usuario deberá poder rastrearse en la auditoría de la aplicación y adicionalmente debe de quedar un registro por correo electrónico de dicha aceptación.
G. MODULO: Link para acceso a la aplicación Trymi ride
Dirigido a los siguientes usuarios
Usuario administrador conjunto
Usuario propietario de inmueble
Usuario dueño aplicación
Debe permitir linkear la aplicación a otra app y en este caso será Trymi ride. Se podrá modificar el texto de la descripción y el link de dicha opción (solo administrador del sistema).
H. MÓDULO: Chat con portería del conjunto
Dirigido a los siguientes usuarios
Usuario administrador conjunto
Usuario propietario de inmueble
Usuario dueño aplicación
Detalle:
Se podrá tener un chat directo a la portería donde por este medio se notificará entrega de paquetes, autorizar ingreso de personal con los soportes, o temas de seguridad de baja prioridad del conjunto.
I. MÓDULO: Métodos de Pagos por acceso a los módulos de la app.
(Elección entre Tres modalidades de pago donde se activan o desactivan funcionalidades)
Dirigido a los siguientes usuarios
Usuario administrador conjunto
Usuario comercio
Usuario propietario de inmueble
Usuario dueño aplicación
Para los conjuntos:
Este método de acceso a la aplicación se elige en el momento de la creación del usuario “Administrador de conjunto”, estas podrían modificarse en caso de requerir variaciones en los accesos y precios:
Forma de pago 1 para acceso a la app (Full access): Permite acceso ilimitado a todas las funcionalidades:
*Link Pago admon: Linkear el banco que utilice cada conjunto para el pago de administración
*Comercio: Visualización de comercio de la zona y promociones.
*Clasificados, novedades, comunicados y notificaciones: Para administración podrá parametrizar y publicar clasificados internos de los inmuebles, información general, novedades y notificaciones. Para los propietarios: Podrán publicar clasificados sin costo.
*Boton de panico para los conjuntos residenciales
* Link para acceso a la aplicación Trymi ride
*Chat con vigilancia o portería del conjunto
En el caso de el modulo de Asambleas y votación virtual:
*Permite acceso a 4 asambleas en 1 año, entonces la app deberá tener un contador interno donde se especifique cuántas asambleas se han realizado en ese periodo de tiempo, en caso de llegar a la 4a y queriendo usar una 5a, se deberá mostrar la opción de pago usando la pasarela que se determine.
*Almacenamiento permanente de historial de asambleas virtuales y consolidado resultados de votaciones
Forma de pago 2 para acceso a la app (Medium access):
*Link Pago admon: Linkear el banco que utilice cada conjunto para el pago de administración
*Comercio: Visualización de comercio de la zona y promociones.
*Clasificados, novedades, comunicados y notificaciones: Para administración podrá parametrizar y publicar clasificados internos de los inmuebles, información general, novedades y notificaciones. Para los propietarios: Podrán publicar clasificados sin costo.
*Boton de panico para los conjuntos residenciales
* Link para acceso a la aplicación Trymi ride
*Chat con vigilancia o portería del conjunto
En el caso de el modulo de Asambleas y votación virtual:
*Permite acceso a 2 asambleas en 1 año, entonces la app deberá tener un contador interno donde se especifique cuántas asambleas se han realizado en ese periodo de tiempo, en caso de llegar a la 2a y queriendo usar una 3a, se deberá mostrar la opción de pago usando la pasarela que se determine.
*Almacenamiento historial de asambleas virtuales y consolidado resultados de votaciones por un tiempo de 2 meses, después de este tiempo tendrá cobro y se parametrizar en el transcurso del desarrollo.
Forma de pago 3 (Open access for demain):
Acceso ilimitado:
*Link Pago admon: Linkear el banco que utilice cada conjunto para el pago de administración
*Comercio: Visualización de comercio de la zona y promociones.
*Boton de panico para los conjuntos residenciales
*Link para acceso a la aplicación Trymi ride
*Chat con vigilancia o portería del conjunto
Acceso limitado:
Clasificados, novedades, comunicados y notificaciones:
*Para administración: Se podrán generar 4 envíos mensuales en total entre notificaciones, novedades, comunicados y clasificados remitidos por la administración, entonces la app deberá tener un contador interno donde se especifique cuántas envíos se han realizado en ese periodo de tiempo, en caso de llegar a la 4o envío y queriendo usar un 5to envío, se deberá mostrar la opción de pago usando la pasarela que se determine.
*Para los propietarios de inmuebles: Podrán publicar clasificados pero en la acción se mostrar la opción de pago acorde la pasarela que se estime usar.
En el caso de el modulo de Asambleas y votación virtual:
*Permite acceso a 2 asambleas en 1 año, entonces la app deberá tener un contador interno donde se especifique cuántas asambleas se han realizado en ese periodo de tiempo, en caso de llegar a la 2a y queriendo usar una 3a, se deberá mostrar la opción de pago usando la pasarela que se determine.
*Almacenamiento historial de asambleas virtuales y consolidado resultados de votaciones que tendrá cobro y se parametrizar en el transcurso del desarrollo.
Para el comercio/profesionales:
Acceso limitado: A todas los y se requiere cobro para acceder a la plataforma específicamente a la funcionalidad de Comercio.
Categoría Programación y Tecnología
Subcategoría Programación de Apps. Android, iOS y otros
¿Cuál es el alcance del proyecto? Crear una aplicación nueva
¿Es un proyecto o una posición? Un proyecto
Actualmente tengo Tengo las especificaciones
Disponibilidad requerida Según se necesite
Plataformas requeridas Android, iPhone, Otro
Plazo de Entrega: No definido
Habilidades necesarias