NAVEGA TELECOM SL

NAVEGA TELECOM SL és una societat de responsabilitat limitada constituïda l'any 2015 amb seu a València, classificada al sector de serveis professionals. D'acord amb la fitxa registral, el capital social inicial consta de 3.000 euros, que el 2020 es va ampliar fins als 103.000 euros. L'estat registral actual és d'activa.

La societat es va constituir el 2015. El document del BORME de 10 d'abril de 2015 (València) consta com a font registral de la constitució. En el moment de la constitució, l'administrador únic era Rafael-Antonio Avellaneda García, segons la fitxa registral.

La informació disponible no detalla l'activitat concreta de l'empresa més enllà de la classificació sectorial com a serveis professionals. No consta a les dades facilitades quins serveis prestava ni a quins clients s'adreçava.

No consta a les dades cap informació sobre facturació, resultats, nombre de treballadors o fites comercials. L'únic element que indica creixement és l'ampliació de capital del 22 d'abril de 2020, que va elevar el capital subscrit de 3.000 a 103.000 euros, d'acord amb el BORME (dades registrals: T 9938, L 7220, F 161, S 8, H V 164490, I/A 2).

No consta que l'empresa hagi tancat. Segons el registre, NAVEGA TELECOM SL continua activa a la data de la fitxa (2025-03-13). El que sí que consta són canvis en els òrgans d'administració: el 18 de juliol de 2024 es va produir el cessament de l'administrador únic, Rafael-Antonio Avellaneda García, i el nomenament de dos administradors solidaris, José Ignacio Aguirre Álvarez i Víctor Manuel Rodríguez Filgueira; el mateix dia es van nomenar quatre apoderats (Jorge Gómez Jiménez, Ignacio Autran Pérez, José Miguel Llinares Tarriño i José María del Corro García Lomas). El 13 de març de 2025 consta el cessament dels dos administradors solidaris i la revocació dels apoderats. Aquests moviments són propis d'un relleu en la governança, no d'una dissolució.

No consta a les dades cap informació sobre l'herència empresarial, actius, marques o continuïtat d'activitat més enllà de l'estat registral d'activa.

Rafael-Antonio Avellaneda García consta com a administrador únic fins al cessament del 18 de juliol de 2024, segons el BORME. No consta a les dades quina és la seva situació actual ni la dels administradors solidaris nomenats el 2024 i cessats el 2025. Per completar-ho es podria consultar el Registre Mercantil de València i les successives publicacions del BORME posteriors al març de 2025.

• En societats petites de serveis professionals, els canvis sobtats d'administrador únic a administradors solidaris i el nomenament simultani de diversos apoderats solen indicar una reestructuració de la propietat o de la gestió; convé verificar-ho al Registre Mercantil abans de treure'n conclusions.
• L'ampliació de capital de 3.000 a 103.000 euros el 2020 és l'únic indicador de creixement documentat; en absència de comptes dipositats a les dades, no es pot inferir ni èxit ni dificultat.
• La revocació de poders i els cessaments del 2025, sense dissolució registral, recorden que cal distingir entre relleu de governança i tancament efectiu de l'empresa.

Reconstruir NAVEGA TELECOM SL com una consultoria de serveis professionals tecnològics amb seu a València, orientada a pimes i administracions locals: desplegament i manteniment d'infraestructura de telecomunicacions, suport tècnic gestionat i acompanyament en digitalització.

Aquesta és una proposta, no una descripció verificada del que feia l'empresa: les fonts registrals disponibles [BORME / BOE, 2025-03-13] només confirmen la forma jurídica, el capital i els canvis en òrgans d'administració, no l'activitat comercial.

L'essència a preservar seria la d'una societat valenciana de mida petita, amb soci administrador i estructura de decisió àgil, que ven servei recurrent (contractes de manteniment i suport) més que projectes puntuals.

València té un teixit dens de pimes industrials, comercials i de serveis que necessiten suport tècnic extern i no tenen departament propi de TI. Aquest nínxol de "consultoria de proximitat" és real i competitiu, amb molts operadors petits i mitjans.

No disposem de dades verificades sobre la cartera de clients, la facturació ni la quota de mercat de NAVEGA TELECOM SL: les fonts consultades no les recullen. Qualsevol xifra de mercat que es faci servir en un pla de negoci s'ha de validar amb dades d'INE, cambres de comerç o estudis sectorials abans de decidir res.

La proposta seria competir per proximitat, resposta ràpida i contracte de servei mensual, no per preu baix.

