NAVES Y PARQUES INDUSTRIALES SOCIEDAD ANÓNIMA

NAVES Y PARQUES INDUSTRIALES SOCIEDAD ANÓNIMA era una sociedad anónima constituida en el año 2013 con domicilio en Madrid, clasificada dentro del sector de industria y manufactura. De acuerdo con la ficha registral de OpenMercantil (a partir del BORME), el capital social en el momento de la última anotación era de 158.169,48 €. El estado registral que consta es "transformada".

El corpus no permite precisar el objeto social literal ni la actividad operativa concreta de la compañía. El nombre sugiere actividad relacionada con naves y parques industriales, pero esta lectura no se puede confirmar con los datos disponibles y, por tanto, no se puede afirmar como hecho.

La sociedad se constituyó en 2013. El corpus no aporta detalles sobre los socios fundadores iniciales ni sobre el capital inicial: esta información no consta en las actas disponibles, que comienzan cronológicamente con anotaciones de 2017.

La clasificación sectorial disponible la sitúa en industria y manufactura. Más allá de esta categoría, el corpus no documenta qué productos o servicios ofrecía, ni cuáles eran sus clientes o mercados. Esta información no consta.

El corpus no contiene datos financieros (facturación, resultados, plantilla) que permitan identificar un periodo de expansión o de buen comportamiento. La única evolución patrimonial documentada es la reducción de capital de 2024, que apunta en sentido contrario a una capitalización creciente, pero no se puede interpretar como indicador de resultados sin datos adicionales, que no constan.

Sí que consta actividad orgánica durante estos años: nombramientos de apoderados en 2019 y en 2024, y nombramientos de auditor en los años 2019, 2022 y 2025, lo que indica que la sociedad mantuvo órganos de gobierno y obligaciones de auditoría durante buena parte de su vida.

El corpus no documenta la causa del cierre. El estado registral es "transformada", lo que según el registro indica una operación de transformación societaria y no necesariamente una disolución o liquidación. El dato cronológicamente más relevante es la reducción de capital de 27 de marzo de 2024, con un importe de 29.943,48 € y un capital resultante de 158.169,48 €, según el acta publicada en el BORME.

No consta ningún acta de disolución, liquidación o concurso en el corpus suministrado. Por tanto, no se puede afirmar que la empresa haya desaparecido: lo que consta es una transformación.

El corpus no permite identificar ninguna herencia empresarial, marca, activo traspasado o continuidad de negocio. Esta información no consta.

Las personas que constan en el corpus son:

• MORENO OLIVARES ANGEL, administrador único desde el 28 de septiembre de 2017 (acta de ceses y nombramientos publicada en el BORME). Previamente había figurado como presidente y consejero delegado en el acta de 27 de marzo de 2017.
• MORENO OLIVARES CARLOS ALBERTO, administrador único hasta 2017 y apoderado desde 2019.
• AGRAZ SEGOVIA ANTONIO, consejero y secretario hasta 2017.
• GARCIA MARTINEZ JOSE MARIA y DANIEL UREÑA MARTIN, apoderados nombrados en 2024.
• JUAN CARLOS FERNANDEZ GARCIA, auditor nombrado en 2025, con CASTRO MOLINA JOSE ANTONIO como auditor suplente.
• FGYP AUDICONSULT SLP, auditora en los años 2019 y 2022.

El corpus no indica cuál es hoy la actividad profesional de estas personas ni su vinculación con la sociedad transformada. Esta información no consta. Para completarla habría que consultar el Registro Mercantil de Madrid (hoja registral M-40022, tomo 29924, folio 172, según los datos registrales que constan) y, en su caso, las publicaciones posteriores del BORME sobre la operación de transformación.

• La transformación no es lo mismo que el cierre. En este caso el estado registral es "transformada", no "disuelta" ni "liquidada". Cualquier análisis de continuidad debe distinguir entre cambio de forma societaria, fusión, escisión y extinción, porque las implicaciones para acreedores, trabajadores y socios son diferentes.
• La reducción de capital es una señal que hay que leer con contexto. Una reducción de 29.943,48 € en 2024 puede responder a devolución de aportaciones, compensación de pérdidas o reestructuración; el BORME publica el importe pero no siempre la finalidad. En ausencia de cuentas depositadas, no se puede inferir la causa.
• En sociedades patrimoniales o inmobiliarias del sector industrial, el rastro registral es a menudo la única fuente pública fiable. Cuando no hay cuentas accesibles ni cobertura periodística, la cronología de apoderamientos, auditorías y cambios de órgano es la evidencia principal de la actividad real de la sociedad.
• La auditoría recurrente (2019, 2022, 2025) indica obligación de verificar cuentas, habitualmente por superar los umbrales legales o por exigencia de socios o acreedores. Es un indicador útil para datar la dimensión mínima de la empresa en cada momento.

