---
# System prepended metadata

title: Planes Grouu

---

# Planes Grouu

1. Integración Tecnológica del Holding
2. Independencia Operativa
3. Venta inter puntos de contacto

# Transacción

La transacción como una serie de pasos.

1. **Construcción de ofertas** (Bodega de Producto Terminado) - Business Partner
    1. Cargar Stock
    2. Cargar Ligaduras
    3. Condiciones Financieras
    4. Promociones

- ¿Todo el holding va a entender lo mismo por Stock, Ligaduras, Condiciones Financieras y Promociones?
- ¿Es el Business Partner una característica de la oferta? - (¿Hay doble stock? - Singleton)

2. **Distribuir Ofertas** (Publicación) - Business Partner
    1. Selecciono
    2. ¿Digo dónde?

    Dudas
- ¿La oferta es única?
- ¿Cuál es la granularidad de la oferta?
- Selección y publicación a través de qué canales de distribución. ¿Quién lo decide?
- ¿Cuál es el rol del Owner?

3. **Comprar**
 
    1. Explora
    2. Cotiza
    3. Reserva/oferta
    4. Acuerdo

La estructura de puntos de contacto basado en Broker Centers y marketplace.

El acuerdo tiene una estructura de ledgers
1. Aprobación del cliente
2. Disponibilidad de Stock y Condiciones Comerciales

- ¿Quién decide si los puntos de contacto tienen broker center y/o marketplace?
- ¿Las cotizaciones valen algo?
- ¿El cierre de la transacción se da en la promesa o en el acuerdo?
- ¿Cuán mutable es el Acuerdo - Promesa? ¿Agrega valor?
    - ¿El comprador es mutable?
    - ¿Vendedor es mutable?
    - ¿Condiciones Comerciales son mutables?
    - ¿Stock es mutable?
- ¿Necesitamos el contrato firmado?
- ¿As is o to be de las transacciones?

## Objetivo General

## Objetivo Específico

## Tareas

## Actividades Clave





## Horas Disponibles
Fronteo de interfaz (Vale Diego Piure)
Fronteo
Back





# Historias del MVP

Interfaz
Esto es lo que ud subió
Mensajería Push -> A la unidad proyecto le puedo generar mensajes. Muro infinito.
Mensaje asociado a un proyecto.

~~
~~
~~
~~
~~
~~
~~


Entenderemos un acuerdo como:
- Stock
- Condiciones Comerciales
- Vendedor
- Comprador

En forma de Reserva Confirmada. (Ahora también podríamos entenderla como transacción confirmada.) Otra forma podría ser un documento digital u otra forma de formalizar la transacción, pero como es inventada, da lo mismo.

Confirmar la transacción es una actividad que puede hacer, o el Owner o el Seller. Debe confirmar las cuatro cosas. El problema es que los de criterios de aprobación de los cuatro son laxos en el negocio.

(Algunas inmobiliarias te piden solo el rut para confirmar la transacción de un cliente, mientras que otras te piden más documentación.)

El problema está en determinar cómo se determinan estos cuatro vectores, de forma tal que el Owner o el Seller puedan ejecutar su actividad clave que es confirmar la transacción.

¿Y qué condiciones tienen que darse para que sea el Seller en vez del Owner el que confirme stock?
¿Podría ser el seller sin pasar por el Owner?
NO, porque hay que confirmar la disponibilidad del stock y el riesgo de cartera.
- Por teléfono + Documentación por correo
- Las credenciales de Plan OK o del gestor de stock propio de la inmobiliaria.


## Preguntas




En nuestro criterio experto, el comprador y el vendedor son los únicos inmutables.

Qué caracteriza a un comprador? En capi tenemos un formulario estándar de "crear cliente". Cómo otros puntos de contacto "Crean cliente"?

El Vendedor se caracteriza por

Las Condiciones Comerciales viven en el cotizador

El stock vive en plataforma.

El problema es qué es, cómo se define lo que hay en cada vector?

4) ~~