Model proposat (a validar):

• Contracte de suport gestionat (quota mensual per usuari o per equip): ingressos recurrents, la base de la sostenibilitat.
• Projectes d'implantació (xarxa, telefonia IP, cloud, ciberseguretat bàsica): ingressos puntuals d'entrada.
• Hores de consultoria a demanda per a clients no recurrents.

La clau financera és que la quota recurrent cobreixi la despesa fixa (local, sous, eines) i els projectes aportin marge. Rangs orientatius, estimació a validar: quota de 25-60 €/usuari/mes segons abast; projectes de 3.000-25.000 € segons mida.

Proposta en quatre fases (estimació de calendaris, a validar):

1. Mesos 0-2 — Validació. Entrevistes amb 15-20 pimes valencianes per confirmar necessitat i disposició a pagar quota. Sense això, no es constitueix res.
2. Mesos 2-4 — Constitució i equip mínim. Soci administrador únic, un tècnic i suport administratiu extern. Capital social modest (3.000-10.000 €, estimació) i tresoreria separada.
3. Mesos 4-9 — Primers clients. Objectiu de 8-12 contractes de suport recurrent, captats per xarxa local i referències.
4. Mesos 9-18 — Consolidació. Contractar el segon tècnic quan la quota recurrent cobreixi el seu cost; avaluar ampliació de capital només amb tracció demostrada.

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

• Constitució, notaria i gestoria: 1.000-2.500 €.
• Capital social mínim operatiu: 3.000-10.000 € (la societat original va arribar a 103.000 € el 2020 [BORME / BOE, 2025-03-13], però això no és una referència obligatòria per a un nou projecte).
• Local/oficina petita a València (6-12 mesos): 6.000-15.000 €.
• Equipament i eines (ordinadors, llicències, monitoratge): 4.000-8.000 €.
• Sous del nucli inicial (soci + 1 tècnic, 6 mesos): 30.000-45.000 €.
• Màrqueting i captació inicial: 3.000-6.000 €.
• Total orientatiu d'arrencada: 25.000-60.000 €, amb un coixí de tresoreria de 3-6 mesos addicional recomanable.

• Risc de validació: no tenim evidència verificada que el model de quota recurrent funcioni en aquest nínxol; cal provar-ho abans d'invertir.
• Risc de governança: els canvis registrals de 2024-2025 (cessió de l'administrador únic i nomenament de dos administradors solidaris, després cessió d'aquests el març de 2025 [BORME / BOE, 2025-03-13]) suggereixen inestabilitat o relleu; un projecte nou ha de néixer amb governança clara i un sol responsable.
• Risc de competència i preus: el nínxol de suport TIC local és molt disputat; competir per preu destrueix marge.
• Risc de concentració de clients: pocs clients grans poden fer caure la facturació de cop.
• Risc financer: el capital social no és tresoreria; cal separar-los.

Lliçons que es poden extreure de la trajectòria registral de NAVEGA TELECOM SL, com a resum per a qui vulgui reconstruir alguna cosa semblant:

• Un sol responsable clar des del primer dia. La societat va passar d'administrador únic a dos administradors solidaris i, en menys d'un any, va cessar tots dos [BORME / BOE, 2025-03-13]: la governança ha de ser simple i estable.
• Capital i tresoreria són coses diferents. Una ampliació a 103.000 € el 2020 no garanteix solvència operativa; el pla ha de preveure caixa real per mes.
• Validar abans de constituir. Cap font verificada confirma l'activitat comercial original; qui reconstrueixi ha de començar per demostrar demanda, no per replicar una estructura.
• Documentar des del minut u. Els apoderaments i canvis de 2024 mostren la importància de tenir poders i protocols escrits per evitar buits de decisió.

Nota: aquest informe és una proposta de reconstrucció basada en dades registrals públiques; no descriu l'activitat real passada de l'empresa, que no ha estat verificada.

Les pimes espanyoles acumulen canvis societaris dispersos en actes del BORME, escriptures notarials i fitxers interns. El cas de NAVEGA TELECOM SL ho il·lustra: entre 2020 i 2025 hi ha una ampliació de capital, un canvi d'administrador únic a dos administradors solidaris, i nomenaments i revocacions d'apoderats en dates molt properes [BORME / BOE (via OpenMercantil), 2025-03-13]. Reconstruir "qui tenia poder de signatura el dia X" requereix llegir actes creuats i entendre quins càrrecs queden vigents després de cada cese.

