500+ integracji później: Dlaczego Subiekt GT wymaga innego podejścia niż Comarch Optima

Po 12 latach automatyzacji systemów ERP w Polsce i ponad 500 wdrożeniach integracji, wiemy jedno na pewno: nie ma czegoś takiego jak "uniwersalna integracja ERP". Każdy system ma swoją strukturę, swoje mocne strony i ograniczenia, które fundamentalnie wpływają na sposób integracji z handlem elektronicznym.

Dziś rozwiejemy mit o tym, że "integracja to integracja" i pokażemy, dlaczego firmy używające Subiekt GT potrzebują zupełnie innej strategii niż te pracujące z Comarch Optima. To wiedza wynikająca z setek godzin debugowania, tysięcy linii kodu i dziesiątków projektów ratunkowych dla firm, które próbowały zastosować "uniwersalne" podejście.

Fundamentalne różnice w architekturze systemów

Subiekt GT/nexo: ERP "wzrastający" z polskim rynkiem

Historia i filozofia: Subiekt GT powstał jako odpowiedź na potrzeby polskich małych i średnich firm. Przez lata ewoluował organicznie, dodając funkcje w odpowiedzi na zmieniające się wymagania polskiego rynku. To system "wzrastający" - każda wersja dodawała nowe warstwy funkcjonalności na istniejące fundamenty.

Kluczowe cechy architektury Subiekt GT:

Struktura bazy danych: Rozbudowane, ale nie zawsze znormalizowane tabele z wieloma polami dziedzictwa
Logika biznesowa: Wbudowana głęboko w strukturę bazy danych
Mechanizmy interfejsu programistycznego: Relatywnie nowe, często nakładane na starszą architekturę
Filozofia danych: "Wszystko w jednym miejscu" - rozbudowane tabele z wieloma informacjami

Comarch Optima: Myślenie przedsiębiorstwa w średniej firmie

Historia i filozofia: Comarch Optima to produkt firmy z ambicjami przedsiębiorstwa, który został dostosowany do rynku SME. Powstał z myślą o skalowalności i standardyzacji procesów biznesowych. To system "zaprojektowany" - architektura była planowana z góry pod kątem różnych scenariuszy użytkowania.

Kluczowe cechy architektury Comarch Optima:

Struktura bazy danych: Bardziej znormalizowana, modułowa architektura
Logika biznesowa: Częściowo wydzielona do warstwy aplikacyjnej
Mechanizmy interfejsu programistycznego: Projektowane od początku jako część architektury
Filozofia danych: "Separacja odpowiedzialności" - wyspecjalizowane tabele i moduły

Praktyczne różnice w integracjach handlu elektronicznego

1. Zarządzanie produktami - dwa różne światy

Subiekt GT - wyzwania z produktami:

Warianty produktów:

-- Subiekt GT - warianty jako osobne produkty
Products: 
ID: 1001, Name: "Koszula Biała M", ParentID: NULL
ID: 1002, Name: "Koszula Biała L", ParentID: NULL  
ID: 1003, Name: "Koszula Biała XL", ParentID: NULL

W Subiekt GT warianty produktów (rozmiary, kolory) są często traktowane jako osobne produkty. To oznacza, że:

Synchronizacja: Trzeba grupować warianty ręcznie lub przez konwencje nazewnictwa
Zarządzanie stanami: Każdy wariant ma osobny stan magazynowy
Ceny: Mogą być różne dla każdego wariantu
Wyzwanie SEO: Ryzyko duplikacji treści na stronie sklepu

Praktyczne rozwiązanie dla Subiekt GT:

Implementacja warstwy mapowania wariantów
Algorytmy grupowania na podstawie wzorców nazw
Niestandardowa logika dla deduplikacji na poziomie sklepu

Comarch Optima - strukturalne podejście do wariantów:

-- Comarch Optima - właściwe relacje wariantów
ProductMaster: ID: 100, Name: "Koszula", Type: "Variable"
ProductVariants: 
  ID: 1001, MasterID: 100, Size: "M", Color: "Biała"
  ID: 1002, MasterID: 100, Size: "L", Color: "Biała"

