Перейти до змісту

ShipCore — Phase 2 Summary (cross-track synthesis)

Phase 2 закрито 2026-05-12 — 4 паралельні треки відпрацьовано з web-verified specs. Цей документ — синтез + recommended corrections перед Phase 3 (final concept).

0. Phase 2 deliverables

Трек Файл Розмір Web-access
1. Carrier APIs phase2-carrier-apis.md ~6500 слів ✅
2. EU compliance phase2-eu-compliance.md ~7000 слів ✅
3. UA-specific phase2-ua-integrations.md ~6700 слів ✅
4. Tracking + partnerships phase2-tracking-partnerships.md ~4300 слів ✅

Сумарно ~24500 слів verified research material.

1. 16 Phase 2 corrections (rolled-up)

Корекції до Phase 1 (revisions)

P2-R1 — WIN platform clarification (revision до C3): WIN — air-cargo connectivity hub (e-AWB до 160+ airlines), НЕ universal rate aggregator. Riege Scope використовує лише для air-leg. Implication: Phase 7 shipcore_pricing.LaneRateHistory — GO build tenant-private, як планувалось у Phase 0. WIN переноситься на Phase 9+ як partner для shipcore_avia (поряд з Awery).

P2-R2 — DCSA versions update (revision до C5): Поточні актуальні versions (May 2026): TNT 2.2 (Dec 2024), Booking 2.0 (Feb 2025), BL 3.0 (Feb 2025), VGM 1.0 (Nov 2025). Implication: standards-matrix.md потребує audit на застарілі v2.0.1 markings.

P2-R3 — Phase 8 effort revision (revision до roadmap): Phase 8 (full EU compliance) — ~16 weeks, не 6-10 як попередньо. Implication: v1.5 EU expansion realistically Q4 2026 - Q1 2027, не встигаємо ICS2 R3 deadline 2026-06-01 навіть з pull-forward. Чесна позиція: v1 = UA-only до Q4 2026 - Q1 2027.

Нові корекції з Phase 2 web research

P2-N1 — eFTI schema-agnostic architecture: Офіційна eFTI XSD НЕ опублікована публічно. eFTI4EU release 0.5 (Feb 2025) використовує власну схему на базі MMT-RDM. Implication: backend/shipcore/compliance/exporters/efti_*.py мають бути pluggable, schema-agnostic — не hard-coded XSD bind.

P2-N2 — ICS2 R3 via ITSP, не direct connect: Direct connect до 27 EU member states непрактично. Через ITSP (Descartes / AEB) — рекомендований path. Implication: Phase 8 shipcore.compliance/integrations/ics2.py — ITSP partner connector, не direct.

P2-N3 — eCMR hybrid: OLF self-host + TransFollow connector: Не "or", а "and". OLF (Apache-2.0, live June 2025) — для UA-internal eCMR generation. TransFollow connector — для cross-border партнерів які вже на TransFollow. Implication: compliance/exporters/ecmr.py має 2 backends — OlfBackend + TransfollowBackend, runtime selection.

P2-N4 — eBL hubs scope reduction: Phase 8 = CargoX + WaveBL primary (2 hubs). Enigio/TradeGo/IQAX(GSBN) — Phase 9+. Implication: integration-matrix §17 редукується з 5 до 2 P0 hubs.

P2-N5 — NCTS-P5 via AEB EU broker: Не direct connect (потребує certified party requirements). Через broker. Implication: Phase 8 NCTS connector — broker partnership, не власна реалізація.

P2-N6 — Sign-twice 2-phase rollout: Phase 4: signxml + Дія КЕП skeleton (test/mock). Phase 8: real Дія SDK integration + EU QTSP partnership для XAdES production. Implication: Phase 4 effort підтверджено ~5 weeks (+30% to 4-week base — як в C-eFTI-byDesign).

P2-N7 — Maersk pilot = sandbox-only demo: Production Maersk requires customer agreement. Pilot Wave 1 UA road carrier — sandbox-only demo для Phase 5. Implication: Phase 4-5 pilot — без real Maersk production data. Production traffic appears у Phase 5.5-6 after pilot validates workflow.

P2-N8 — CMA CGM two-tier entry strategy: Public API key (free 30-day trial — container milestones) → OAuth2 upgrade при production traffic. Implication: Phase 8 CMA integration cost-optimized — start free, scale paid.

P2-N9 — MSC skip до DCSA готовий: MSC eBL/Booking 2.0 scheduled, не live. EDI legacy НЕ рекомендую (cost EDI parser). Implication: MSC переноситься з Phase 8 P1 на Phase 8.5+ (after MSC DCSA готовий, ~2026-Q3+).

P2-N10 — Awery open-source PHP ONE Record server: Awery готує OSS PHP ONE Record reference server (5× IATA hackathon winner). Implication: Phase 9+ shipcore_avia ONE Record adapter може переюзати Awery OSS foundation, не з нуля. Outreach до Awery про licensing/contribution як partnership entry-point.

