BONOPARK SL

BONOPARK SL és una societat mercantil espanyola constituïda l'any 2009. D'acord amb la fitxa registral, té la consideració de societat activa i un capital social d'1.000.000 d'euros. La ubicació que consta és Madrid.

El corpus no permet determinar amb precisió l'objecte social ni l'activitat econòmica concreta més enllà de la classificació sectorial genèrica ("Altres"). Les dades disponibles són exclusivament registrals i no inclouen informació sobre el producte o servei que oferia.

La constitució de la societat es data el 2009. Les primeres anotacions del corpus provenen de 2013 i corresponen a nomenaments d'apoderats, amb números de tom i full corresponents a Navarra (T 1470, F 7, S 8, H NA 29212), cosa que indica que el domicili registral original era en aquesta comunitat. Posteriorment, les anotacions passen a fer referència a Madrid (T 32615, F 211, S 8, H M 587043), cosa que suggereix un trasllat de domicili, tot i que el corpus no ho documenta explícitament.

Entre els fundadors i administradors que consten figuren VITAL HUICI MIGUEL, PERURENA BOROBIA RAMON i PEREZ MORENO DOMINGO, en qualitat de consellers.

El corpus no conté informació sobre l'activitat comercial, els clients o el model de negoci de BONOPARK SL. La classificació sectorial disponible és "Altres", sense més concreció. No consta cap descripció de producte o servei a les fonts consultades.

El corpus no inclou dades financeres (facturació, resultats, plantilla) ni indicadors de creixement. L'única dada rellevant és l'ampliació de capital de 375.000 euros registrada el 3 de març de 2014, que va situar el capital subscrit en 1.000.000 d'euros, segons el BORME (BOE/BORME, 2014-03-03).

També consta que el 2018 es va nomenar ERNST & YOUNG SL com a auditor de comptes (anotació de 19 de juliol de 2018) i que el nomenament es va revocar el 2019 per a l'exercici tancat a 31 de desembre de 2018. Aquestes dades són registrals i no permeten valorar l'acompliment econòmic de la societat.

