TUBERIAS UNSASA 210 SOCIEDAD LIMITADA

Tuberías Unsasa 210 Sociedad Limitada era una sociedad mercantil de responsabilidad limitada constituida en Bizkaia en el año 2009, con un capital social que llegó a los 75.000 EUR. De acuerdo con la ficha registral publicada en OpenMercantil a partir de datos del BORME, la sociedad consta actualmente como inactiva.

La denominación social remite al sector de las tuberías y su fabricación o instalación, si bien los datos disponibles no permiten confirmar la actividad efectivamente desarrollada más allá de lo que consta en el objeto social registrado.

La sociedad se constituyó en 2009. El primer acto que consta en el registro es un nombramiento de auditor el 7 de mayo de 2009, a nombre de AGUILAR FURRASOLA MIGUEL ANGEL, según el BORME. El 14 de mayo de 2009 consta una ampliación de capital de 99.766,00 EUR, con un capital resultante de 111.185,00 EUR.

El 3 de diciembre de 2009 consta el cese y dimisión de los administradores solidarios NAVARRO AGUIRRE LUIS ANGEL y NAVARRO AGUIRRE JUAN CARLOS, de acuerdo con el registro.

El objeto social original no consta de manera explícita en los datos disponibles. El 9 de mayo de 2013 consta una ampliación del objeto social para incluir "actividades de realización de instalaciones mecánicas", según el BORME (T 4972, F 51, S 8, H BI 52898, I/A 5).

No consta en los datos facilitados qué clientela o qué ámbito geográfico de operación tenía la sociedad, ni qué productos o servicios concretos ofrecía más allá de la referencia a instalaciones mecánicas.

Los datos registrales muestran una actividad societaria intensa entre 2009 y 2015, con varias ampliaciones de capital y cambios en los órganos de administración.

El 27 de febrero de 2012 consta una ampliación de capital de 89.900,00 EUR, con un capital resultante de 93.000,00 EUR. El 20 de diciembre de 2012 consta otra ampliación de 25.000,00 EUR, con un capital resultante de 75.000,00 EUR, según el BORME. Esta es la cifra de capital que figura como vigente en la ficha registral.

En cuanto a los órganos de gobierno, el 15 de diciembre de 2010 constan nombramientos de consejeros y presidente (DIEZ TORRALBO MOISES como presidente y consejero, ASTORKI KAIFER JAVIER y MARTI como consejeros), con ceses simultáneos. El 3 de febrero de 2012 consta el nombramiento de administrador único a MARTINEZ PEREZ MIGUEL ANGEL, con el cese de MARTINEZ GOMEZ IVAN. El 20 de enero de 2015 consta el nombramiento de administrador único a MUELAS CANTERA CARLOS, el cese de PORRO RELLOSO ALICIA y una declaración de unipersonalidad. El 23 de noviembre de 2015 consta el nombramiento de administrador único a NAVARRO AGUIRRE JUAN CARLOS.

Estos datos reflejan una sociedad con movimiento societario y de capital, pero no permiten afirmar nada sobre resultados económicos, volumen de negocio o rentabilidad, que no constan en las fuentes disponibles.

Los datos disponibles no permiten determinar la causa del cese de actividad. El estado registral es "inactiva", según la ficha de OpenMercantil basada en el BORME, pero no consta en las fuentes facilitadas ningún acto de disolución, liquidación o concurso, ni ninguna fecha concreta de cierre.

El último acto registral disponible es del 23 de noviembre de 2015 (nombramiento de administrador único). No consta qué pasó después de esa fecha ni cuál fue el motivo por el que la sociedad dejó de operar.

No consta en los datos disponibles ninguna información sobre activos, marcas, cartera de clientes, continuidad de negocio por parte de otras sociedades o cualquier otro elemento de legado empresarial de Tuberías Unsasa 210 SL.

Las personas que constan en el corpus como vinculadas a la sociedad son, entre otras, NAVARRO AGUIRRE LUIS ANGEL y NAVARRO AGUIRRE JUAN CARLOS (administradores solidarios iniciales), MARTINEZ GOMEZ IVAN, MARTINEZ PEREZ MIGUEL ANGEL, MUELAS CANTERA CARLOS, PORRO RELLOSO ALICIA, DIEZ TORRALBO MOISES, ASTORKI KAIFER JAVIER, MARTI, ESTIVARIZ GONZALEZ JESUS y CASTAÑOS GUANTES VIRGINIA, además de la sociedad AGUILEDA ARCO ATLANTICO SOCIEDAD LIMITADA como auditora.

