cheveguerra/Kelloggs_v4
1
0
Fork 0
mirror of https://github.com/KeymonSoft/Kelloggs_v4.git synced 2026-04-20 11:39:13 +00:00
Code Issues Packages Projects Releases Wiki Activity

- VERSOIN 5.11.26

Browse Source 
- Se agregó le descripcion del "flujo" de las promociones en C_Promos
This commit is contained in:
Jose Alberto Guerra Ugalde
2025-11-30 02:32:36 -06:00
parent 749cf6e7fe
commit 7a88acaf4c
13 changed files with 442 additions and 88 deletions
Download Patch File Download Diff File Expand all files Collapse all files

68
B4A/C_Promos.bas
View File

@@ -4,6 +4,74 @@ ModulesStructureVersion=1
Type=Class
Version=11.5
@EndOfDesignText@
Sub Descripcion
' *** FLUJO DE LAS PROMOCIONES ***
' Aquí está el desglose del flujo actual de decisión para mostrar una promoción, calculando los máximos y aplicando las restricciones de Segmentación, Inventario y Trade Spending (Bonificaciones).
'
' ### Flujo Maestro: ¿Se muestra la promo y cuántas alcanzan?
'
' El proceso se ejecuta secuencialmente. Si en algún punto el resultado es 0, la promoción no se muestra o se marca como agotada.
'
' #### 1. Cálculo de Límites Administrativos (La Base)
'
' Lo primero que hace el sistema es determinar el "Techo Teórico" de cuántas promociones se pueden vender Sin mirar inventario ni dinero aún.
' * **Paso A: Datos Generales:** Se obtienen los límites configurados en `PROMOS_COMP`: Máximo por Cliente, Máximo Recurrente y Máximo Global.
' * **Paso B: Lógica de Promociones Segmentadas:** Aquí entra el filtro crítico.
' * El sistema consulta `HIST_CLIENTE_CANT_PROMOS`.
' * **Si la promo es segmentada:**
' * Si el cliente **NO** está en la lista: Se establecen todos los máximos a 0. La promo se oculta.
' * Si el cliente **SÍ** está en la lista: Se ignoran los límites generales y se usan los específicos asignados al cliente.
' * **Fórmula:** `MaxDisponible = Asignado - Vendido`.
' * **Paso C: Cálculo del Mínimo:** Se comparan todos los límites (Global, Recurrente, Cliente/Segmentado) y se toma el **valor más pequeño** como el `MaxPromos` inicial.
'
' #### 2. Restricción por Inventario de Productos FIJOS
'
' Una vez que sabemos cuántas *podríamos* vender administrativamente, revisamos si tenemos los productos obligatorios (Fijos).
' * El sistema itera sobre cada producto fijo de la promoción.
' * **Cálculo:** `InventarioDisponible / PiezasRequeridasPorPromo`.
' * **Resultado:** El `MaxPromos` se actualiza al **mínimo** entre el valor del Paso 1 y lo que permite el inventario de cada producto fijo.
' * *Nota Crítica:* Si este valor es 0, la promo se marca como "KO" (No disponible).
'
' #### 3. El Cruce de Inventarios (La Resta)
'
' Este es el punto que mencionaste y es vital en el flujo actual. Antes de evaluar si alcanzan los productos variables, el código **simula la venta de los productos fijos**.
' * Se toma el mapa de inventario actual.
' * Se ejecuta `restaFijosDePromo`.
' * **Acción:** Para cada producto fijo, se resta: `(MaxPromosCalculado * PiezasRequeridas)`.
' * **Resultado:** Se genera un *Nuevo Mapa de Inventario Virtual* que contiene solo lo que sobró después de apartar lo necesario para la parte fija. Este mapa es el que se pasa a la siguiente etapa.
'
' #### 4. Cálculo de Variables y Restricción de Trade Spending (TS)
'
' Aquí es donde la lógica se vuelve compleja y utiliza los bucles iterativos para validar tanto existencia física como presupuesto financiero (Bonificaciones).
' Se ejecuta `revisaMaxPromosProdsVariablesPorInventario`, que usa el *Inventario Virtual* del paso anterior.
' **El Bucle de Validación (Paso a Paso):**
' El código prueba vender 1 promo, luego 2, hasta llegar al `MaxPromos` calculado en el paso 2.
' 1. **Iteración `x` (Número de promos a probar):**
' 2. **Consumo de Fijos en Variables:** Si un producto variable *también* es fijo, el código descuenta (otra vez) el inventario necesario para la parte fija dentro de este bucle para asegurar integridad.
' 3. **Suma de Inventario Variable:** Se suman las existencias de todos los productos que califican como variables para esta promo.
' 4. **Validación de Trade Spending (El Presupuesto):**
' * Dentro del bucle, para cada producto variable disponible, se llama a `ts.traeBonificacionesMaximas`.
' * **La Lógica de ts:** El sistema verifica si el producto actual califica como bonificación (precio especial/cero).
' * **Si califica:** Verifica si hay saldo en el presupuesto de "BONIFICACIONES". Si no hay saldo, este producto variable **no se cuenta** como disponible para armar la promo en esta iteración.
' * **Si NO califica:** (Es un producto de precio normal dentro de la promo), no consume presupuesto y se cuenta libremente según su inventario físico.
' 5. **Prueba de Fuego:**
' * Se compara: `InventarioVariableValidado (Físico + Financiero)` vs `(PiezasVariablesRequeridas * x)`.
' * Si alcanza, el ciclo continúa para probar `x + 1`.
' * Si no alcanza, el ciclo se rompe y se define el máximo posible.
'
' ### Resumen del Factor TS en el Flujo
'
' El presupuesto de ts no bloquea la promo "per se", sino que **filtra qué productos variables están disponibles**.
' * Si la promo pide 3 variables.
' * Tienes 5 opciones en inventario físico.
' * 2 opciones son "Bonificación" (consumen presupuesto) y 3 son venta normal.
' * **Escenario Sin Presupuesto:** Al iterar, `ts.traeBonificacionesMaximas` devolverá 0 para los 2 productos de bonificación. El sistema solo verá 3 productos disponibles (los normales).
' * **Resultado:** Como la promo pide 3 y el sistema "ve" 3 disponibles, la promo **SÍ SE MUESTRA**.
' * **Bloqueo:** Solo se bloquearía si la promo pidiera 4 variables, ya que Sin presupuesto ts solo "vemos" 3 productos disponibles, insuficientes para armar el paquete.
'
' ### Este flujo garantiza que la promo se muestre siempre que sea *físicamente* posible armarla, restringiendo la parte financiera solo a los ítems que realmente cuestan dinero al presupuesto de bonificaciones.
End Sub
Sub Class_Globals
Private Root As B4XView 'ignore
Private xui As XUI