La funció econòmica original era clara pel nom i el sector registrat: posar en valor sòl i naus industrials —promoure, adequar i explotar espais per a activitat productiva i logística a Madrid [BORME / OpenMercantil, 2026-08-20]. Aquesta funció no ha desaparegut; el que ha canviat és com es pot fer avui.

La proposta (meva, no de l'empresa original) és una versió "asset-light": en lloc de comprar i desenvolupar sòl amb balanç propi, actuar com a operador i gestor de naus de tercers —propietaris familiars, fons petits, herències no treballades— als quals se'ls ofereix adequació, comercialització i gestió integral a canvi d'una comissió i un percentatge de la renda. El producte és el mateix espai industrial; el model financer és molt més lleuger.

El mercat rellevant és el lloguer de naus industrials i logístiques a la Comunitat de Madrid. És un mercat estructuralment tensionat per l'escassetat de sòl finalista ben comunicat, cosa que afavoreix qui sap trobar i preparar espais [estimació a validar amb dades d'Incasòl, Idealista i informes de consultores].

Tres segments on una estructura petita pot competir sense enfrontar-se frontalment als grans promotors:

• Naus petites i mitjanes (300–2.000 m²) per a manufactures lleugeres, tallers i última milla, sovint desateses pels operadors grans.
• Sòl i naus infrautilitzades en municipis de la corona (Cobo Calleja, San Fernando, Torrejón, Getafe, Alcalá), on hi ha propietaris sense capacitat de gestió.
• Reconversió d'usos cap a activitats productives petites i logística urbana.

Risc de mercat a vigilar: la demanda industrial va lligada al cicle econòmic i a la localització; un excés d'oferta nova en algun corredor pot comprimir rendes [estimació a validar].

Tres línies de ingrés, totes de proposta:

1. Comissió de comercialització per lloguer tancat (típicament un mes de renda o un percentatge, a validar segons mercat).
2. Contracte de gestió de la nau (manteniment, cobrament, relació amb llogaters): quota fixa mensual o percentatge de la renda.
3. Fees d'adequació i projecte: coordinació d'obres de condicionament, amb marge de gestió.

Opcionalment, un percentatge d'èxit sobre l'increment de renda aconseguit respecte del lloguer anterior, que alinea interessos amb el propietari.

El punt clau: no es necessita comprar actius per començar. Es monetitza la capacitat de trobar, preparar i comercialitzar espai, no el balanç.

Fases (proposta, calendaritzada a validar):

• Mesos 0–3: constituir la societat, definir l'àrea geogràfica d'actuació i fer un mapa de naus i sòl buits o infrautilitzats a la corona de Madrid.
• Mesos 3–6: tancar els primers 2–3 mandats de gestió o comercialització amb propietaris; validar el discurs comercial i les comissions reals.
• Mesos 6–12: operar les primeres naus, mesurar ocupació i renda, i construir cartera de llogaters recurrents.
• Mesos 12–24: escalar a una cartera estable de naus gestionades i valorar si convé coinvertir en alguna adequació concreta.

Xifres estimades i a validar, no dades de l'empresa original:

• Constitució i estructura legal/fiscal inicial: 3.000–8.000 €.
• Equip mínim (2–3 persones els primers 12 mesos): 90.000–150.000 €.
• Comercialització, web, eines i màrqueting: 10.000–25.000 €.
• Caixa de maniobra per a adequacions puntuals o avals: 100.000–300.000 €.
• Total orientatiu d'arrencada: 250.000–600.000 € (rang ampli, depèn de si s'assumeixen obres).

Com a referència de dimensió, el capital social registrat de l'empresa original va quedar en 158.169,48 € després de la reducció de 29.943,48 € el 2024 [BORME, 2024-03-27] — és una dada de l'empresa, no una previsió de la nova.

• Cicle immobiliari i de demanda industrial: rendes i ocupació poden caure; el model de gestió ho absorbeix millor que el de propietat, però no n'és immune.
• Dependència de pocs propietaris: si la cartera és petita, perdre un mandat pot trencar el compte d'explotació.
• Execució d'obres i permisos: terminis municipals i costos d'adequació poden menjar-se el marge.
• Competència de promotors grans i plataformes logístiques: cal especialitzar-se en el nínxol petit i local.
• Lliçó del tancament: l'empresa original va acabar "transformada" el 2026 després de 13 anys i d'una reducció de capital el 2024 [BORME / OpenMercantil, 2026-08-20]; el senyal és que el model intensiu en actius i capital és fràgil davant de cicles llargs. La reconstrucció hauria de néixer més lleugera.