Això genera risc operatiu real: contractes signats per persones amb poder ja revocat, poders bancaris no actualitzats, o declaracions de beneficiari últim (Titular Real) desfasades. Les eines existents o bé són consulta passiva de dades registrals, o bé són gestió documental sense semàntica de vigència. Cap de les dues respon la pregunta temporal.

La proposta és un SaaS de govern del canvi societari: ingereix fonts públiques i documents interns, construeix un bessó digital de la governança de l'empresa amb línia temporal, i emet alertes i informes auditables.

Arquitectura modular en tres plànols: ingestió, domini i presentació. El motiu de separar ingestió del domini és que les fonts (BORME, PDFs notarials, fulls de càlcul interns) canvien de format sovint i no han de contaminar el model de negoci.

``` [Fonts] [Ingestió] [Domini] [Presentació] BORME/OpenMercantil --> connectors + parser --> event store (append-only) --> API REST/GraphQL PDF escriptures --> OCR + extractor --> motor de reconciliació --> panell web CSV/Excel interns --> validador d'esquema --> projector de vigència --> export PDF/CSV auditable | alertes (worker) ```

Decisions i motius:

• Event store append-only com a font de veritat. Els actes registrals són inherentment esdeveniments datats i immutables; modelar-los com a fets (no com a estat) permet recalcular la vigència en qualsevol instant i auditar canvis. Un model CRUD sobre "càrrecs actuals" perdria la història i faria impossible respondre consultes "a data de".
• Projector de vigència separat de l'event store. L'estat vigent (qui és administrador avui) és una projecció derivada; es pot reconstruir des de zero. Això permet corregir errors d'ingestió sense perdre dades originals.
• Connector BORME via OpenMercantil com a primera font. És la font pública estructurada més fiable i citada; el connector s'aïlla darrere d'una interfície `RegistrySource` per poder afegir Registradors o proveïdors comercials després.
• PostgreSQL com a base única amb taules d'esdeveniments i projeccions. Evita la complexitat operativa d'un event store dedicat (Kafka/EventStoreDB) en una fase inicial; les consultes temporals es resolen amb rangs `tstzrange` i índexs GiST.
• Worker d'alertes desacoblat. Les notificacions (canvi de càrrec, poder revocat, capital modificat) s'han de poder reintentar i auditar; un worker amb cua persistent ho garanteix.

Model centrat en entitats de governança amb vigència temporal explícita. Les taules `_event` són immutables; les taules `_current` són projeccions.

```sql -- Nucli CREATE TABLE company ( id uuid PRIMARY KEY, legal_name text NOT NULL, tax_id text UNIQUE, -- CIF registry_id text, -- dades registrals (T/L/F/S/H) created_at timestamptz NOT NULL DEFAULT now() );

-- Esdeveniments registrals crus (append-only) CREATE TABLE registry_event ( id uuid PRIMARY KEY, company_id uuid NOT NULL REFERENCES company(id), source text NOT NULL, -- 'borme', 'notary_pdf', 'manual' source_ref text NOT NULL, -- URL o hash del document event_date date NOT NULL, -- data de l'acte published_at timestamptz, -- data de publicació BORME kind text NOT NULL, -- 'appointment','dismissal','capital_increase','power_of_attorney' payload jsonb NOT NULL, -- contingut normalitzat parcial raw jsonb, -- original per traçabilitat ingested_at timestamptz NOT NULL DEFAULT now(), UNIQUE (source, source_ref, event_date, kind) );

-- Persones i òrgans CREATE TABLE person ( id uuid PRIMARY KEY, full_name text NOT NULL, id_number text, -- NIF/NIE (xifrat en repòs) nationality text );

CREATE TABLE role_assignment ( -- projecció de vigència id uuid PRIMARY KEY, company_id uuid NOT NULL REFERENCES company(id), person_id uuid NOT NULL REFERENCES person(id), role text NOT NULL, -- 'administrador_unico','administrador_solidario','apoderado' valid_from date NOT NULL, valid_to date, -- NULL = vigent source_event uuid NOT NULL REFERENCES registry_event(id), CONSTRAINT no_overlap EXCLUDE USING gist ( company_id WITH =, person_id WITH =, role WITH =, daterange(valid_from, valid_to, '[]') WITH && ) );

CREATE TABLE capital_movement ( id uuid PRIMARY KEY, company_id uuid NOT NULL REFERENCES company(id), effective_date date NOT NULL, amount_eur numeric(14,2) NOT NULL, resulting_capital_eur numeric(14,2) NOT NULL, source_event uuid NOT NULL REFERENCES registry_event(id) ); ```