No consta en las fuentes facilitadas cuál es la situación actual de estas personas ni si mantienen vinculación con otras sociedades. Para ampliarlo, se podría consultar el Registro Mercantil de Bizkaia, las fichas de OpenMercantil de cada persona o sociedad mencionada, y el BORME para detectar nombramientos posteriores.

• En el sector de la fabricación e instalación de tuberías e instalaciones mecánicas, la ampliación del objeto social en 2013 indica una diversificación hacia servicios de instalación; conviene verificar si esta diversificación se acompañó de capacidad técnica y contratos, dado que los datos no permiten confirmarlo.
• Las ampliaciones de capital sucesivas (2009, 2012) sin información pública sobre resultados sugieren la importancia de disponer de información financiera depositada para valorar la evolución real; en este caso, las fuentes disponibles no incluyen cuentas anuales.
• La rotación frecuente en los órganos de administración (varios administradores únicos y consejeros entre 2010 y 2015) es un indicador que hay que contrastar con la estabilidad de la gestión; en este caso, no consta la causa de los cambios.
• Para cualquier análisis de continuidad, habría que consultar el Registro Mercantil para confirmar si hay actos posteriores a 2015 no recogidos en las fuentes disponibles.

La dada registral més rellevant per a una reconstrucció és l'ampliació de l'objecte social del 2013 cap a "activitats de realització d'instal·lacions mecàniques" [BORME 2013-05-09]. Això indica que l'empresa, originalment de tubs, va virar cap a l'execució d'instal·lacions: un negoci de projecte, pressupost, obra i postvenda, amb molta càrrega administrativa i poca digitalització.

La proposta d'avui no és reconstruir una empresa de tubs (capital intensiu, marge baix, competència local ferotge), sinó capturar l'essència operativa —saber com es pressuposta, s'executa i es factura una instal·lació mecànica— en forma de programari vertical per a instal·ladors. És a dir: un SaaS de gestió d'obra i pressupostos per a PIMEs instal·ladores (climatització, fontaneria, gas, ventilació).

Això és una proposta nova, no una continuació de l'activitat registrada. No consta que l'empresa hagués desenvolupat mai programari; el sector "Software i SaaS" de la fitxa és la classificació de la consulta, no una activitat acreditada als actes.

El mercat objectiu són les PIMEs instal·ladores a Euskadi i nord de Castella, un teixit fragmentat de microempreses de 3 a 30 treballadors que avui gestionen pressupostos amb fulls de càlcul, WhatsApp i programari genèric de facturació.

No disposo de dades verificades sobre la mida d'aquest mercat ni sobre la cartera de l'empresa original; qualsevol xifra seria inventada. El que sí que és verificable és el context: l'empresa va mantenir activitat 17 anys i va ampliar objecte cap a instal·lacions, cosa que suggereix que el nínxol era prou gran per sostenir una societat amb auditor extern i capital de 75.000 EUR [BORME 2012-12-20].

Estimació a validar: un mercat adreçable d'entre 800 i 2.000 empreses instal·ladores a Bizkaia i Gipuzkoa, amb una disposició a pagar de 40–120 EUR/mes per eina. Són rangs orientatius que caldria contrastar amb un estudi de camp abans de decidir res.

Model SaaS per subscripció, amb tres components:

1. Subscripció base per empresa instal·ladora (gestió de pressupostos, obra, materials i facturació). Preu estimat: 49–99 EUR/mes segons nombre d'usuaris.
2. Mòdul de camp per a operaris (partes de treball, fotos d'obra, signatura de client). Add-on estimat: 15–25 EUR/usuari/mes.
3. Serveis d'implantació puntuals (migració de dades, formació). Ingrés no recurrent, estimat 500–1.500 EUR per client.

El marge brut d'un SaaS ben construït sol situar-se per sobre del 70% (estimació estàndard del sector, a validar amb cost real d'infraestructura i suport). El repte no és el marge sinó el cost d'adquisició: vendre a instal·ladors requereix canal presencial i referències.

Fase 0 (mesos 0–3): validació. 20–30 entrevistes a instal·ladors de Bizkaia, prototip de pressupostador i prova de disposició a pagar. Cost estimat: 8.000–15.000 EUR (temps fundador + eines).

Fase 1 (mesos 3–9): MVP amb pressupostos, obra i facturació. 5–8 clients pilots gratuïts o a preu reduït. Cost estimat: 40.000–70.000 EUR (desenvolupament, sovint amb soci tècnic o freelance).

Fase 2 (mesos 9–18): comercialització a Euskadi, 30–50 clients de pagament, primera contractació de suport/comercial. Cost estimat: 60.000–100.000 EUR addicionals.