Lliçons de l'informe original, no un currículum:

• Un equip petit amb coneixement local del sòl industrial de Madrid val més que un equip gran sense arrel: la informació de què està buit i qui el pot llogar és l'avantatge competitiu.
• Separar propietat de gestió redueix el risc que va caracteritzar el model original intensiu en capital.
• Disciplina financera des del dia u: la reducció de capital del 2024 és el recordatori que cal vigilar la caixa abans que el creixement.
• Especialització en un nínxol (nau petita/mitjana, corona de Madrid) en lloc de competir en el segment gran.
• Governança i auditors ja eren presents a l'empresa original [BORME, 2025-09-01]; mantenir controls formals des del començament és barat i evita sorpreses.

Nota: totes les xifres d'inversió, comissions i mides de mercat són estimacions pròpies a validar; les úniques dades verificades són les registrals citades.

Els gestors de patrimoni industrial (naus, naus logístiques, parcs empresarials) operen amb fulls de càlcul, correu i carpetes compartides. Això genera tres problemes concrets: (1) no hi ha una font única de veritat sobre quina nau està llogada, a qui, amb quines condicions i fins quan; (2) el manteniment preventiu i correctiu es perd entre proveïdors i no es pot imputar a contracte; (3) el reporting a socis, auditors i bancs es reconstrueix manualment cada any.

La cronologia registral d'aquesta empresa ho il·lustra: canvis d'administrador (2017), nomenaments d'apoderats (2019, 2024), auditoria recurrent (2019, 2022, 2025) i una reducció de capital el 2024 de 29.943,48 € que deixa el capital en 158.169,48 €. Cada un d'aquests fets requereix que l'empresa pugui demostrar, amb dades, l'estat dels seus actius i contractes. Un sistema que no traci aquesta informació obliga a reconstruir-la ex post.

Arquitectura de tres capes, monolític modular (no microserveis) perquè l'equip inicial és petit i el domini és cohesionat:

``` [Client web (React + Vite)] | v [API REST/JSON — NestJS] <-- autenticació JWT + RBAC per rol | +--> [PostgreSQL 16] (dades transaccionals, RLS per organització) +--> [S3-compatible] (documents: contractes, factures, actes) +--> [Redis] (cues de treball: generació de PDF, recordatoris) +--> [Servei de jobs] (worker Node: venciments, manteniment preventiu) ```

Decisions i motius:

• Monòlit modular amb NestJS: el domini (actius, contractes, manteniment, financer) comparteix transaccions; separar-ho en serveis introduiria consistència eventual on no cal. Els mòduls es poden extreure després si un creix.
• PostgreSQL amb Row-Level Security: cada organització client (tenant) veu només les seves files. RLS a la base de dades, no només al codi, perquè un error d'autorització a l'API no exposi dades d'altres tenants.
• S3 per a documents: els contractes i actes són binaris grans i immutables; guardar-los a la BD encareix backups i no aporta res.
• Worker separat per a jobs: els venciments de contracte i els recordatoris de manteniment no han de bloquejar l'API ni dependre que un usuari obri l'app.

Entitats principals (PostgreSQL, totes amb `org_id` i RLS):

``` organizations(id, nom, cif, created_at) users(id, org_id, email, rol, actiu) properties(id, org_id, referencia_cadastral, adreca, superficie_m2, tipus, estat) units(id, property_id, codi, superficie_m2, estat) -- nau dins d'un parc tenants(id, org_id, rao_social, cif, contacte) leases(id, unit_id, tenant_id, inici, fi, renda_mensual, ike, estat) lease_events(id, lease_id, tipus, data, import, notes) -- pròrrogues, revisions IPC maintenance_orders(id, unit_id, proveidor_id, tipus, estat, obertura, tancament, cost) maintenance_plans(id, unit_id, frequencia_dies, ultima_exec) documents(id, entitat_tipus, entitat_id, s3_key, hash_sha256, pujat_per) audit_log(id, org_id, user_id, accio, entitat, abans, despres, ts) ```

Decisions i motius:

