# Entrada Simplificada: un solo toggle global + ampliar a gastos, socios y promesa

- **Fecha:** 2026-08-01
- **Rama:** `feat/simplified-input-expand`
- **Estado:** diseño aprobado en brainstorming, pendiente de plan.
- **Motivación:** el "modo simplificado" (escribir montos sin ceros, `1500` → `$1.500.000`) hoy se aplica solo en crédito y pago, con toggles por área. Se quiere: (a) **un único toggle global** del que dependan todas las áreas (se eliminan los toggles "En créditos"/"En pagos"), y (b) **ampliar** la función a los 3 inputs de dinero que hoy no la tienen: **gastos**, **aportes/retiros de socios** y el **monto prometido** de la visita "no paga hoy".

## Cómo funciona hoy (auditado)

- **Backend — `CompanyFinancialSettings`** (tabla `company_financial_settings`, 1:1 con `Company`):
  - `simplified_input_enabled` (bool) — maestro; `simplified_input_multiplier` (uint, def 1000); `simplified_input_contexts` (json, p. ej. `['pwa_credit_create','pwa_payment_create']`); `simplified_input_require_confirm` (bool).
  - `isSimplifiedInputEnabled(?string $context = null)` — con contexto: maestro **y** contexto en el array; sin contexto: solo el maestro. `convertSimplifiedToReal($v)` = `$v * multiplier`.
- **API PWA — `SettingsController`**: `buildSettingsPayload()` expone `simplified_input: { enabled, credit_enabled, payment_enabled, multiplier, require_confirm }`; `update()` reconstruye `simplified_input_contexts` a partir de flags `simplified_input_credit`/`simplified_input_payment`.
- **PWA — store `stores/settings.js`**: getters `isCreditSimplifiedEnabled`, `isPaymentSimplifiedEnabled`, `multiplier`, `requireConfirm`.
- **Componente `components/forms/SimplifiedAmountInput.vue`**: prop `context: 'payment'|'credit'`, badge ×multiplicador + preview "Monto real" + checkbox de confirmación. **Emite el valor crudo**; el backend convierte vía flag `is_simplified_amount`.
- **Aplicado en:** `CreditCreateView` (context `credit`; backend `StoreCreditRequest::prepareForValidation` re-convierte) y `PaymentView` (context `payment`).
- **Back-office Filament** (`CompanySettings.php`): ya es **master-only** (sin toggles por área; activa ambos contextos juntos con el maestro). → el cambio alinea la PWA con Filament.
- **Los 3 huecos:** `ExpenseCreateView`, `PartnerTransactionView`, `NoPaymentModal.promised_amount` (inputs crudos; sus controladores sin conversión).

## Decisiones (del brainstorming)

1. **Un solo toggle global.** Se **eliminan** los toggles por área "En creación de créditos" y "En registro de pagos". El gating de **todas** las áreas (crédito, pago, gastos, socios, promesa) pasa a depender **solo** de `simplified_input_enabled` (maestro).
2. **Ampliar a las 3 áreas:** gastos, socios y promesa de pago.
3. Se **reutiliza** `SimplifiedAmountInput` + la confirmación global + el multiplicador (sin cambios).

## Diseño

### Backend
1. **Gating master-only.** `isSimplifiedInputEnabled(?string $context = null)` pasa a devolver **solo el maestro** (`(bool) $this->simplified_input_enabled`), ignorando el `$context` (se conserva el parámetro para no romper firmas). El array `simplified_input_contexts` queda **vestigial** (ya no gatea; NO se borra la columna — sin migración). Los callers actuales (`StoreCreditRequest`, `StorePaymentRequest`) siguen funcionando (ahora gatean por maestro).
2. **Payload** `SettingsController::buildSettingsPayload()`: `simplified_input.enabled` = maestro. Se mantienen `credit_enabled`/`payment_enabled` = maestro (baja fricción: los consumidores actuales no cambian) — o se exponen como alias del maestro.
3. **`SettingsController::update()`**: deja de manejar `simplified_input_credit`/`simplified_input_payment`; solo persiste `simplified_input_enabled` + `simplified_input_multiplier` + `simplified_input_require_confirm`. (El `contexts` se puede fijar a todos-o-vacío; no afecta el gating master-only.)
4. **Conversión + validación** en los 3 endpoints nuevos, patrón de créditos (monto **crudo** + flag `is_simplified_amount`; si el flag viene **y** `isSimplifiedInputEnabled()` (maestro) es true → `convertSimplifiedToReal()`; defensa en profundidad). Aceptan `is_simplified_amount`/`simplified_amount_confirmed` opcionales:
   - `ExpenseController::store` (gastos)
   - `PartnerController::storeTransaction` (socios)
   - el endpoint que persiste `promised_amount` del flujo "no paga hoy" (el plan lo localiza)