P2-N11 — УЗ Cargo direct API виявлено можливим: ЕТРАН помер, наслідник — АС Клієнт УЗ + е.Портал УЗ-Карго через ГІОЦ. API через B2B-договір + NDA (2-6 тижнів onboarding per tenant). Implication: Phase 6 shipcore_rail direct API — viable path, не fallback aggregator. AsMAP — для road, не rail (виправляє попередню Phase 1 assumption).

P2-N12 — eTTN 2 backends достатньо: Mandate 2027-01-01. 3 акредитовані Q4 2025 (Vchasno, M.E.Doc, EDI NETWORK) + ~6 нових 2026. Roaming через Мінрозвитку забезпечує cross-provider exchange. Implication: Phase 4 shipcore.compliance/exporters/ettn.py має 2 backends (Vchasno + M.E.Doc primary), EDI NETWORK as-needed.

P2-N13 — BAF Sync per-instance, не API standard: BAF — кожен instance унікальний. Не будувати "BAF API". Implication: backend/baf_sync/ залишається MVP-ready, two-layer strategy: direct HTTP-service для strong clients + EDI-bridge через Vchasno для mass-market.

P2-N14 — Customs API bonus (Phase 6 win): Держмитслужба офіційно відкрила API до митних декларацій. Не згадано раніше у нашій документації. Implication: Phase 6 shipcore.compliance/integrations/customs_ua.py — easy win. Замінює припускання що митні декларації йдуть тільки через QDPro/M.E.Doc.

P2-N15 — Banking Phase 5 expansion: Phase 5 — Privat24 Autoclient + Monobank Corporate + Raiffeisen Cash Management Open API (нова). FUIB у Phase 8. Решта (OTP/Universal) — file import (вже працює). Implication: Bank Exchange status з ⚠️ partial → ✅ ready після Phase 5.

P2-N16 — Black Sea Corridor = playbook, не integration: Не зовнішня інтеграція, а internal playbook + master data (CustomsBroker, InsuranceProvider, ePhytoCertificate, MarketCorridor) + corridor validation service. Unity insurance facility до $50M. Implication: Ізмаїл/Рені/Усть-Дунайськ — Phase 5.5 own TOS (за C1). Constanța через partner workflow, не direct integration.

2. Headline architectural impact

backend/shipcore/compliance/ остаточна структура (Phase 4 commit)

backend/shipcore/compliance/
├── exporters/
│   ├── efti_road.py          ← schema-agnostic, eFTI4EU 0.5 base
│   ├── efti_rail.py          ← same
│   ├── efti_iwt.py           ← same
│   ├── efti_air.py           ← reuses Awery PHP ONE Record OSS
│   ├── ecmr_olf.py           ← OLF self-host backend
│   ├── ecmr_transfollow.py   ← TransFollow connector backend
│   ├── ettn_vchasno.py       ← primary
│   ├── ettn_medoc.py         ← primary
│   ├── ettn_edi_network.py   ← as-needed
│   └── emswe.py              ← sea-specific (НЕ через eFTI)
├── signing/
│   ├── kep_dia_skeleton.py   ← Phase 4 mock/test
│   ├── kep_dia_real.py       ← Phase 8 real Дія SDK
│   ├── xades.py              ← signxml
│   └── sign_twice.py         ← cross-border UA→EU
├── integrations/
│   ├── ics2_itsp.py          ← Descartes/AEB partner connector (Phase 8)
│   ├── ncts_broker.py        ← AEB EU broker bridge (Phase 8)
│   ├── customs_ua.py         ← Держмитслужба API (Phase 6 bonus)
│   ├── ebl_cargox.py         ← Phase 8 primary
│   ├── ebl_wavebl.py         ← Phase 8 primary
│   └── uz_cargo_gioc.py      ← Phase 6 direct via ГІОЦ
├── mapping/
│   ├── ettn_to_ecmr.py
│   ├── ecmr_to_efti.py
│   ├── waybill_to_canonical.py
│   └── canonical_to_*.py     ← 3 projections з canonical Waybill
├── sanctions/
│   ├── eu_xml_feed.py        ← v1.5 baseline (verified URL)
│   ├── sanctions_io.py       ← v2 upgrade
│   └── compliance_advantage.py  ← enterprise tier
└── audit.py

Effort estimate (revised)

Phase Original (Phase 0) Revised (Phase 2) Зміна
Phase 4 (refactor + compliance foundation) 2-3 weeks ~5 weeks +30-40% (C-eFTI-byDesign)
Phase 5 (Sea + Maersk + CargoWise migration playbook) 4-6 weeks ~5-6 weeks без змін
Phase 5.5 NEW (Дунайські TOS) — 1-2 weeks NEW (P2-N16 + reaction на Octopi Romania)
Phase 6 (Rail + УЗ Cargo + Customs UA bonus) 3-4 weeks ~4 weeks без змін
Phase 7 (Quote builder + LaneRateView build) 2-3 weeks ~3 weeks +slightly (WIN cleared as non-fit)
Phase 8 (EU expansion full compliance) 4-6 weeks ~16 weeks 🔴 major revision — ICS2 ITSP + eCMR hybrid + eBL 2 hubs + NCTS broker + Sign-twice real Дія SDK + EU QTSP partnership + eFTI 4 connectors + sanctions Sanctions.io upgrade
Phase 9+ (Awery partnership + advanced) TBD TBD окрема conversation з Awery