• `units` separada de `properties`: un parc industrial té diverses naus; el lloguer es fa per nau, no per parcel·la. Modelar-ho així evita duplicar contractes.
• `lease_events` com a taula d'esdeveniments: les revisions d'IPC i pròrrogues no són camps del contracte sinó fets datats; així es pot reconstruir la renda vigent en qualsevol data.
• `audit_log` amb `abans`/`despres` en JSONB: requisit de traçabilitat equivalent al que un auditor (com els que apareixen al registre: FGYP Audiconsult, Juan Carlos Fernández García) demanaria. JSONB permet guardar l'estat sense esquema rígid per entitat.
• `documents.hash_sha256`: permet detectar si un contracte penjat s'ha modificat fora del sistema.

API REST versionada (`/v1`), autenticació JWT, RBAC amb rols `admin`, `gestor`, `manteniment`, `lectura`.

Endpoints clau:

• `GET /v1/units?estat=lliure&property_id=...` — inventari filtrable.
• `POST /v1/leases` — alta de contracte; valida solapament temporal per `unit_id` (constraint a BD, no només a l'API).
• `GET /v1/leases/:id/renda?data=YYYY-MM-DD` — renda vigent calculada des de `lease_events`.
• `POST /v1/maintenance-orders` i `PATCH /v1/maintenance-orders/:id` — cicle de vida de l'ordre.
• `GET /v1/reports/ocupacio?desde=&fins=` — ocupació per parc i període.
• `POST /v1/documents` (multipart) — puja a S3 i registra hash.

Integracions:

• Passarel·la de pagaments / conciliació bancària: import CSV de moviments (Norma 43 o CAMT.053) per conciliar cobraments de renda. Motiu: els gestors ja reben extractes; no cal construir un banc propi.
• Signatura electrònica (p. ex. proveïdor eIDAS): enviament de contractes a signar. Motiu: els contractes de lloguer industrial es signen presencialment o per correu; digitalitzar-ho redueix el cicle.
• Webhook de sortida per a esdeveniments (`lease.expiring`, `maintenance.overdue`) cap a eines del client (Slack, correu).

Fase 1 (MVP, 8-10 setmanes):

1. Inventari d'actius i unitats amb importació CSV inicial.
2. Contractes de lloguer amb validació de solapament i càlcul de renda vigent.
3. Alertes de venciment (worker diari) per correu.
4. Pujada de documents amb hash i vinculació a contracte.

Fase 2: manteniment (ordres + plans preventius), reporting d'ocupació, conciliació bancària. Fase 3: signatura electrònica, webhooks, portal de llogater (lectura de contracte i factures).

Motiu de l'ordre: sense inventari i contractes no hi ha producte; el manteniment i el reporting depenen d'aquestes dades. La signatura és valor afegit, no fonamental.

Mides:

• MVP: ~15-20 taules, ~40 endpoints, 2 desenvolupadors + 1 dissenyador durant 10 setmanes.
• Volum esperat per tenant mitjà: 50-500 unitats, 100-1.000 contractes actius, 5.000-20.000 documents. PostgreSQL ho absorbeix sense particionar.
• Cost d'infraestructura inicial: ~150-300 €/mes (API + BD gestionada + S3 + Redis).

Riscos:

• Multi-tenancy mal implementat: mitigació amb RLS a BD i tests automàtics que intenten accedir a dades d'un altre tenant.
• Migració de dades del client: els fulls de càlcul són bruts; cal un importador amb validació i informe d'errors, no un "importa i ja veurem".
• Càlcul de renda amb IPC: les revisions poden tenir fórmules diverses; cal modelar-les com a events amb import explícit, no com a fórmula automàtica al principi.
• Compliment RGPD: dades de contacte de llogaters; cal base legal, retenció i dret d'esborrament, amb anonimització al `audit_log` si cal.
• Dependència d'un sol proveïdor de signatura: abstraure la integració darrere d'una interfície.

1. Tests d'integració de domini: solapament de contractes, càlcul de renda vigent en dates concretes, transicions d'estat de manteniment.
2. Tests de seguretat multi-tenant: suite que, amb un token d'organització A, intenta llegir cada endpoint amb IDs d'organització B i ha de rebre 404/403.
3. Pilot amb un gestor real: 1 parc, 20-50 unitats, 3 mesos, comparant l'ocupació i els cobraments calculats pel sistema amb els del full de càlcul.
4. Validació de traçabilitat: reproduir un cas com el d'aquesta empresa —canvi d'administrador, reducció de capital, auditoria anual— i comprovar que el sistema pot exportar l'estat d'actius i contractes a una data donada.
5. Càrrega: 500 unitats i 1.000 contractes per tenant amb temps de resposta < 300 ms al 95è percentil en els endpoints de llistat.