Katalog produktów z wariantami i zestawami: schemat i wzorce UI

Dlaczego warianty i zestawy szybko się komplikują

Katalog wydaje się prosty, gdy każdy produkt to jeden przedmiot z jedną ceną i jednym stanem magazynowym. Dodaj kolor, rozmiar, długość subskrypcji czy opakowanie zależne od regionu i ta prostota pryska. Jedna tabela „Produkty” nie potrafi już odpowiedzieć na podstawowe pytania: co dokładnie sprzedajemy i jak to śledzić?

Klienci też oczekują poprawnych informacji. Chcą wybierać opcje, widzieć właściwą cenę od razu i wiedzieć, czy ich dokładny wybór może być wysłany dziś. Jeśli strona mówi „Na stanie”, a wybrany rozmiar jest niedostępny, zaufanie szybko spada. Jeśli cena zmienia się dopiero przy realizacji zamówienia, pojawiają się zgłoszenia do obsługi i zwroty.

Zestawy dodają drugi poziom złożoności, bo wyglądają jak produkty, ale zachowują się jak reguły. „Starter Kit” może zawierać butelkę, pompkę i zestaw filtrów. Jego dostępność zależy od części, a koszty i raporty nadal muszą być sensowne.

Znaki, że katalog zaczyna pękać:

• Tworzysz duplikaty SKU tylko po to, by przedstawić opcję.
• Liczniki stanu wydają się niepoprawne, szczególnie po sprzedaży zestawów.
• Ekrany administracyjne stają się długimi listami niemal identycznych pozycji.
• Rabaty i podatki działają dla pojedynczych artykułów, ale psują się dla kitów.
• Raporty nie potrafią odpowiedzieć „co właściwie sprzedano?”

Naprawa to w dużej mierze dyscyplina: model danych, który pozostaje spójny, i wzorce UI, które jasno pokazują wybór opcji i dostępność klientom i zespołowi.

Terminy w prostym języku: opcje, warianty, SKU, zestawy

Kiedy ludzie mówią „warianty”, często mieszają kilka różnych pojęć. Ustalenie słów na początku ułatwia późniejsze decyzje (schemat, UI, zapasy).

Większość zespołów używa takich definicji:

• Opcja: wybór, który może zrobić kupujący, np. Rozmiar lub Kolor.
• Wartość opcji: pojedyncza wartość w opcji, np. Rozmiar = M lub Kolor = Czarny.
• Wariant: dokładna kombinacja wartości opcji, np. Rozmiar M + Kolor Czarny.
• SKU: jednostka sprzedawalna, którą śledzisz w operacjach i zapasach. Wariant często mapuje się na jeden SKU, ale nie zawsze.
• Zestaw / kit / multipak: produkt złożony z innych produktów. Bundle to grupa marketingowa (części można sprzedawać osobno). Kit to zestaw, który „musi być wysłany razem”. Multipack to ten sam przedmiot powtórzony (3-pak skarpetek).

W praktyce mylą się też identyfikatory. ID wewnętrzne to to, czego używa baza danych. SKU to kod operacyjny (do kompletacji, uzupełniania i raportów). Kod kreskowy (UPC/EAN) to to, co skanery czytają. Jedno SKU może mieć wiele kodów kreskowych (różne regiony) i niektóre przedmioty mogą nie mieć wcale kodu.

Dobra zasada, czy coś powinno być wariantem sprzedawalnym: jeśli może mieć inną cenę, zapas, wagę lub reguły wysyłki — traktuj to jako sprzedawalne. Ta sama koszulka w rozmiarze M i XL zwykle potrzebuje oddzielnych stanów, więc powinny to być osobne SKU.

Zdecyduj, co twój katalog musi wspierać

Zanim wybierzesz schemat, zacznij od pytań, na które biznes musi odpowiadać codziennie. Gdy ktoś ogląda przedmiot, czy możesz z pewnością powiedzieć: czy jest dostępny teraz, ile kosztuje, jak zostanie wysłany i jakie reguły podatkowe obowiązują?

Przydatny sposób myślenia to zdecydować, gdzie „żyje” każde „fakt”. Umieść wspólne fakty na produkcie, a zmienne fakty na wariancie (SKU). Jeśli je wymieszasz, będziesz naprawiać ten sam błąd w dwóch miejscach.

Pytania, które zwykle decydują o polu na poziomie produktu vs wariantu:

• Jeśli zmienia się w zależności od rozmiaru/koloru/materiału — należy do wariantu.
• Jeśli jest prawdziwe dla każdej kombinacji opcji — należy do produktu.
• Jeśli raportujesz to per SKU (sprzedaż, marża, zwroty) — przechowuj per wariant.
• Jeśli operacje używają tego do kompletacji/pakowania/wysyłki — przechowuj tam, gdzie pracuje magazyn: na SKU.
• Jeśli można to bezpiecznie wyprowadzić (np. nazwa wyświetlana z wartości opcji), wyprowadzaj ją i przechowuj tylko źródło.

Trzymaj jedno źródło prawdy. Na przykład nie przechowuj „ceny” równocześnie na produkcie i wariancie, chyba że role są jasne (np. produkt ma MSRP, wariant ma faktyczną cenę sprzedaży).

Planuj zmiany. Możesz dodać nową opcję później (np. „Długość”), wycofać wariant lub połączyć SKU po zmianie dostawcy. To przebiega łatwiej, gdy warianty są pełnoprawnymi rekordami, a nie samymi etykietami.

Jeśli budujesz w AppMaster, czytelne nazewnictwo encji w Data Designer ułatwia utrzymanie, gdy wymagania się zmieniają.

Praktyczny schemat dla produktów i wariantów

Czysty schemat utrzymuje katalog czytelnym, gdy prosty produkt zamienia się w dziesiątki kombinacji sprzedawalnych. Cel to modelować wybory (co wybierają klienci) oddzielnie od sprzedawalnych przedmiotów (co faktycznie magazynujesz i wysyłasz).

Zestaw przydatnych encji:

• Product: element nadrzędny (nazwa, opis, marka, kategoria, domyślne zdjęcia)
• Option: typ wyboru (Rozmiar, Kolor)
• OptionValue: dozwolone wartości (Small, Medium, Red, Blue)
• Variant: jednostka sprzedawalna (jedna kombinacja wartości)
• VariantOptionValue: tabela połączeń łącząca Variant z jego OptionValues

Unikalność wariantów to miejsce, gdzie wiele katalogów popełnia błędy. Najbezpieczniejsze podejście to normalizacja: wymuś jedną wartość opcji na opcję dla każdego wariantu i zapobiegaj duplikowaniu kombinacji. Jeśli chcesz też szybkości, przechowuj obliczony „klucz wariantu” np. color=red|size=m (lub jego hash) na wariancie i egzekwuj unikalność per Product.

Trzymaj pola, które zmieniają się w zależności od kombinacji, na Variant, nie na Product: SKU, barcode, price, compare-at price, cost, weight, wymiary, status (aktywny/wycofany) i obrazy (jeden główny obraz lub mały zestaw obrazów).

Dla atrybutów niestandardowych (np. „materiał” czy „instrukcje pielęgnacji”) unikaj wiecznego dodawania nowych kolumn. Pole JSONB na Product lub Variant dobrze działa w PostgreSQL, sparowane z małą warstwą walidacji w aplikacji.

Zasady SKU, które przetrwają w czasie

SKU to identyfikator jednostki sprzedawalnej, który obiecujesz utrzymać stabilnym. Powinien odpowiadać na jedno pytanie: „Który dokładny przedmiot sprzedaliśmy?” Nie powinien przenosić nazwy marketingowej, pełnego tekstu opcji, sezonu ani całej historii. Jeśli go przeciążysz, ciężko będzie cokolwiek zmienić później bez łamania raportów.

Zdecyduj wcześnie, czy SKU są nadawane ręcznie, czy generowane. Ręczne SKU są bezpieczniejsze, gdy masz już ERP, kody kreskowe lub SKU dostawcy, które muszą się zgadzać. Generowane SKU są praktyczne, gdy masz dużo wariantów i potrzebujesz spójności, ale tylko jeśli zasady się nie zmienią w trakcie roku. Popularny kompromis to stałe bazowe SKU, które kontrolujesz, plus krótki generowany sufiks dla atrybutów wariantu.

Zasady, które są czytelne i przetrwają rozrost:

• Trzymaj SKU stabilne po złożeniu zamówienia. Nigdy „nie poprawiaj” starych SKU przez ich zmianę.
• Oddziel ID wewnętrzne od SKU. Używaj SKU dla ludzi, ID dla bazy.
• Używaj krótkich prefiksów dla rodzin produktów (np. TSH, MUG), nie pełnych słów.
• Unikaj znaczeń, które mogą się zmienić (np. „2026” lub „SUMMER”), chyba że biznes naprawdę tak działa.