5. **Tests backend (TDD):** por endpoint nuevo — con maestro **on** + flag, `1500` (×1000) se guarda `1.500.000`; con **off**/sin flag, `1500` crudo. + un test que confirme que crédito/pago siguen gateando por el maestro tras el cambio. Ver [[credify-test-db]], [[credify-ci-phpstan-preflight]].

### Frontend (PWA)
6. **Store `settings.js`:** los getters `isCreditSimplifiedEnabled`/`isPaymentSimplifiedEnabled` (y un `isSimplifiedInputEnabled`) resuelven **todos al maestro** (`simplified_input.enabled`). Baja fricción: los consumidores actuales (`CreditCreateView`, `PaymentView`) no cambian su computada.
7. **`SimplifiedAmountInput.vue`:** el gating (`isSimplified`) pasa a leer el **maestro** para **todos** los contextos; se amplía `context` para aceptar `'expense'|'partner'|'promise'` (el prop queda como etiqueta, no afecta el gating). Crédito/pago sin cambios de comportamiento (su getter ahora = maestro).
8. **Cablear los 3 formularios** — reemplazar el `<input type="number">` crudo por `<SimplifiedAmountInput :context="…" v-model v-model:confirmed="amountConfirmed">`, con `isSimplifiedEnabled`/`requireConfirmation` desde el store, gate del submit sobre `amountConfirmed` cuando aplique, y enviar `is_simplified_amount`/`simplified_amount_confirmed`:
   - `ExpenseCreateView.vue` (`expense`), `PartnerTransactionView.vue` (`partner`), `NoPaymentModal.vue` (`promise`, sobre `promised_amount` — **opcional**: no convertir/enviar flag si va vacío).
9. **`CompanySettingsView.vue`:** **eliminar** los toggles "En creación de créditos" y "En registro de pagos" (y su estado/guardado); dejar solo el maestro + multiplicador + "Pedir confirmación". Texto de ayuda bajo el maestro: *"El modo simplificado aplica a créditos, pagos, gastos, aportes de socios y promesas de pago."*

## No-objetivos / límites
- **No** borrar la columna `simplified_input_contexts` (queda vestigial; sin migración).
- **No** cambiar el multiplicador ni la confirmación (globales).
- **No** unificar la inconsistencia crédito(flag)/pago(envía real) — las áreas nuevas siguen el patrón de **crédito** (flag + backend convierte).
- **No** tocar el back-office Filament (ya master-only).

## Riesgos / gotchas
- **Cambio de comportamiento:** una empresa con maestro **on** pero un área **off** (config inusual, hoy posible) verá esa área ahora **simplificada**. Aceptado (es el objetivo: todo depende del maestro). Sin migración de datos (el `contexts` se ignora).
- **Doble multiplicación:** el componente emite crudo y el backend convierte — ningún form nuevo debe pre-convertir en el cliente (patrón crédito, no pago). Los tests lo blindan.
- **Promesa opcional:** `promised_amount` puede ir vacío → no convertir/enviar flag si no hay monto.
- **PHPStan level 5** sobre el backend nuevo antes de push. Ver [[credify-ci-phpstan-preflight]].
- **Sin tests JS** de la PWA → build + revisión + validación en dispositivo.
- **Deploy full** (assets + backend). Ver [[credify-prod-vm]].

## Verificación
- Tests backend nuevos verdes (3 endpoints) + crédito/pago siguen gateando por maestro + suite completa + PHPStan + Pint.
- `npm run build` sin errores; en Ajustes quedan **3** controles (maestro + multiplicador + confirmación), sin los 2 toggles por área.
- Validación en dispositivo: con maestro **on**, en crédito/pago/gastos/socios/promesa escribir `1500` → preview `$1.500.000` → confirmar → se persiste `1.500.000`; con **off**, crudo.
- CHANGELOG.