Fase 3 (mes 18+): expansió a mercats adjacents (Navarra, Cantàbria, nord de Burgos) i possible verticalització per especialitat (gas, fred industrial).

Totes les xifres són estimacions a validar; no hi ha cap dada financera verificada de l'empresa original que permeti calibrar-les millor.

Rang estimat per arribar a primers ingressos (12–18 mesos): 120.000–200.000 EUR, desglossat aproximadament així (tot a validar):

• Desenvolupament de producte: 60.000–100.000 EUR.
• Màrqueting i vendes inicials: 20.000–35.000 EUR.
• Legal, constitució i compliment (RGPD, contractes): 5.000–10.000 EUR.
• Infraestructura i eines: 5.000–10.000 EUR/any.
• Capital de maniobra i imprevistos: 20.000–40.000 EUR.

Alternativa més lleugera: fundador tècnic en solitari amb MVP en 6 mesos, cost estimat 25.000–40.000 EUR, però amb risc molt més alt de producte incomplet i venda lenta.

1. Risc de mercat: que els instal·ladors no paguin per programari i prefereixin fulls de càlcul. És el risc número u i només es resol amb validació prèvia.
2. Risc de producte: un SaaS vertical requereix molta funcionalitat específica (normativa, materials, IVA, obra). Subestimar-ho crema capital.
3. Risc de canal: vendre a PIME local és car i lent; caldrà canal (associacions, distribuïdors de material, gestories).
4. Risc de continuïtat del coneixement: no consta que hi hagi equip humà disponible de l'empresa original; el coneixement sectorial s'hauria de reconstruir via entrevistes, no heretar.
5. Risc financer: el capital social registrat (75.000 EUR) no implica liquiditat disponible; no hi ha comptes verificats a la font consultada.

La lliçó de l'expedient original no és "torna a fer tubs", sinó que una empresa pot sobreviure 17 anys si sap pivotar l'objecte cap on hi ha marge (el 2013 va passar de tubs a instal·lacions). La reconstrucció hauria de seguir la mateixa lògica: pivotar del producte físic al servei digital, aprofitant el coneixement del sector però sense arrossegar el capital intensiu.

Qui ho hauria de fer: un equip de dues persones —un perfil tècnic de producte i un perfil comercial amb arrel al sector d'instal·lacions de Bizkaia—, amb un mentor o soci industrial que hagi viscut el negoci des de dins. No cal un gran equip inicial; cal algú que conegui el client millor que el producte. I, sobretot, cal validar abans de construir: la història de l'empresa original demostra que el sector aguanta, però no demostra que pagui per programari.

Les dades registrals d'una societat com TUBERIAS UNSASA 210 SL existeixen, però estan disperses en actes del BORME amb formats inconsistents: nomenaments, cessaments, ampliacions de capital i canvis de domicili apareixen com a text lliure, sovint amb errors de transcripció i noms repetits o truncats. Reconstruir la cronologia fiable —qui era administrador únic el 2015, quin capital hi havia abans i després de cada ampliació, quan es va ampliar l'objecte social— requereix llegir desenes de PDFs.

El producte resoldria aquesta reconstrucció per a qualsevol societat espanyola: una línia de temps normalitzada, amb cada fet enllaçat a l'acte font i marcat amb el seu grau de confiança. El cas d'UNSASA 210 és representatiu: 15 actes entre 2009 i 2015, amb ampliacions de capital successives (99.766 €, 89.900 €, 25.000 €), canvis d'administrador únic i una declaració d'unipersonalitat, i un estat final inactiu.

Pipeline en tres etapes desacoblades, perquè la ingesta de PDFs és lenta i fràgil mentre que la consulta ha de ser ràpida i estable:

``` [BORME/BOE] --(crawler diari)--> [raw_actes (object storage + metadades)] | (parser + normalitzador) | [fets_normalitzats (Postgres)] | (API REST /v1/empreses/{id}/cronologia) | [clients SaaS] ```

Decisions i motius:

• Emmagatzematge del PDF original immutable (object storage amb hash SHA-256): cada fet ha de poder-se citar; si el parser canvia, es reprocessa des del raw sense tornar a descarregar.
• Normalitzador determinista + regles versionades: els noms de càrrec ("administrador_unico", "consejero_delegado", "secretario") es mapegen a un enum tancat. Motiu: els camps del BORME són text lliure i cal estabilitat per comparar entre empreses.
• Idempotència per clau natural `(empresa_id, data_acte, tipus_acte, hash_contingut)`: el crawler pot repetir-se sense duplicar fets.
• Postgres amb taula d'esdeveniments append-only: la cronologia és un log; mai s'edita un fet, se'n crea un de correcció amb `supersedeix_id`.