Wycofanych SKU nie usuwaj. Oznacz je jako nieaktywne, zachowaj historię cen i trzymaj je wybieralne w starych zamówieniach, zwrotach i raportach. Jeśli zastępujesz SKU, przechowaj odwołanie „zastąpiony przez”, by wsparcie mogło prześledzić zmianę.

Reguły walidacji zapobiegają powolnemu psuciu się: wymuś unikalność SKU wśród wszystkich sprzedawalnych przedmiotów, pozwalaj tylko na litery, cyfry i myślniki, ustaw jasną maksymalną długość (zwykle 20–32 znaki) i zarezerwuj prefiksy dla przypadków specjalnych (np. „BND-” dla zestawów). W AppMaster te sprawdzenia pasują do ograniczeń danych plus procesu biznesowego blokującego zapis przy naruszeniu reguł.

Logika zapasów wykraczająca poza proste „na stanie/wyprzedane”

Zapasy komplikują się, gdy ten sam „produkt” może oznaczać wiele sprzedawalnych jednostek. Zanim napiszesz reguły, wybierz jednostkę zapasową: czy śledzisz zapas na poziomie produktu, wariantu, czy obu?

Jeśli klienci wybierają rozmiar lub kolor, zwykle bezpieczniej jest śledzić zapas na poziomie wariantu. Koszulka może być „na stanie” ogólnie, ale wariant Small-Blue może być wyprzedany. Poziom produktu działa dla rzeczy, gdzie warianty nie zmieniają fizycznego przechowywania (np. licencja cyfrowa z różnymi planami). Niektóre zespoły trzymają oba: poziom produktu dla raportów, wariant dla sprzedaży.

Zapobieganie oversellingowi to nie pojedynczy magiczny flag, a jasne stany. Większość katalogów potrzebuje rezerwacji (przytrzymaj jednostki krótko dla koszyków lub nieopłaconych zamówień), backorderów (pozwól na sprzedaż z jasnymi datami wysyłki), buforów stanu (ukryta ilość na pokrycie opóźnień synchronizacji) i atomowych aktualizacji (zmniejsz zapas w tej samej operacji, która potwierdza zamówienie).

Sytuacje brzegowe to źródło „tajemniczego zapasu”. Zwroty powinny dodawać zapas dopiero po inspekcji, nie przy wygenerowaniu etykiety zwrotnej. Uszkodzone przedmioty powinny przejść do osobnego statusu lub lokalizacji, żeby nie były widoczne jako sprzedawalne. Korekty stanu potrzebują śladu audytu (kto, co i dlaczego), zwłaszcza jeśli wiele kanałów aktualizuje zapasy.

Zestawy i kity wymagają jednej kluczowej zasady: nie zmniejszaj rekordu „bundle”, jeśli bundle jest tylko grupowaniem. Pomniejszaj przedmioty składowe. 3-pak powinien zmniejszyć trzy jednostki tego samego SKU; kit powinien zmniejszyć po jednej jednostce każdego komponentu.

Przykład: „Starter Kit” zawiera 1 butelkę i 2 filtry. Jeśli masz 10 butelek i 15 filtrów, dostępność kitu to 7, ponieważ filtry są ograniczeniem. Matematyka oparta na komponentach utrzymuje raportowanie, zwroty i uzupełnianie spójne.

W AppMaster mapuje się to naturalnie na tabele wariantów w Data Designer i logikę rezerwacji/dekrementacji w Edytorze procesów biznesowych, tak aby każdy checkout przestrzegał tych samych reguł.

Modelowanie zestawów i kitów bez łamania raportów

Zestawy to miejsce, gdzie katalogi często zbaczają w stronę wyjątków. Najprostsze podejście to modelować zestawy jako normalne sprzedawalne pozycje, a następnie dołączać przejrzystą listę komponentów.

Czysta struktura: Product (sprzedawalny) plus BundleLines. Każda BundleLine wskazuje komponentowy SKU (lub produkt komponentowy plus wymagany wariant) i przechowuje ilość. Zamówienia dalej pokazują „jeden przedmiot”, ale możesz je rozwinąć do części, gdy potrzebujesz kosztów, zapasów i szczegółów realizacji.