W Comarch Optima warianty są strukturalnie powiązane:

Czyste relacje: Relacja nadrzędny-podrzędny między produktem głównym a wariantami
Ujednolicone zarządzanie: Zarządzanie na poziomie produktu głównego
Strukturalne atrybuty: Atrybuty wariantów w dedykowanych polach
Czysta synchronizacja: Naturalne mapowanie na struktury handlu elektronicznego

2. Obsługa zamówień - różne logiki biznesowe

Subiekt GT - workflow dokumentów:

Subiekt GT ma złożony system stanów dokumentów, który odzwierciedla realne procesy w polskich firmach:

Zamówienie → Rezerwacja → Wydanie → Faktura → Płatność

Wyzwania integracyjne:

Wiele typów dokumentów: Każdy etap to osobny dokument w systemie
Złożoność statusów: Stan zamówienia składa się z statusów kilku dokumentów
Logika rezerwacji: Skomplikowana logika rezerwacji stanów
Niestandardowe przepływy pracy: Każda firma może mieć inny przepływ

Praktyczny przykład problemu z cenami: Sklep internetowy potrzebuje wyświetlić ceny dla różnych grup klientów:

Cena detaliczna (tw_cena1)
Cena hurtowa (tw_cena2)
Cena dla VIP (tw_cena3)
Ceny promocyjne (tw_cena4-tw_cena10)

Problem: Co jeśli potrzebujesz 15 różnych cen? Subiekt GT ma limit 10 cen na produkt.

Rozwiązanie dla Subiekt GT:

// Workaround dla limitów cenowych Subiekt GT
function getProductPrice(productId, customerType, quantity) {
  const product = getProductFromSubiekt(productId);
  
  // Mapping statycznych cen z Subiekt GT
  const priceMapping = {
    'retail': product.tw_cena1,
    'wholesale': product.tw_cena2,
    'vip': product.tw_cena3,
    'promotion1': product.tw_cena4,
    'promotion2': product.tw_cena5
    // Tylko 10 cen dostępnych...
  };
  
  // Dla dodatkowych cen musimy użyć external logic
  if (customerType === 'super_vip') {
    return calculateCustomPrice(product.tw_cena1, 0.85); // 15% rabat
  }
  
  return priceMapping[customerType] || product.tw_cena1;
}

Comarch Optima - procesowe podejście:

Comarch ma bardziej standardowe podejście do przepływu zamówień:

Order → ProcessingStatus → FulfillmentStatus → InvoiceStatus

Zalety dla integracji:

Jasna hierarchia statusów: Przejrzysta hierarchia statusów
Standardowy przepływ pracy: Przepływ bliższy standardom handlu elektronicznego
Przyjazny dla interfejsów: Statusy zaprojektowane z myślą o integracji
Sterowany zdarzeniami: Możliwość subskrypcji zmian statusów

3. Zarządzanie cenami - filozoficzne różnice

Subiekt GT - ceny "limitowane i proste":

-- Subiekt GT - wszystkie ceny w jednej tabeli
tw_Ceny: 
  tw_id, tw_symbol, tw_cena1, tw_cena2, tw_cena3, tw_cena4, tw_cena5,
  tw_cena6, tw_cena7, tw_cena8, tw_cena9, tw_cena10

Charakterystyka:

Single-table pricing: Wszystkie ceny produktu w jednej tabeli (tw_Ceny)
Limited price variants: Maksymalnie 10 różnych cen na produkt (tw_cena1 do tw_cena10)
No explicit customer pricing: Brak dedykowanych cen dla konkretnych klientów
Simple structure: Prosta struktura, ale ograniczona elastyczność

Wyzwanie integracyjne: Główne problemy z cenami w Subiekt GT:

Ograniczenie do 10 cen - nie można mieć więcej wariantów cenowych
Brak customer-specific pricing - nie ma tabeli z cenami dla konkretnych klientów
Manual mapping - trzeba ręcznie mapować tw_cena1, tw_cena2 etc. na logikę biznesową
No price history - brak wersjonowania i historii zmian cen
Limited promotion support - promocje nie są zintegrowane z systemem cen

Comarch Optima - strukturalne zarządzanie cenami:

-- Comarch Optima - bardziej ustrukturyzowane podejście
PriceLists: ID, Name, Currency, ValidFrom, ValidTo
PriceListItems: PriceListID, ProductID, Price
CustomerPriceLists: CustomerID, PriceListID, Priority

Charakterystyka:

Logika cenników: Jasna logika cenników
Hierarchiczne priorytety: Strukturalna hierarchia priorytetów
Czysta separacja: Separacja cen standardowych od promocyjnych
Zoptymalizowana dla interfejsów: Łatwiejsza synchronizacja przez interfejs programistyczny

Różnice w podejściu do integracji API

Subiekt GT - platforma integracyjna Sfera

Charakterystyka interfejsu Subiekt GT przez Sfera:

Rozwiązanie zewnętrzne: Interfejs dostępny przez platformę Sfera, nie natywny Subiekt GT
Wymagany rozwój niestandardowy: Większość funkcji wymaga niestandardowego kodowania w Sfera
Ograniczone gotowe rozwiązania: Podstawowe operacje dostępne, zaawansowane wymagają rozwoju
Złożoność integracji: Trzeba znać zarówno Subiekt GT jak i środowisko Sfera

Praktyczny przykład - pobieranie zamówienia przez Sfera:

// Sfera API - wymaga custom development
const sferaAPI = require('@sfera/subiekt-connector');

// Custom kod dla pobierania zamówienia
async function getOrderDetails(orderId) {
  // 1. Połączenie z bazą Subiekt GT przez Sfera
  const connection = await sferaAPI.connect({
    host: 'localhost',
    database: 'SubiektGT_db',
    credentials: credentials
  });
  
  // 2. Custom query - musimy sami napisać logikę
  const orderData = await connection.query(`
    SELECT dh.*, dk.* 
    FROM DokHandlowy dh 
    LEFT JOIN DokHandlowy_Pozycja dk ON dh.dh_id = dk.dk_dokument
    WHERE dh.dh_id = ?
  `, [orderId]);
  
  // 3. Manual data transformation
  const transformedOrder = {
    id: orderData[0].dh_id,
    customer: await getCustomerData(orderData[0].dh_klient),
    items: await transformOrderItems(orderData),
    status: await calculateOrderStatus(orderId)
  };
  
  return transformedOrder;
}

Wyzwania rozwoju z Sfera:

Custom logic required: Większość funkcji biznesowych musi być zakodowana od zera
Database knowledge needed: Trzeba znać strukturę bazy Subiekt GT
No pre-built endpoints: Brak gotowych endpointów dla typowych operacji e-commerce
Maintenance overhead: Custom kod wymaga utrzymania przy aktualizacjach Subiekt GT

Strategia integracji z Subiekt GT + Sfera:

Database-first approach: Direct access do bazy danych przez Sfera connectors
Custom middleware development: Budowanie własnej warstwy abstrakcji
Business logic implementation: Kodowanie reguł biznesowych w Sfera environment
Testing complexity: Każda zmiana w Subiekt GT może wpłynąć na custom kod

Comarch Optima - zaprojektowany dla integracji

Charakterystyka interfejsu Comarch Optima:

Prawdziwy RESTful: Konsekwentne stosowanie standardów REST
Kompleksowe pokrycie: Większość funkcji dostępna przez interfejs programistyczny
Nowoczesna architektura: Zaprojektowane z myślą o integracji
Zoptymalizowana wydajność: Efektywne zapytania, operacje masowe

Ten sam przykład - pobieranie zamówienia:

GET /api/orders/123?expand=items,customer,status
# Jedno zapytanie zwraca kompletne dane

Strategia integracji z Comarch Optima:

Bezpośrednie wykorzystanie interfejsu: Większość operacji bezpośrednio przez interfejs programistyczny
Synchronizacja w czasie rzeczywistym: Możliwość efektywnej synchronizacji w czasie rzeczywistym
Standardowe wzorce: Zastosowanie standardowych wzorców integracyjnych
Wsparcie powiadomień: Lepsze wsparcie dla integracji sterowanej zdarzeniami

Case Studies - rzeczywiste wdrożenia

Case Study 1: Firma odzieżowa z Subiekt GT

Wyzwanie: Internetowy sklep odzieżowy z 15,000 produktów w 1,200 wariantach (rozmiary/kolory). Subiekt GT traktował każdy wariant jako osobny produkt.

Problem:

Sklep internetowy miał 15,000 osobnych produktów zamiast 1,200 z wariantami
Duplikacja treści SEO
Chaos w nawigacji sklepu
Niemożność efektywnego zarządzania stanami

Rozwiązanie:

// Custom middleware dla grupowania wariantów
function groupVariants(products) {
  return products.reduce((groups, product) => {
    const baseCode = extractBaseCode(product.code);
    if (!groups[baseCode]) {
      groups[baseCode] = {
        master: product,
        variants: []
      };
    }
    groups[baseCode].variants.push(product);
    return groups;
  }, {});
}

Rezultaty:

87% redukcja duplikatów na stronie
45% poprawa w SEO rankings
60% szybsze zarządzanie asortymentem
23% wzrost konwersji dzięki lepszej UX

Studium przypadku 2: Dystrybutor elektroniki z Comarch Optima

Wyzwanie: B2B dystrybutor z kompleksowym systemem cen: ceny podstawowe, rabaty wolumenowe, ceny specjalne dla partnerów strategicznych, promocje czasowe.

Zaleta Comarch Optima: Strukturalna obsługa wielu cenników pozwoliła na elegancką integrację:

-- Mapowanie struktury cennej Comarch na e-commerce
SELECT 
  p.ProductID,
  CASE 
    WHEN sp.Price IS NOT NULL THEN sp.Price  -- Cena specjalna
    WHEN vp.Price IS NOT NULL THEN vp.Price  -- Cena wolumenowa  
    ELSE bp.Price                            -- Cena podstawowa
  END as FinalPrice
FROM Products p
LEFT JOIN BasePriceList bp ON p.ProductID = bp.ProductID  
LEFT JOIN VolumePriceList vp ON p.ProductID = vp.ProductID AND vp.MinQty <= @quantity
LEFT JOIN SpecialPrices sp ON p.ProductID = sp.ProductID AND sp.CustomerID = @customerID

Rezultaty:

100% accurateness w cenach B2B
Real-time pricing dla różnych segmentów klientów
40% redukcja czasu zarządzania cenami
15% wzrost marży dzięki lepszemu pricing

Praktyczne rekomendacje wyboru podejścia

Kiedy wybrać Subiekt GT?

Profil firmy:

SME z polskimi procesami: 10-200 pracowników, typowe polskie workflow
Handel tradycyjny + e-commerce: Firmy łączące sprzedaż stacjonarną z internetową
Budget-conscious: Ograniczony budżet na ERP i integrację
Growth-oriented: Firmy w fazie dynamicznego rozwoju

Optymalne scenariusze dla Subiekt GT:

Sklepy z relatywnie prostym asortymentem (do 5,000 SKU)
B2C z elementami B2B
Firmy potrzebujące flexibility w procesach biznesowych
Quick wins na początek automatyzacji

Strategia integracji dla Subiekt GT:

Fazowane wdrażanie: Start od podstawowej synchronizacji
Custom development: Plan na custom logic dla specyficznych potrzeb
Performance optimization: Focus na caching i batch processing
Long-term roadmap: Przygotowanie na przyszłe migracje

Kiedy wybrać Comarch ERP?

Profil firmy:

Larger SME/Enterprise: 100+ pracowników, złożone procesy biznesowe
Multi-channel, multi-warehouse: Kompleksne operacje logistyczne
Scale-oriented: Planowany szybki wzrost lub high-volume operations
Process standardization: Potrzeba ustandaryzowania procesów