BONOPARK SL no consta com a tancada. L'estat registral és actiu i la darrera anotació disponible és de l'11 de juliol de 2025 (nomenament d'apoderada: DIAZ DEL CONSUELO ANA MARIA), segons el BORME.

El que sí que documenta el registre és un canvi de control: el 14 d'agost de 2019, PERURENA BOROBIA RAMON va cessar com a administrador únic i va ser substituït per LLORENTE BUS SL, amb ALONSO SOROA VALENTIN com a representant. El 14 de febrer de 2022, LLORENTE BUS SL va cessar i va ser substituïda per AVANZA MOVILIDAD INTEGRAL SL, també amb ALONSO SOROA VALENTIN com a representant. Aquestes són transmissions de control, no un tancament.

Atès que la societat continua activa, no es pot parlar d'herència en el sentit de llegat d'una empresa desapareguda. El corpus no permet identificar cap activitat, marca o actiu que hagi transcendit de manera autònoma.

El corpus només permet afirmar el següent:

• VITAL HUICI MIGUEL consta com a conseller.
• PERURENA BOROBIA RAMON consta com a conseller i va exercir com a administrador únic fins al cessament de 14 d'agost de 2019.
• PEREZ MORENO DOMINGO consta com a conseller.

No consta cap informació sobre la seva trajectòria posterior, altres càrrecs o activitats. Per completar-ho caldria consultar el Registre Mercantil de Madrid (full H M 587043) i les bases de dades de càrrecs societaris, que no formen part del corpus disponible.

• El registre mercantil documenta canvis de control (cessaments i nomenaments d'administrador únic) però no explica les raons estratègiques: per interpretar una substitució com la de LLORENTE BUS SL per AVANZA MOVILIDAD INTEGRAL SL cal creuar la informació registral amb fonts corporatives o periodístiques, que aquí no consten.
• La successió d'apoderats en bloc (2019) sol acompanyar un canvi de control o una reestructuració interna; en anàlisi registral, és un indicador a seguir, no una prova per si sol.
• L'ampliació de capital de 2014 fins a 1.000.000 d'euros i la designació d'un auditor el 2018 són senyals d'una estructura societària formalitzada; tanmateix, sense comptes dipositades al corpus no se'n pot inferir solvència ni rendibilitat.
• El trasllat d'anotacions de Navarra a Madrid recorda que la seu registral pot canviar sense que això impliqui canvi d'activitat: cal verificar-ho sempre al full registral corresponent.

El registre mercantil no descriu l'activitat de BONOPARK SL: només noms, càrrecs i dates [BORME/OpenMercantil, 2025-07-11]. El que sí que és verificable és el perfil: una societat de 2009, amb capital d'1 M€ des de l'ampliació de març de 2014 [BOE/BORME, 2014-03-03], auditada per Ernst & Young per al exercici 2018 [BORME, 2019-11-14], i que el 2019 passa a estar administrada per Llorente Bus SL i el 2022 per Avanza Movilidad Integral SL [BORME, 2019-08-14; BORME, 2022-02-14].

La lectura raonable —i cal dir-ho clarament: inferència, no fet— és que BONOPARK operava en l'espai de l'aparcament i la mobilitat urbana, i que va acabar integrada en el perímetre d'un operador de transport. La proposta d'avui seria reconstruir aquesta essència com una capa digital d'aparcament i intermodalitat: una app i un backend que connectin places d'aparcament (públiques, privades i de rotació) amb operadors de mobilitat compartida i transport públic, venent accés i dades en lloc de maons.

No disposem de xifres verificades del mercat original de BONOPARK. El que sí que podem afirmar és que el segment d'aparcament urbà digitalitzat i intermodalitat té actors consolidats a Espanya i Europa, i que els socis registrals de BONOPARK (Llorente Bus, Avanza) són operadors de transport col·lectiu, cosa que suggereix un model B2B/B2G més que no pas B2C pur.

Com a estimació a validar: una ciutat mitjana espanyola pot tenir entre 5.000 i 30.000 places d'aparcament regulat, i la digitalització d'una fracció d'aquestes sol generar ingressos recurrents per transacció i per subscripció d'operador. Aquestes xifres són un rang de treball, no una dada contrastada.

Proposta (no verificada com a model original):

• SaaS per a operadors d'aparcament: gestió de places, reserves i pagament, amb quota mensual per instal·lació. Estimació: 200–800 €/mes per operador, a validar.
• Comissió per transacció en reserves i pagaments in-app. Estimació: 3–8 % del valor de la transacció, a validar.
• Venda de dades agregades d'ocupació i flux a administracions i operadors de mobilitat, amb compliment estricte de RGPD.
• Integració amb operadors de transport (el perfil dels socis registrals encaixa aquí): API perquè un operador de bus integri l'aparcament dissuasiu a la seva app.

1. Mesos 0–3: validar el nínxol amb 5–10 operadors d'aparcament i 1–2 operadors de transport. Producte mínim: reserves + pagament + panell d'ocupació.
2. Mesos 3–9: pilot en una ciutat, amb un operador d'aparcament i un de transport. Mètrica clau: ocupació induïda i retenció d'usuaris.
3. Mesos 9–18: comercialització a 3–5 ciutats, API pública per a operadors, primers contractes de dades.
4. Mesos 18–36: expansió i possible integració amb un operador de mobilitat (el camí que el registre suggereix que va fer l'empresa original).

Totes les xifres són estimacions a validar, no dades de l'empresa:

• Equip fundacional (2 devs + 1 producte + 1 comercial): 180.000–260.000 €/any.
• Desenvolupament del MVP (app, backend, pagaments, panell): 80.000–150.000 €.
• Pilot i integracions amb operadors: 30.000–60.000 €.
• Legal, RGPD, comptabilitat i assegurances: 15.000–25.000 €/any.
• Màrqueting i vendes inicials: 30.000–50.000 €.
• Total orientatiu any 1: 350.000–550.000 €, a validar amb proveïdors i socis reals.

• Risc d'identitat: no sabem què feia BONOPARK; reconstruir "la mateixa essència" és una hipòtesi, no una certesa. Cal validar-la abans d'invertir.
• Risc de mercat: l'aparcament digital té actors consolidats i marges pressionats; la diferenciació per intermodalitat és la palanca més plausible.
• Risc regulatori: dades de mobilitat i pagaments exigeixen compliment RGPD i PSD2.
• Risc de dependència: si el model depèn d'un sol operador de transport, el poder de negociació és feble.
• Risc financer: el capital d'1 M€ de l'empresa original no garanteix que el nou projecte en necessiti el mateix; l'estimació dalt és molt inferior.

Les lliçons de l'expedient original, més enllà del currículum dels socis:

1. El registre no és el negoci: les actes diuen qui mana i quan, no què es ven. Qualsevol reconstrucció ha de començar per validar l'activitat real, no per assumir-la.
2. Els socis importen més que el pla: BONOPARK va passar per mans d'operadors de transport; un projecte de mobilitat avui necessita un soci operatiu des del dia u, no un inversor passiu.
3. L'auditoria és un senyal, no una garantia: Ernst & Young auditava els comptes el 2018 i el 2019 es revoca el nomenament [BORME, 2019-11-14]; els canvis de control solen precedir canvis de rumb.
4. Capital social alt ≠ capital disponible: 1 M€ de capital des del 2014 no diu res sobre la caixa real; el nou projecte ha de dimensionar-se per fases.
5. Qui ho hauria de fer: un equip petit (producte + enginyeria + vendes B2B) amb un soci operatiu de mobilitat o aparcament que aporti places i legitimitat, i un pla de validació de 90 dies abans de comprometre capital.

El model que descriuen les dades registrals de BONOPARK SL (font: OpenMercantil, 2025-07-11) és el d'un operador de mobilitat amb una capa de governança complexa: un administrador únic que és una altra societat (AVANZA MOVILIDAD INTEGRAL SL, des del 2022-02-14), una desena d'apoderats nomenats en bloc el 2019 i revocacions puntuals posteriors (per exemple, HIDALGO SALCEDO JOSE LUIS el 2023-12-28). Això és símptoma d'un negoci on la capacitat d'actuar en nom de l'empresa (reservar places, signar acords amb pàrquings, facturar) està repartida entre moltes persones i societats, i on cada canvi de poder genera risc operatiu i legal.

El problema concret que resoldria la plataforma és: cap operador pot saber, en temps real, qui pot fer què, sobre quina plaça d'aparcament, amb quin marge, i qui ha de cobrar a qui. En un negoci de mobilitat amb places reservades i flota compartida, els errors típics són places venudes dues vegades, liquidacions entre operadors que es fan a mà en fulls de càlcul, i apoderats que actuen amb permisos que ja han estat revocats. La plataforma resol la reserva, la delegació de permisos i la liquidació en un sol flux auditable.

Arquitectura de microserveis amb un nucli de domini únic (monòlit modular) i serveis satèl·lit, perquè el domini de reserves i liquidació és transaccional i no es pot repartir sense cost.

``` [Apps mòbil conductor] [Backoffice operador] [Portal pàrquing] | | | +---------- API Gateway (Kong) --------------+ | +--------------------+---------------------+ | | | [reserves-svc] [flota-svc] [permisos-svc] (PostgreSQL) (PostgreSQL) (PostgreSQL + audit log) | | | +----------> [liquidacio-svc] <-----------+ (PostgreSQL + outbox) | [Kafka] -> [notificacions-svc] | [data warehouse (ClickHouse)] ```

Decisions i motius:

• Monòlit modular per a reserves i liquidació, no microserveis purs. La reserva i la seva liquidació han de ser atòmiques; separar-les en serveis amb consistència eventual introdueix doble venda de places. Es desplega com un sol artefacte amb mòduls interns ben delimitats.
• `permisos-svc` separat i amb log d'auditoria append-only. El registre mercantil mostra que els poders es nomenen i es revoquen (2023-12-28: nomenament i revocació del mateix apoderat el mateix dia). El sistema ha de poder respondre "qui podia fer què el dia X" amb proves. Un log immutable és requisit legal, no un extra.
• Outbox pattern + Kafka per a liquidacions. La liquidació entre operadors ha de ser exactament-una-vegada; l'outbox garanteix que un pagament no es perd ni es duplica si cau un servei.
• PostgreSQL per a tot el transaccional. Les reserves necessiten rangs de dates i exclusió de solapaments; PostgreSQL amb `EXCLUDE USING gist` ho resol nativament sense infraestructura addicional.
• ClickHouse per a analítica. Les consultes d'ocupació per franja i operador no han de tocar la base transaccional.

Esquema simplificat (PostgreSQL). Les taules d'auditoria són append-only amb trigger que bloqueja `UPDATE`/`DELETE`.

```sql -- Actors: persones i societats que poden actuar CREATE TABLE actor ( id UUID PRIMARY KEY, tipus TEXT NOT NULL CHECK (tipus IN ('persona','societat')), nom TEXT NOT NULL, nif TEXT UNIQUE, actiu BOOLEAN NOT NULL DEFAULT true );

-- Poders: qui pot fer què, des de quan i fins quan CREATE TABLE poder ( id UUID PRIMARY KEY, actor_id UUID NOT NULL REFERENCES actor(id), rol TEXT NOT NULL, -- 'apoderat','administrador_unic','representant' abast TEXT NOT NULL, -- 'reserves','facturacio','flota','tot' vigent_des DATE NOT NULL, vigent_fins DATE, -- NULL = sense límit revocat_el DATE, referencia_acte TEXT -- p.ex. 'BORME 2023-12-28' );

-- Places d'aparcament CREATE TABLE plaça ( id UUID PRIMARY KEY, parkings_id UUID NOT NULL, codi TEXT NOT NULL, tipus TEXT NOT NULL CHECK (tipus IN ('turisme','moto','furgoneta','ev')), UNIQUE (parkings_id, codi) );

-- Reserves amb exclusió de solapament per plaça CREATE TABLE reserva ( id UUID PRIMARY KEY, plaça_id UUID NOT NULL REFERENCES plaça(id), conductor_id UUID NOT NULL, inici TIMESTAMPTZ NOT NULL, fi TIMESTAMPTZ NOT NULL, estat TEXT NOT NULL CHECK (estat IN ('pendent','confirmada','cancel·lada','completada')), preu_centims INTEGER NOT NULL, creada_per UUID NOT NULL REFERENCES actor(id), EXCLUDE USING gist ( plaça_id WITH =, tstzrange(inici, fi) WITH && ) WHERE (estat IN ('pendent','confirmada')) );

-- Liquidació entre operadors CREATE TABLE liquidacio ( id UUID PRIMARY KEY, periode_des DATE NOT NULL, periode_fins DATE NOT NULL, operador_id UUID NOT NULL REFERENCES actor(id), import_centims INTEGER NOT NULL, estat TEXT NOT NULL CHECK (estat IN ('calculada','aprovada','pagada')), creat_el TIMESTAMPTZ NOT NULL DEFAULT now() );

-- Auditoria append-only CREATE TABLE audit_log ( id BIGSERIAL PRIMARY KEY, taula TEXT NOT NULL, registre_id UUID NOT NULL, accio TEXT NOT NULL, actor_id UUID, payload JSONB NOT NULL, creat_el TIMESTAMPTZ NOT NULL DEFAULT now() ); ```

Motiu de l'`EXCLUDE`: és l'única manera de fer complir "una plaça no pot tenir dues reserves actives solapades" a nivell de base de dades, no de codi d'aplicació. Si el codi falla, la BD no deixa passar la segona reserva.

API REST versionada (`/v1`), autenticació OAuth2 amb scopes derivats del rol del `poder` vigent. Cada petició porta `X-Actor-Id`; el servei de permisos valida que l'actor té un poder vigent amb l'abast requerit.

Endpoints principals:

``` POST /v1/reserves # crear reserva (valida solapament + poder) GET /v1/reserves/{id} POST /v1/reserves/{id}/cancel·lar GET /v1/places?parkings_id=&inici=&fi= # disponibilitat

POST /v1/permisos # només administrador_unic DELETE /v1/permisos/{id} # revocació (no esborra, marca revocat_el)

GET /v1/liquidacions?periode=2025-06 POST /v1/liquidacions/{id}/aprovar POST /v1/liquidacions/{id}/pagar # idempotent, clau Idempotency-Key

GET /v1/auditoria?taula=reserva&registre_id= ```

Integracions:

• Passarel·la de pagament (Stripe o Redsys) per a cobraments al conductor; webhooks signats i idempotents.
• Sistemes de pàrquing (OCPI o API pròpia) per sincronitzar ocupació real; si no hi ha integració, la reserva és la font de veritat i l'ocupació es reconcilia cada 5 min.
• Registre mercantil / BORME com a font externa per importar canvis de poders. No s'automatitza la validació legal, però el sistema importa els actes i crea un `poder` en estat `pendent_validacio` que un humà aprova.
• Facturació electrònica (FacturaE) per a les liquidacions entre operadors.

Ordre de construcció, amb criteri de "què desbloqueja més valor amb menys risc":

1. `permisos-svc` + `audit_log`. És el fonament legal. Sense saber qui pot fer què, cap reserva és vàlida. Es pot construir en 3-4 setmanes i ja dona valor: substituir els fulls de càlcul de poders.
2. `reserves-svc` amb l'`EXCLUDE` de solapament. El nucli del negoci. Cal validar el flux de reserva → confirmació → cancel·lació amb un sol pàrquing pilot.
3. `flota-svc` bàsic (alta de vehicles i assignació a places).
4. `liquidacio-svc` amb càlcul automàtic per període i aprovació manual. El pagament automàtic ve després.
5. Portal de pàrquing perquè els operadors vegin les seves places i reserves.

No es comença pel portal del conductor ni per l'app mòbil: el valor primer és intern i B2B.

Mides:

• 1 pàrquing pilot: ~200 places, ~5.000 reserves/mes. El sistema ha de suportar 10x sense canvis d'arquitectura.
• `reserves-svc`: ~50 req/s en pic; PostgreSQL amb índex GiST ho absorbeix sense partició fins a ~10M de reserves.
• `audit_log`: creixement lineal amb l'activitat; a 5.000 reserves/mes, ~50 MB/mes. Cal política de retenció de 7 anys (obligació mercantil) i arxiu a object storage.

Riscos tècnics:

• Solapament de reserves sota concurrència. L'`EXCLUDE` ho resol, però cal provar-ho amb càrrega real; un `SERIALIZABLE` mal configurat pot generar errors de serialització en pic. Mitigació: reintents amb backoff al client.
• Poders importats del BORME amb retard. El BORME publica amb dies de retard; un apoderat pot actuar abans que el sistema ho sàpiga. Mitigació: el poder importat neix `pendent_validacio` i no dona accés fins aprovat; el risc residual s'accepta i es documenta.
• Liquidació entre operadors amb dades incompletes. Si un pàrquing no integra ocupació, la liquidació es basa en reserves, no en ús real. Mitigació: marcar la liquidació com a `estimada` i requerir aprovació manual.
• Revocació de poder enmig d'una operació. Un apoderat pot tenir una