Większość setupów pasuje do jednego z typów:

• Fixed bundle (kit): zawsze te same komponenty i ilości.
• Configurable bundle: klient wybiera z dozwolonych komponentów (zapisane jako linie w zamówieniu).
• Virtual bundle: grupowanie marketingowe (zwykle bez efektu na zapasy), użyteczne do merchandisingu bez wymuszania logiki fulfillmentu.

Ceny to miejsce, gdzie zespoły przypadkowo łamią raporty. Zdecyduj z góry, co pojawia się na linii zamówienia i co zasila raporty marży i zapasów. Typowe podejścia: stała cena pakietu, suma części lub zdyskontowana suma z regułami per komponent (np. „wybierz dowolne 3, najtańszy 50% taniej”).

Zapas powinien być równie ścisły: kit jest dostępny tylko, jeśli każdy wymagany komponent jest dostępny w potrzebnej ilości. Dla raportowania przechowuj dwa widoki sprzedaży:

• Sprzedany przedmiot: SKU zestawu (dla przychodów, konwersji i merchandisingu).
• Skonsumowane komponenty: rozwinięte BundleLines (dla ruchu zapasów, COGS i list kompletacji).

W AppMaster pasuje to naturalnie: tabela Bundle plus wiersze BundleLine, z procesami biznesowymi, które rozwijają komponenty przy checkout i zapisują zarówno sprzedaż zestawu, jak i zużycie komponentów w jednej transakcji.

Wzorce UI do wyboru opcji i wariantów

Dobre UI opcji utrzymuje ludzi w ruchu. Złe UI powoduje domysły, błędy i odejścia. Klucz to poprowadzić kupującego do prawdziwego, możliwego do kupienia wariantu wcześnie, jasno pokazując, co zmienia jego wybór.

Dla klienta: najpierw opcje, potem warianty

Sprawdzony wzorzec to pokazać opcje (Rozmiar, Kolor, Materiał), a potem obliczać i pokazywać tylko wybory, które nadal mają sens.

Zamiast pozwalać klientom wybierać dowolną kombinację i dopiero wtedy odrzucać przy dodawaniu do koszyka, wyłączaj niemożliwe kombinacje zaraz po dokonaniu wyboru. Na przykład, gdy ktoś wybierze Kolor = Czarny, rozmiary, które nie istnieją w Czarnym, powinny stać się nieaktywne (nie usuwane), żeby klient rozumiał, co jest niedostępne.

Wraz ze zmianą wyboru aktualizuj to, co najważniejsze: cenę (w tym cenę promocyjną i wszelkie zniżki na zestawy), główne zdjęcia (dopasowane do wybranego koloru lub stylu), status zapasu (dokładny stan wariantu, nie ogólny stan produktu), szacowany termin dostawy (jeśli różni się per wariant) i opcjonalnie SKU lub „kod przedmiotu” do wsparcia.

Utrzymuj interfejs stonowany. Pokaż kilka grup opcji naraz, unikaj ogromnych rozwijanych list tam, gdzie działają próbki kolorów czy przyciski, i wyraźnie oznacz bieżący wybór.

Dla administracji: edytuj warianty jak arkusz

W adminie ludzie potrzebują szybkości, nie ładnych kart. Grid wariantów działa dobrze: każdy wiersz to SKU, każda kolumna to opcja lub reguła (cena, barcode, waga, stan, aktywny/nieaktywny). Dodaj akcje masowe do typowych zadań: aktualizacje cen, zmiana dostępności, przypisywanie obrazów.

Jeśli budujesz to w AppMaster, praktyczne ustawienie to grid powiązany z tabelą Variant z filtrami (wartość opcji, status aktywny, niski stan) oraz akcją masowej aktualizacji, która waliduje reguły przed zapisaniem.

Krok po kroku: wybór wariantu i sprawdzanie dostępności zestawu

Przepływ wyboru powinien wydawać się prosty, ale pod spodem ma ścisłe reguły. Cel to zawsze wiedzieć, który dokładny SKU klient konfiguruje i czy można go teraz kupić.

Wybór wariantu (pojedynczy produkt)

Wczytaj więcej niż nazwę produktu i zdjęcia. Potrzebujesz pełnego zbioru wartości opcji (Rozmiar, Kolor) i listy prawidłowych kombinacji wariantów, które istnieją jako SKU.

Sprawdzony przepływ:

1. Pobierz produkt, jego opcje i wszystkie istniejące warianty (lub skompaktowaną mapę prawidłowych kombinacji).
2. Przechowuj bieżące wybory kupującego (np. Rozmiar=M, Kolor=Czarny) i aktualizuj je przy każdym kliknięciu.
3. Po każdej zmianie znajdź pasujący wariant przez porównanie wybranych wartości opcji z listą wariantów.
4. Jeśli jest dopasowanie i wariant jest kupowalny (aktywny, cena ustawiona, niezablokowany), włącz Dodaj do koszyka.
5. Jeśli brak dopasowania, trzymaj Dodaj do koszyka wyłączone i skieruj klienta do prawidłowego wyboru.

Mały detal UI, który zapobiega frustracji: wyłączaj niemożliwe wartości opcji zaraz po dokonaniu wcześniejszych wyborów. Jeśli Rozmiar=M istnieje tylko w Czarnym, pokaż inne kolory jako niedostępne po wyborze M.

Dostępność zestawu (kit z komponentów)

Dla zestawów „na stanie” nie jest jedną liczbą. Zależy od komponentów. Zwykła reguła to:

bundle_available = minimum over components of floor(component_stock / component_qty_per_bundle)

Przykład: „Starter Kit” potrzebuje 1 butelki i 2 filtrów. Jeśli masz 10 butelek i 9 filtrów, dostępność kitu to min(floor(10/1)=10, floor(9/2)=4) = 4 kity.

Komunikaty o błędach powinny być konkretne. Wolisz „Tylko 4 kity dostępne (to filtry ograniczają ten zestaw)” niż „Brak w magazynie.” W AppMaster takie sprawdzenie łatwo wyrazić w procesie biznesowym: oblicz dopasowany wariant najpierw, potem limity zestawu, a następnie zwróć jasny status dla UI.

Częste błędy i pułapki do unikania

Katalogi pękają, gdy modelujesz „wszystko, co mogłoby istnieć” zamiast „to, co faktycznie będziesz sprzedawać”. Najszybszy sposób, by się uwikłać, to wygenerować wszystkie możliwe kombinacje opcji z góry, a potem próbować utrzymać porządek w miarę rozrostu katalogu.

Tworzenie wariantów, które nigdy nie będą magazynowane, to klasyczna pułapka. Jeśli masz 4 kolory x 6 rozmiarów x 3 materiały, to 72 warianty. Jeśli sprzedasz tylko 10, pozostałe 62 rekordy tworzą bałagan, zapraszają do błędów i spowalniają raportowanie.

Ceny to ciche źródło błędów. Problemy zaczynają się, gdy ta sama cena istnieje w wielu miejscach (produkt, wariant, tabela cen, tabela promocji) bez jednego źródła prawdy. Prosta zasada: przechowuj bazową cenę raz, a nadpisania tylko tam, gdzie naprawdę potrzebne (np. jeden wariant ma inną cenę).

Zestawy i kity zawodzą w zapasach, gdy zmniejszasz zarówno rekord bundle, jak i jego komponenty. Jeśli sprzedasz „Starter Kit” zawierający 1 butelkę i 2 filtry, odejmowanie 1 kit i równoczesne odejmowanie 1 butelki i 2 filtrów sprawi, że zapas spadnie za szybko. Trzymaj bundle jako sprzedawalny przedmiot, ale obliczaj dostępność i dekrementacje z komponentów.

Narzędzia administracyjne mogą wyrządzić szkody, jeśli pozwalają na nieprawidłowe dane. Dodaj zabezpieczenia wcześnie:

• Blokuj duplikaty SKU, nawet wśród zarchiwizowanych pozycji.
• Wymagaj, by każdy wariant miał wszystkie wartości opcji (bez „brak rozmiaru”).
• Zapobiegaj dwóm wariantom dzielącym tę samą kombinację opcji.
• Waliduj komponenty zestawu (brak zerowych ilości, brak brakujących SKU).

Wreszcie, planuj zmiany. Dodanie nowej opcji później (np. „Szerokość” dla butów) to migracja, nie checkbox. Zdecyduj, co stanie się z istniejącymi wariantami, jak ustawia się domyśły i jak stare zamówienia zachowają oryginalne SKU i snapshot opcji.

Szybkie kontrole przed wdrożeniem