Optymalne scenariusze dla Comarch ERP:

Duże katalogi produktów (10,000+ SKU)
Kompleksowa sprzedaż B2B z indywidualnym pricing
Multi-company operations
Integracje z external systems (CRM, WMS, BI)

Strategia integracji dla Comarch ERP:

API-first approach: Maximizing native API capabilities
Real-time integration: Focus na real-time sync gdzie możliwe
Standardized patterns: Wykorzystanie industry-standard integration patterns
Scalability planning: Architektura zaprojektowana pod przyszły wzrost

Błędy których należy unikać

Uniwersalne błędy integracyjne

Błąd #1: "One size fits all" mentality

// ŹRÓDŁO PROBLEMÓW - generyczne podejście
function syncProducts(erpSystem, products) {
  // Jeden kod dla wszystkich systemów ERP
  products.forEach(product => {
    erpSystem.createProduct(product);
  });
}

// POPRAWNE PODEJŚCIE - system-specific logic
function syncProducts(erpSystem, products) {
  if (erpSystem.type === 'SubiektGT') {
    return syncProductsSubiektGT(products);
  } else if (erpSystem.type === 'ComarchERP') {
    return syncProductsComarchERP(products);
  }
}

Błąd #2: Ignorowanie ograniczeń systemowych

Próba real-time sync tam gdzie system nie jest na to przygotowany
Nie uwzględnianie performance limitations
Zakładanie capabilities które system nie ma

Błąd #3: Brak fallback strategies

Nie planowanie scenariuszy awarii
Brak manual override options
Nie przewidywanie edge cases

Subiekt GT - specificzne pułapki

Pułapka #1: Variant management

// PROBLEM - traktowanie wariantów jak osobne produkty
products.forEach(product => {
  createProductInShop(product); // 1000 wariantów = 1000 produktów
});

// ROZWIĄZANIE - grupowanie wariantów
const groupedProducts = groupProductVariants(products);
groupedProducts.forEach(productGroup => {
  createProductWithVariants(productGroup.master, productGroup.variants);
});

Pułapka #2: Limited pricing flexibility

// PROBLEM - nie można przekroczyć 10 cen w Subiekt GT
const customerTypes = [
  'retail', 'wholesale', 'vip', 'distributor', 'partner',
  'seasonal1', 'seasonal2', 'promotion1', 'promotion2', 'clearance',
  'loyalty_tier1', 'loyalty_tier2', 'corporate', 'government', 'export'
]; // 15 typów cen - ale Subiekt GT ma tylko 10 slotów!

// ROZWIĄZANIE - hybrid approach z external pricing logic
function getPriceForCustomer(productId, customerType, quantity) {
  const subiektPrices = getSubiektPrices(productId); // tw_cena1-tw_cena10
  
  // Core prices z Subiekt GT
  const corePrices = {
    'retail': subiektPrices.tw_cena1,
    'wholesale': subiektPrices.tw_cena2,
    'vip': subiektPrices.tw_cena3,
    // ... do tw_cena10
  };
  
  // Extended pricing logic outside Subiekt GT
  if (corePrices[customerType]) {
    return corePrices[customerType];
  } else {
    return calculateExternalPrice(subiektPrices.tw_cena1, customerType, quantity);
  }
}

Pułapka #3: Document workflow assumptions Zakładanie że stan zamówienia w e-commerce odpowiada pojedynczemu dokumentowi w Subiekt GT.

Comarch ERP - specifyczne wyzwania

Wyzwanie #1: Over-engineering

// PROBLEM - niepotrzebna złożoność
class ComplexPricingEngine {
  calculatePrice(product, customer, quantity, date, location, channel) {
    // 500 linii kodu dla prostej ceny
  }
}

// ROZWIĄZANIE - start simple, scale smart
function getPrice(productId, customerId) {
  return comarchAPI.getPrice(productId, customerId);
}