```sql empresa(id, nom_razon_social, sector, provincia, any_constitucio, capital_actual_eur, estat_registral, font_url)

acte_font(id, empresa_id, data_acte, tipus, url_pdf, hash_sha256, text_original, processat_el)

fet(id, empresa_id, acte_font_id, data_efectiva, tipus_fet, -- tipus_fet: NOMENAMENT | CESSAMENT | AMPLIACIO_CAPITAL | -- CANVI_DOMICILI | AMPLIACIO_OBJECTE | DECLARACIO_UNIPERSONALITAT confianca numeric(3,2), supersedeix_id, creat_el)

carrec(fet_id, persona_nom, rol, entitat_nom) -- rol: enum tancat capital_canvi(fet_id, import_eur, capital_resultant_eur) ```

Motiu de separar `acte_font` de `fet`: un sol acte pot generar diversos fets (el de 2015-01-15 conté nomenaments, cessaments i canvi de domicili alhora), i volem traçar cada fet a l'acte que el conté.

• `GET /v1/empreses/{id}/cronologia?desde=&fins=` → llista de fets ordenats, cada un amb `acte_font.url_pdf` i `confianca`.
• `GET /v1/empreses/{id}/carrecs-en-data?data=YYYY-MM-DD` → qui ocupava cada rol en una data concreta, calculat reproduint nomenaments i cessaments.
• `GET /v1/empreses/{id}/capital-en-data?data=` → capital vigent reproduint les ampliacions.
• Ingestió: crawler diari contra el BORME (OpenMercantil com a font secundària de verificació), cua de treball per PDF, webhook intern en acabar cada empresa.
• Integració de sortida: export CSV/JSON per a sistemes de compliance i un webhook `fet.creat` perquè els clients sincronitzin canvis.

Motiu de les consultes "en data": el valor no és la llista de fets sinó l'estat reconstruït; calcular-lo al servidor evita que cada client reimplementi la lògica de nomenaments i cessaments.

1. Parser d'actes del BORME per als tipus presents al cas UNSASA 210 (nomenaments, cessaments, ampliacions de capital, canvi de domicili, ampliació d'objecte, unipersonalitat). És el coll d'ampolla i el risc principal.
2. Model `acte_font` + `fet` amb hash i idempotència, carregant manualment els 15 actes d'UNSASA 210 com a corpus de prova.
3. Endpoint `cronologia` amb citació a font, que ja dona valor llegible.
4. Càlcul `carrecs-en-data` i `capital-en-data`, validat contra el cas real (p. ex. administrador únic el 2015-11-23 = NAVARRO AGUIRRE JUAN CARLOS).
5. Crawler diari i webhooks, un cop el parser és estable.

• Volum: el BORME publica milers d'actes diaris; el coll és el parsing, no l'emmagatzematge. Estimo 10-50 PDFs/minut per instància de parser.
• Risc d'errors de transcripció: els noms apareixen repetits o truncats (p. ex. "ASTORQUI KAIFER JAVIER" vs "ASTORKI KAIFER JAVIER" al mateix registre). Cal un pas de reconciliació de persones amb confiança baixa marcada, no correcció silenciosa.
• Risc de canvi de format del BORME: el parser ha de fallar de manera visible (acte marcat `no_processat`) i alertar, no descartar en silenci.
• Risc de dades contradictòries: dues fonts (BORME i OpenMercantil) poden discrepar; el model ha de permetre múltiples `acte_font` per fet i marcar conflictes.
• Privacitat: dades de persones físiques en càrrecs; cal base legal i política de retenció, ja que són dades públiques però personals.

• Corpus de regressió: els 15 actes d'UNSASA 210 com a golden set; el parser ha de reproduir exactament els fets esperats (capital 75.000 € el 2012-12-20, administrador únic NAVARRO AGUIRRE JUAN CARLOS el 2015-11-23, etc.).
• Test de reconstrucció d'estat: `carrecs-en-data` i `capital-en-data` han de coincidir amb la lectura manual de la cronologia per a cada data d'acte.
• Test d'idempotència: reprocessar el mateix PDF dues vegades no ha de crear fets duplicats.
• Test de citació: cada fet retornat per l'API ha de tenir `url_pdf` resoluble i hash coincident amb el raw.
• Monitor de cobertura: percentatge d'actes processats vs. `no_processat` per dia, amb alerta si baixa del llindar.