Zanim wystartujesz, przejrzyj rzeczy, które psują się w praktyce: znajdowanie SKU, aktualizowanie stanu i blokowanie niemożliwych zakupów.

Upewnij się, że każde sprzedawalne SKU jest łatwe do znalezienia. Wyszukiwanie powinno je odnaleźć po nazwie, kodzie SKU, barcode/GTIN i kluczowych atrybutach (np. rozmiar lub kolor). Jeśli używasz skanowania w magazynie, przetestuj kilka skanów fizycznych i potwierdź, że trafiają na dokładny SKU, a nie tylko na produkt nadrzędny.

Bądź surowy co do miejsc, gdzie dokonuje się zmian stanu. Wybierz jedno źródło prawdy (logika ruchu zapasów) i upewnij się, że każde zdarzenie go używa: zamówienia, anulowania, zwroty, korekty ręczne i składanie zestawów. Jeśli zapas można edytować na dwóch ekranach lub w dwóch ścieżkach, dryft jest gwarantowany.

Kontrole wartę wykonania przy starcie:

• Wybierz opcje w UI i potwierdź, że nieprawidłowe kombinacje są blokowane wcześnie (przed dodaniem do koszyka), a nie wykrywane przy checkout.
• Dla zestawów, potwierdź, że dostępność zależy od najsłabszego komponentu i właściwej ilości (2 baterie na kit powinny zmniejszyć dostępność o połowę).
• Wycofaj SKU i sprawdź, czy znika z list i wyników wyszukiwania, ale dalej pokazuje się poprawnie w starych zamówieniach, fakturach i raportach.
• Złóż testowe zamówienie, anuluj je, a potem złóż ponownie; zapas powinien wrócić i ponownie zostać zarezerwowany poprawnie.

Jeśli budujesz w AppMaster, trzymaj reguły aktualizacji stanu w jednym procesie biznesowym i wywołuj go z każdej ścieżki. Ten pojedynczy nawyk zapobiega większości błędów zapasowych.

Przykładowy scenariusz i praktyczne następne kroki

Wyobraź sobie sklep odzieżowy, który potrzebuje poważnego katalogu.

Sprzedajesz koszulkę z dwoma opcjami: Rozmiar (S, M, L) i Kolor (Czarny, Biały). Każda sprzedawalna kombinacja to osobny wariant z własnym SKU, ceną (jeśli potrzeba) i zapasem.

W schemacie trzymaj jeden rekord Product dla „Classic T-shirt”, dwa rekordy Option (Rozmiar, Kolor) i kilka rekordów Variant. Każdy Variant przechowuje swoje wybrane wartości opcji (np. Rozmiar=M, Kolor=Czarny) i SKU (np. TSH-CL-M-BLK). Zapas jest śledzony na poziomie Variant, nie Product.

W UI ogranicz wybory i zapobiegaj martwym końcom. Czysty wzorzec: pokaż wszystkie Kolory najpierw, a potem tylko Rozmiary, które istnieją dla wybranego Koloru (lub odwrotnie). Jeśli „Biały + L” nie istnieje, nie pozwól na wybór lub pokaż jako wyłączone z jasną notatką.

Dodaj teraz zestaw: „Gift Set”, który zawiera:

• 1x Classic T-shirt (dowolny wariant)
• 1x Sticker pack (prosty SKU)

Dostępność zestawu ogranicza najsłabszy komponent. Jeśli Sticker pack ma stan 5, nie możesz sprzedać więcej niż 5 zestawów, nawet jeśli koszulki są liczne. Jeśli zestaw wymaga konkretnego wariantu koszulki (np. Czarny M), wtedy dostępność wynosi min(StickerPackStock, BlackMStock).

Praktyczne następne kroki w AppMaster:

• Zbuduj tabele w Data Designer (Products, Options, OptionValues, Variants, VariantOptionValues, Inventory, Bundles, BundleComponents).
• Zaimplementuj „znajdź prawidłowe warianty” i „oblicz dostępność zestawu” w Edytorze procesów biznesowych.
• Generuj UI web i natywne mobilne z tego samego projektu, używając tych samych reguł filtrowania wariantów i dostępności wszędzie.

Jeśli chcesz szybko prototypować end-to-end, AppMaster (appmaster.io) jest zaprojektowany do budowy kompletnych aplikacji z prawdziwą logiką biznesową — dokładnie tego, od czego zależy wybór wariantów i reguły zapasów dla zestawów.