Motius de disseny:

• `EXCLUDE USING gist` amb `daterange` impedeix solapaments de vigència per a la mateixa persona i rol; és la garantia a nivell de BD que no hi ha dos "administradors únics" simultanis.
• `payload jsonb` + `raw jsonb` permeten evolucionar l'extractor sense migracions destructives; el `raw` és la prova d'origen per a l'auditoria.
• `UNIQUE (source, source_ref, event_date, kind)` fa la ingestió idempotent: reingerir el mateix acte no duplica.
• `id_number` xifrat perquè és dada personal; el xifrat a nivell de columna (pgcrypto o KMS) redueix l'abast d'una fuita.

API REST versionada (`/v1`) amb autenticació OAuth2 (client credentials per a màquines, autorization code per a usuaris). GraphQL opcional en fase 2 per a consultes temporals ad hoc.

Endpoints principals:

``` GET /v1/companies/{id}/governance?at=2024-07-18 -> { administrators: [...], attorneys: [...], capital_eur: 103000.00 } GET /v1/companies/{id}/events?from=&to=&kind= GET /v1/companies/{id}/timeline POST /v1/companies/{id}/events (ingesta manual / correcció) POST /v1/ingestions/borme (webhook o batch) GET /v1/companies/{id}/report.pdf?at= (informe auditable a data) GET /v1/alerts ```

Integracions:

• OpenMercantil / BORME: connector que consulta la fitxa de l'empresa i descarrega els actes; parser que normalitza tipus d'acte a `kind`. Referència de comportament: la fitxa de NAVEGA TELECOM SL mostra actes de 2020 a 2025 amb tipus heterogenis (ampliació de capital, nomenaments, ceses) [BORME / BOE (via OpenMercantil), 2025-03-13].
• PDF notarials: pipeline OCR (Tesseract) + extractor basat en regles + revisió humana assistida; cap dada extreta automàticament no es marca com a "verificada" fins que un usuari la confirma.
• Webhooks sortints: `role.changed`, `capital.changed`, `power.revoked` perquè el client pugui sincronitzar el seu ERP o el seu banc.
• Export: PDF signat (hash SHA-256 del contingut) i CSV per a auditors.

Ordre de construcció per maximitzar aprenentatge amb mínim abast:

1. Connector BORME + parser d'actes per a un conjunt tancat de `kind` (nomenament, cese, ampliació de capital, apoderament, revocació). És la font que valida el model.
2. Event store + projector de vigència amb la restricció d'exclusió temporal. Sense això no hi ha producte.
3. Endpoint `GET /governance?at=` i panell de línia temporal. És la proposta de valor mínima demostrable.
4. Ingesta manual i correcció amb traçabilitat (qui va canviar què i quan).
5. Informe PDF auditable a data, amb cites a les fonts.

Fora d'abast inicial: integració bancària, firma electrònica, multi-tenant avançat, OCR de PDFs notarials (es fa manualment assistit).

• Qualitat de les dades d'origen: el BORME publica actes amb redaccions variables i camps opcionals; el parser ha de ser tolerant i marcar baixa confiança. Risc: falsos negatius en revocacions. Mitigació: revisió humana obligatòria per a `dismissal` i `power_revoked`.
• Ambigüitat de noms de persones: homonímia i variacions (accents, ordre). Mitigació: clau `(full_name_normalized, id_number)` i resolució manual d'ambigüitats.
• Volum: una pime té desenes d'actes, no milers; PostgreSQL és suficient. El risc no és volum sinó latència d'ingestió i consistència.
• Compliment: dades personals (NIF, càrrecs) sota RGPD; cal base legal (interès legítim o contracte), xifrat i retenció definida. L'informe auditable no ha d'exposar NIF complets.
• Dependència de tercers: OpenMercantil no és una API oficial garantida; cal un pla B (scraping controlat o proveïdor comercial) i cachejar les respostes.
• Risc de producte: si el client només vol consultar i no governar, el valor cau; cal validar que l'alerta i l'informe són el motiu de pagament.

• Test de reconstrucció històrica: amb les dades de NAVEGA TELECOM SL, el sistema ha de respondre correctament "qui era administrador el 2024-07-17" (administrador únic) i "el 2024-07-18" (dos administradors solidaris), coherent amb