Wyzwanie #2: API over-reliance Założenie że wszystko można zrobić przez API - czasem potrzeba direct database access.

Wyzwanie #3: Performance optimization Comarch API jest powerful, ale może być slow dla bulk operations.

Przyszłość integracji ERP w Polsce

Trendy technologiczne 2025-2027

Ewolucja oprogramowania pośredniczącego:

Architektura sterowana zdarzeniami staje się standardem
Mikrousługi dla warstw integracyjnych
Mapowanie wspomagane sztuczną inteligencją i czyszczenie danych
Platformy integracyjne z minimalnym kodowaniem

Standaryzacja interfejsów programistycznych:

OpenAPI 3.0 jako standard dokumentacji
GraphQL dla elastycznych zapytań o dane
Standardy powiadomień dla komunikacji w czasie rzeczywistym
OAuth 2.0/OIDC dla bezpieczeństwa

Plan rozwoju Subiekt GT

Co się zmienia:

nexo (nowa generacja) z nowoczesnym interfejsem programistycznym
Podejście "chmura w pierwszej kolejności" w nowych wersjach
Dostosowanie do KSeF - obowiązkowe e-faktury od 2026 roku
Compliance z nowymi przepisami - automatyczne dostosowywanie do zmian prawnych

Strategia przygotowania:

Plan migracji do nexo dla długoterminowych korzyści
Rozwiązania tymczasowe dla obecnego Subiekt GT
Inwestycja w elastyczną warstwę integracyjną
Przygotowanie na wymagania KSeF i nowe regulacje

Ewolucja Comarch Optima

Kierunek rozwoju:

Projektowanie z interfejsem w centrum dla wszystkich modułów
Rozszerzenie możliwości sterowanych zdarzeniami
Dostosowanie do KSeF - pełna integracja z Krajowym Systemem e-Faktur

Przygotowanie strategiczne:

Wykorzystanie istniejących możliwości interfejsu
Plan dla rozszerzonych scenariuszy automatyzacji
Inwestycja w możliwości integracji w czasie rzeczywistym
Przygotowanie do przepływów pracy zgodnych z KSeF

Podsumowanie: Wybór strategii na lata

Po 500+ integracjach i 12 latach doświadczenia widzimy jeden kluczowy wzorzec: nie ma złych systemów ERP, są tylko źle dopasowane strategie integracji.

Kluczowe wnioski:

Subiekt GT to doskonały wybór gdy:

Potrzebujesz flexibility w procesach biznesowych
Masz ograniczony budżet na start
Planujesz organic growth
Zespół ma ograniczoną ekspertyzę techniczną
Quick wins są priorytetem

Comarch Optima to optymalna opcja gdy:

Planujesz skalę i standardyzację
Masz budżet na właściwą implementację
Możliwości interfejsu programistycznego są kluczowe
Potrzebujesz zaawansowanych funkcji od początku
Długoterminowy zwrot z inwestycji jest priorytetem

Najważniejsza rada:

Inwestuj w elastyczną warstwę integracyjną niezależnie od wybranego ERP. Systemy się zmieniają, firmy rosną, wymagania ewoluują. Warstwa integracyjna która może adaptować się do zmian to najlepsza inwestycja w przyszłość Twojej firmy.

Pytanie nie brzmi "Subiekt GT czy Comarch Optima?"
Pytanie brzmi "Jak zbudować strategię integracji która będzie działać przez następne 5 lat?"

Orbis Software - 12 lat doświadczenia w integracjach ERP, 500+ projektów z Subiekt GT, Comarch Optima, Enova365. Potrzebujesz pomocy w wyborze strategii integracji? Umów bezpłatną konsultację z ekspertami, którzy przez lata pracowali z obiema platformami.

Problemy z integracją zwrotów niezależnie od systemu ERP? Sprawdź Zwroteo.com.pl - universal platform do automatyzacji zwrotów dla każdego systemu.

Kategoria: erp

Autor: Orbis Software Polska | Data publikacji: 14.07.2025