Сумарно Phase 4-8: ~28-30 weeks ≈ 7-8 months at 1-2 sessions/week.

Calendar implications

Deadline Що ShipCore позиція
2026-06-01 ICS2 R3 mandatory для PL/RO/SK/HR/LV Не встигаємо. v1 = UA-only до Phase 8 — підтверджено. EU expansion v1.5 = Q4 2026 - Q1 2027
2027-01-01 eTTN UA mandatory Встигаємо через Phase 4 deliverable (Vchasno + M.E.Doc backends)
2027-07-09 eFTI mandatory для public authorities Встигаємо за Phase 8 (Q1 2027) — Phase 4 foundation готова, Phase 8 додає connectors
2030 DCSA eBL 100% adoption Залежить від CargoX/WaveBL hubs у Phase 8

3. Що НЕ змінюється з Phase 1

✅ Підтверджено без змін: - D1-D12 Phase 0 рішення (pricing flat / open-paid split / pilot wave UA road carrier → ZAMMLER / brand ShipCore / thin core / Carrier separate + Shipper/Consignee ролі / D9 Maersk first / D10 MarketCorridor / D11 hybrid tracking / D12 sanctions) - C1 (terminal scope bridge) — підтверджено - C2 (Awery partnership) — підтверджено + P2-N10 Awery OSS reuse opportunity - C4 (CargoWise migration playbook) — підтверджено - C5 (DCSA VGM REST) — підтверджено + P2-R2 version update до v1.0 - C6 (eBL interop hubs) — підтверджено + P2-N4 reduction до 2 hubs primary - C7 (v1 = UA-only) — підтверджено + Phase 8 effort revision робить calendar more realistic - C8 (pilot wave: UA road carrier архетип first) — підтверджено - C-eFTI-byDesign — підтверджено + P2-N1 schema-agnostic + P2-N6 sign-twice 2-phase

4. Phase 3 plan (наступна після Phase 2)

Phase 3 = final concept + sub-document rewrite на базі verified Phase 1+2 specs.

Phase 3 scope:

  1. Rewrite concept.md з outline до повного narrative (manifesto-варіація для ShipCore конкретно):
  2. § 1-8 за outline у concept.md stub
  3. Інкорпорувати всі Phase 1 + Phase 2 verified insights

  4. ~3000-4000 слів

  5. Update модулі (sub-документи):

  6. modules/auto.md, forwarder.md, sea.md, rail.md, terminal.md, avia.md — повні implementation specs з Phase 2 architectural decisions (моделі, services, integrations, Phase per module)

  7. Final roadmap.md rewrite з:

  8. Revised effort estimates (Phase 8 ~16 weeks)
  9. Calendar milestones (eTTN 2027-01-01 / eFTI 2027-07-09 / DCSA eBL 2030)
  10. Dependencies map

  11. Resource constraints + acceleration triggers

  12. README.md final update:

  13. Phase 0 + Phase 1 + Phase 2 closed sections
  14. Module map updated з final names + status
  15. Linkbacks до всіх Phase research deliverables

  16. Status legend

  17. Optional: standards-matrix.md audit на DCSA версії (P2-R2 fix)

Phase 3 budget:

  • 1-2 сесії (~2-3 години work)
  • Output: ~10-15K слів нового content + edit existing

Phase 3 deliverables:

  • Програмний документ (README.md) — final
  • Concept narrative (concept.md) — full
  • 6 module specs (modules/*.md) — implementation-ready
  • Roadmap (roadmap.md) — detailed з calendar
  • All Phase research files preserved у папці як reference

5. Open questions для Phase 3 spike-days

12+ невпевненостей з Phase 2 research що потребують verification перед Phase 4 commit.

Pricing transparency

  • TransFollow / Enigio / DigiCMR / IRU eCMR-EPD точні pricing tiers
  • Vchasno / M.E.Doc eTTN pricing tiers
  • WIN platform pricing (для Phase 9+ decision)

Technical specs

  • OLF eCMR tech stack — Java/Postgres assumed, не verified
  • Дія КЕП public REST API status — чи є production-ready integration path
  • UA QTSP в EUTL trust list — для cross-border XAdES recognition

Regulatory dates

  • NCTS-P6 EU MS dates
  • Greek EMSWe deadline (delayed status)
  • eFTI mandatory date для economic operators (2027-2029 expectation analytics, не зафіксовано в primary тексті)

Market intelligence

  • Awery actual response до partnership outreach
  • Maersk customer agreement onboarding timeline
  • УЗ Cargo / ГІОЦ B2B-договір реальні timelines (2-6 тижнів стверджено, треба verify)

6. Linkbacks

Phase 2 closed 2026-05-12. Phase 3 (final concept + sub-document rewrite) awaiting user trigger.