01/2026 Draft
Opracowanie AI na podstawie:
Rejestrowanie operacji 1
Rejestrowanie operacji 2. Na bieżąco
Rejestrowanie operacji. Parametry
Dodatkowe metody rejestrowania operacji produkcyjnych
Metody rejestracji danych oraz ew. dodatkowe parametry które mogą rozwinąć Trawers
i przygotować system dla jeszcze innych firm produkcyjnych
(część to nowe tryby, część to parametry, które mogą sterować istniejącymi ekranami KR/terminalami/SOA).
1) Dodatkowe metody rejestracji danych (ponad 1/2/3 + SOA + Backflush)1. Rejestracja kioskowa (wspólny terminal przy wejściu/gnieździe)Cel: proste odbicie pracy bez przypisania do konkretnego stanowiska terminalowego.
Jak: pracownik loguje PIN/kartą wybiera operację z listy zadań START/STOP.
Warianty:
* kiosk per gniazdo/linia,
* kiosk czas pracy + późniejsze rozpisanie na zlecenia (dla firm z wysoką zmiennością).
2. Aplikacja mobilna (Android/iOS) z trybem offlineCel: firmy bez infrastruktury PC/terminali, praca w ruchu (montaż, magazyn międzyoperacyjny, serwis wewn.).
Funkcje kluczowe:
* skan QR/kodów, START/STOP, ilość, braki,
* cache offline + synchronizacja,
* geolokalizacja opcjonalnie (serwis/teren).
3. Rejestracja przez kolejkę zadań (dispatch list) zamiast wybierania zleceniaCel: linie i gniazda, gdzie operator nie powinien wybierać zlecenia/operacji z kartoteki.
Jak: system generuje listę zadań na stanowisko/gniazdo operator tylko: START/STOP + ilość + wyjątki.
Korzyści: mniej błędów, szybsza praca, łatwiejsze wdrożenie.
4. Rejestracja ruchu WIP (skan półwyrobu między operacjami)Cel: firmy, które chcą śledzić przepływ partii/półwyrobów, kolejki, czasy oczekiwania.
Jak: etykieta partii/półwyrobu (TransferLabel) staje się tokenem skan na wejściu/wyjściu operacji:
* wejście na operację (queuein process),
* wyjście z operacji (in processdone / do następnej).
5. RFID/NFC/karty pracownika + stanowisko (touch-in/touch-out)Cel: szybciej niż skanowanie; dobre w brudnym środowisku lub gdy operator ma rękawice.
Tryb: przyłożenie karty do czytnika przy stanowisku = START/STOP.
6. Integracja maszynowa sygnałowa (IoT) - zdarzenia z maszynyCel: firmy, gdzie maszynę da się odczytać (cykle, start/stop, alarmy).
Jak: SOA/MQTT/OPC-UA system dostaje eventy:
* start cyklu, stop cyklu,
* licznik sztuk,
* przestój/awaria (downtime).
Operator dopisuje tylko kontekst (zlecenie, przyczyna, braki jakościowe).
7. Rejestracja pakietowa po zmianie z kontrolą wyjątków (exception-based)Cel: firmy, które nie chcą rejestrować wszystkiego, tylko odchylenia.
Jak: norma + plan daje domyślne wykonanie, operator zgłasza tylko:
* braki,
* przestoje,
* rework,
* zmianę zlecenia/operacji.
To jest pośrednie, ale znacznie mniej pracochłonne.
8. Rejestracja przez Kanban (skan kart/pudeł)Cel: Lean / przepływ pojemnikowy; operacja = zeskanowanie karty pojemnika.
Dane: ilość z pojemnika, czas w uproszczeniu (opcjonalnie), automatyczne przesunięcie WIP.
9. Rejestracja rework/napraw jako osobny strumieńCel: branże z dużą naprawialnością (metal, meble premium, automotive tier).
Jak: rework jako:
* osobna operacja w routingu,
* albo osobny typ [KR] z powiązaniem do operacji bazowej + przyczyna + koszt.
2) Parametry/ustawienia, które realnie zwiększają 'dopasowalność'
Poniżej parametry, które można dodać (albo rozwinąć istniejące), żeby pokryć kolejne typy firm
bez zmiany logiki bazowej.
A. Parametry pracy i czasu
1. Obsługa przerw (planowane i nieplanowane)
* czy przerwy automatycznie odejmować od czasu operacji,
* przerwy zakładowe vs indywidualne.
2. Rozdzielenie czasu na składowe
* Setup / Run już jest, ale warto dodać opcjonalnie:
* przezbrojenie,
* kontrola jakości,
* transport wewnętrzny,
* czekanie na materiał/narzędzie (queue time).
3. Wiele osób / współpraca
* parametr: czy operacja może mieć N pracowników (i jak liczyć czas/koszt):
* czas wspólny * N,
* czas rozdzielany,
* czas tylko maszynowy + obsługa.
4. Wiele maszyn/gniazd
* rejestr na maszynę vs na stanowisko vs na gniazdo,
* reguła: czy stanowisko identyfikuje operację (jak w Twoich materiałach) - ale z wariantami.
5. Tryb: czas tylko normatywny / tylko rzeczywisty / mieszany
* już jest, ale praktycznie przydaje się dodatkowo:
* czas rzeczywisty tylko dla wyjątków,
* czas normatywny + korekta odchyleniem.
B. Parametry ilości, partii i jakości
6. Partie / numery seryjne / traceability
* czy w [KR] wymagane jest wskazanie partii wejściowej i/lub wyjściowej,
* czy generować partie automatycznie.
7. Braki: rozbudowane kategorie
* braki natychmiastowe vs ujawnione później,
* złom vs naprawa vs przeklasyfikowanie,
* przyczyna + odpowiedzialność + miejsce powstania (operacja/stanowisko).
8. Kontrola jakości jako checkpoint
* parametr: po operacji X wymagaj kontroli jakości:
* blokada przejścia do następnej operacji bez odbioru,
* rejestr pomiarów (min/max, cechy krytyczne) jako załącznik do [KR].
C. Parametry przepływu i sterowania procesem
9. Rejestracja wejście/wyjście zamiast tylko wykonania
* pozwala mierzyć kolejki i WIP.
* parametr: czy wymagać skanu wejścia przed START.
10. Reguły sekwencji
* dzisiaj jest nie więcej w następnej - warto dodać warianty:
* dopuszczaj wyprzedzenie z limitem (% lub szt.),
* dopuszczaj równoległe operacje,
* dopuszczaj powroty/rework loop.
11. Zamykanie operacji
* nie tylko po ilości zleconej, ale też:
* po statusie QA OK,
* po zatwierdzeniu brygadzisty,
* po spełnieniu warunków materiałowych.
12. Automatyzacje materiałowe
* Auto-wydanie materiałów już jest; warto parametryzować:
* wydać przy START czy przy STOP,
* wydać 100% normy czy proporcjonalnie do ilości,
* obsługa substytutów / zamienników.
D. Parametry uprawnień i antybłędowe
13. Tryb operator prosty
* ogranicz pola, słowniki, wybory; tylko skan + ilość.
* blokada ręcznej edycji czasu.
14. Walidacje na terminalu
* alerty: zbyt długi czas, zbyt duża ilość, brak STOP, brak materiału,
* progi per operacja (np. maks. czas rzeczywisty bez zgody).
15. Workflow korekt
* kto może poprawiać: operator, brygadzista, planista,
* ślad rewizji (kto/co/kiedy dlaczego) mocno przydatne w automotive/ISO.
E. Parametry rozliczeń i kosztów
16. Koszt pracy: stawka z pracownika vs z operacji vs z gniazda
* wybór źródła stawki,
* narzuty zależne od zmiany/tygodnia.
17. Rozliczanie kosztu maszynowego
* dla firm, gdzie koszt to nie tylko robocizna:
* stawka maszynogodziny,
* energia, narzędzia (opcjonalnie).
3) Profile firm - gotowe zestawy (żeby łatwiej wdrażać)
To jest bardzo praktyczne: zamiast setek ustawień, dać 5-7 profili,
które prekonfigurują parametry rejestracji.
1. Job shop / jednostkowa
Rzeczywisty czas, dużo wyjątków, rework, mocne korekty + ślad zmian.
2. Gniazda/linie (powtarzalna)
Dispatch list, kiosk/terminal, minimalne pola, normatyw + wyjątki, TransferLabel/WIP.
3. Lean / Kanban
Skan pojemnika, backflush, rejestracja zdarzeń tylko przy odchyleniach, mocne wsparcie WIP.
4. Proces / partie
Partie, traceability, checkpoints jakości, automaty maszynowe.
5. Podwykonawstwo / usługi
Czas rzeczywisty, zlecenie-usługa, prace przygotowawcze, rozliczenia kosztowe i dekretacje.
4) Co bym uznał za 'największy zwrot z inwestycji' (TOP 6)
Jeśli miałbym wybrać rzeczy, które najczęściej otwierają nowe firmy bez rewolucji:
1. Dispatch list / kolejka zadań (mniej błędów niż wybieranie zleceń)
2. Rejestracja wejście/wyjście + WIP (kolejki, lead time, przepływ)
3. Offline mobile (tam, gdzie nie ma infrastruktury)
4. Przerwy + downtime reasons (OEE i prawdziwe czasy)
5. Rework jako strumień (naprawy, pętle, koszty jakości)
6. Workflow korekt + ślad rewizji (audytowalność, branże wymagające)
***********************************************************************************************************************
Poniżej:
1. Lista wymagań rozwojowych (w formacie funkcja / parametry / ekrany / wpływ na KR / raporty / ryzyka) jako backlog do planowania.
2. Propozycja nowych pól w dokumencie [KR] oraz odpowiadających im przełączników/parametrów (głównie w `ZP_PRS10`, plus kilka logicznych podparametrów w ZP/operatorze/KIM).
Żeby zachować zgodność z tym, co już jest, trzymam się zasady: jedno źródło prawdy to [KR], a reszta to tryby zbierania danych i walidacje.
1) Proponowane wymagania rozwojowe (backlog)EPIC A. Dispatch list (kolejka zadań) zamiast wyboru zlecenia/operacjiProblem biznesowy: w firmach liniowych i gniazdowych operatorzy nie powinni szukać zlecenia, tylko realizować przydzielone zadania.
* Funkcja: Rejestracja z listy zadań dla stanowiska/gniazda (dispatch).
* Parametry:
* tryb rejestracji: `wybór zlecenia` vs `lista zadań`,
* źródło listy: planista / harmonogram / kolejka WIP,
* limit widocznych zadań (np. top 10), priorytety.
* Ekrany: nowy ekran Zadania stanowiska dostępny w (2) i (3) + menu podręczne.
* Wpływ na [KR]: dopisać identyfikator zadania (TaskID) + źródło przydziału.
* Raporty: wykonanie vs plan wg TaskID, opóźnienia, przepływ przez kolejkę.
* Ryzyka: konieczność spójnego modelu zadania (czy to pozycja operacji, czy osobny byt).
EPIC B. WIP Wejście/Wyjście (queue in process done)Problem: część firm chce mierzyć lead time, czasy oczekiwania, kolejki międzyoperacyjne, a nie tylko czas pracy.
* Funkcja: rejestracja zdarzeń:
* IN (wejście partii na operację),
* START (opcjonalnie rozpoczęcie),
* STOP,
* OUT (wyjście / przekazanie).
* Parametry:
* czy wymagać IN przed START,
* czy OUT jest automatyczne przy STOP,
* czy dopuszczać częściowe OUT (częściowa partia).
* Ekrany: terminal/mobilka: przyciski IN/OUT + lista WIP na stanowisku.
* Wpływ na [KR]: nowe pola na typ zdarzenia lub osobny subtyp pozycji (EventType).
* Raporty: queue time, wait time, WIP per stanowisko, bottleneck.
* Ryzyka: dane stają się procesowe, trzeba pilnować konsekwencji zdarzeń (stan maszyny/partii).
EPIC C. Offline mobile (Android) + synchronizacjaProblem: firmy bez infrastruktury na hali albo praca w ruchu (montaż, UR, serwis wewnętrzny).
* Funkcja: rejestracja (2)/(3) na urządzeniach mobilnych offline.
* Parametry:
* polityka konfliktów (kto wygrywa przy edycji),
* bufor danych (max dni),
* dozwolone operacje offline (START/STOP/ilość/braki).
* Ekrany: uproszczony UI (operator prosty) + ekran synchronizacji.
* Wpływ na [KR]: dodać Source = MOBILE_OFFLINE, DeviceID, SyncID, Timestamp urządzenia.
* Raporty: brak nowych, ale potrzebny raport błędy synchronizacji.
* Ryzyka: rozwiązywanie konfliktów, czas urządzenia, duplikaty, bezpieczeństwo.
EPIC D. Downtime / przestoje + OEE-lite
*Problem:** wiele firm chce rejestrować przestoje i przyczyny (OEE, TPM), ale nie zawsze ma MES.
* Funkcja: rejestrowanie przestoju jako:
* osobny typ zdarzenia na [KR] (Downtime),
* lub osobny dokument, ale spięty ze zleceniem/stanowiskiem.
* Parametry:
* wymóg podania przyczyny przestoju,
* katalog przyczyn (planowane/nieplanowane),
* czy przestój automatycznie wstrzymuje operację w toku.
* Ekrany: terminal: START przestój / STOP przestój + wybór przyczyny.
* Wpływ na [KR]: EventType=DT + ReasonCode + MachineID/WorkCenter.
* Raporty: przestoje wg przyczyn, OEE-lite (Availability), trendy.
* Ryzyka: definicja co jest przestojem i jak łączyć z operacją produkcyjną.
EPIC E. Rework / naprawy jako strumień jakościowyProblem: firmy z naprawami chcą znać koszt rework, powiązanie do operacji pierwotnej, przyczyny.
* Funkcja: rework jako:
* typ pracy w [KR] (np. Run/Setup/Rework),
* z linkiem do operacji źródłowej albo do partii/sztuki.
* Parametry:
* czy rework zwiększa ilość wykonaną (zwykle nie),
* czy rework zużywa materiały (opcjonalnie).
* Ekrany: terminal: wybór rework + wskazanie przyczyny + referencja.
* Wpływ na [KR]: ReworkFlag, ReworkReason, RefKR/RefOperation.
* Raporty: koszt jakości (COPQ), rework wg przyczyn/operacji.
* Ryzyka: spójność ilości (dobre/braki/rework), aby nie pompować wykonania.
EPIC F. Traceability: partie / numery seryjne / genealogiaProblem: branże wymagające śledzenia partii i genealogi (food, pharma, automotive, lotnictwo).
* Funkcja: obowiązkowe wskazywanie:
* partii wejściowej i wyjściowej,
* lub numeru seryjnego / zakresu seryjnego.
* Parametry:
* tryb: partia / serial / brak,
* kiedy wymagane: na IN/OUT/STOP,
* generowanie partii automatycznie.
* Ekrany: terminal/mobilka: skan partii/seriala + walidacje.
* Wpływ na [KR]: LotIn, LotOut, SerialFrom/To, TraceID.
* Raporty: genealogia produktu, ścieżka partii, zgodność.
* Ryzyka: duża liczba rekordów przy serializacji; wydajność raportów.
EPIC G. Kontrola jakości jako checkpoint (blokady przejścia)Problem: firmy chcą odbiory po wybranych operacjach i blokady przekazania.
* Funkcja: QA checkpoint po operacji:
* status: Pending/OK/NOK,
* (opcjonalnie) rejestr pomiarów.
* Parametry:
* lista operacji QA required,
* czy brak QA blokuje OUT/następną operację/przyjęcie PR.
* Ekrany: prosty ekran QA + szybkie zatwierdzanie.
* Wpływ na [KR]: QAStatus, QAUser, QATime, opcjonalnie link do danych pomiarowych.
* Raporty: odsetek NOK, czasy oczekiwania na QA.
* Ryzyka: zmiana procesów organizacyjnych; kto robi QA i kiedy.
EPIC H. Multi-person / team mode (zespoły, brygady, współpraca)Problem: operacje wykonywane przez 2-6 osób lub brygady (montaż, pakowanie).
* Funkcja: przypięcie wielu pracowników do jednej operacji + reguła rozliczania czasu.
* Parametry:
* sposób liczenia: `czas wspólny * N` vs `podział` vs `czas per osoba`,
* czy dopuszczać dołączanie w trakcie.
* Ekrany: terminal: dodaj osobę do operacji, zdejmij osobę.
* Wpływ na [KR]: PeopleCount + lista pracowników (relacja), TeamID.
* Raporty: efektywność brygad, obciążenie pracowników.
* Ryzyka: model danych (1 pozycja vs wiele pozycji), spójność kosztów.
EPIC I. Antybłędowe walidacje + workflow korekt + ślad rewizjiProblem: firmy wymagające audytu (ISO/IATF) i ograniczania pomyłek na terminalu.
* Funkcja: progi i blokady:
* max czas operacji bez akceptacji,
* max ilość,
* ostrzeżenie o długich operacjach w toku,
* obowiązkowy powód korekty.
* Parametry: progi globalne i per operacja/gniazdo, role zatwierdzania.
* Ekrany: okno zatwierdź wyjątek + historia zmian.
* Wpływ na [KR]: Audit fields: ChangedBy/ChangedAt/ChangeReason + wersjonowanie.
* Raporty: raport korekt i wyjątków.
* Ryzyka: opór użytkowników, jeśli walidacje będą zbyt restrykcyjne.
EPIC J. Integracja maszynowa (eventy z IoT/MES) rozszerzenie SOAProblem: część firm chce automatycznie pobierać cykle/sztuki/alarmy z maszyn.
* Funkcja: SOA przyjmuje zdarzenia typu:
* MachineStart/MachineStop,
* Counter (ilość),
* Alarm/Downtime.
* Parametry: mapowanie MachineIDWorkCenterOperacja, tolerancje, agregacja.
* Ekrany: panel podglądu zdarzenia z maszyn + korekty mapowania.
* Wpływ na [KR]: Source=MACHINE, MachineEventID, opcjonalnie sygnatura danych.
* Raporty: porównanie manual vs machine, odchylenia.
* Ryzyka: mapowanie kontekstu (jaka operacja?), dane brudne, duplikaty.
2) Propozycja rozbudowy dokumentu [KR] i parametrów sterujących
Poniżej podaję w praktycznym układzie: nowe pola [KR] -> przełącznik/parametr -> po co.
2.1 Pola ogólne (źródło, urządzenie, zadanie)Nowe pola w [KR] (nagłówek lub pozycja):
* `KR_Source` (MANUAL_OFFICE / SHOP_ONLINE / TERMINAL / MOBILE / MACHINE / SOA)
* `KR_DeviceID` (terminal/mobilka/komputer)
* `KR_SyncID` (dla offline)
* `KR_TaskID` (identyfikator zadania z kolejki)
* `KR_DispatchSource` (PLAN / WIP / RĘCZNIE)
Parametry (ZP_PRS10 / operator):
* `Tryb wyboru operacji`: Lista zadań vs wybór zlecenia
* `Wymagaj identyfikacji urządzenia`: T/N
Efekt: ułatwia audyt, analizę jakości danych i wdrożenia dispatch.
2.2 Zdarzenia procesu (IN/START/STOP/OUT) i WIPNowe pola:
* `KR_EventType` (IN, START, STOP, OUT, ADJUST)
* `KR_WIPContainerID` (ID etykiety/pojemnika/TransferLabel)
* `KR_StepStateBefore/After` (opcjonalnie)
Parametry (ZP_PRS10):
* `Włącz WIP IN/OUT`: T/N
* `Wymagaj IN przed START`: T/N
* `OUT automatyczne przy STOP`: T/N
* `Dopuszczaj częściowe OUT`: T/N
Efekt: mierzenie kolejek, lead time, przepływ partii.
2.3 Przestoje (downtime) i przyczynyNowe pola:
* `KR_DowntimeFlag`
* `KR_DowntimeReason`
* `KR_DowntimeCategory` (planowany/nieplanowany)
* `KR_MachineID` / `KR_WorkCenterID` (jeśli nie ma jeszcze spójnego)
Parametry:
* `Rejestruj przestoje`: T/N
* `Wymagaj przyczyny przestoju`: T/N
* `Przestój wstrzymuje operację w toku`: T/N
Efekt: OEE-lite i realna analiza strat.
2.4 Rework / naprawy i powiązaniaNowe pola:
* `KR_WorkType` rozszerzone: RUN / SETUP / REWORK / QA / TRANSPORT (lub słownik)
* `KR_ReworkReason`
* `KR_RefKRDoc` / `KR_RefOperation` (link do źródła)
Parametry:
* `Włącz Rework`: T/N
* `Rework wpływa na ilość dobrą`: T/N (zwykle N)
* `Wymagaj referencji do operacji źródłowej`: T/N
Efekt: koszt jakości, pętle technologiczne, naprawialność.
2.5 Partie / numery seryjne / traceabilityNowe pola:
* `KR_LotIn`, `KR_LotOut`
* `KR_SerialFrom`, `KR_SerialTo` (lub lista seriali)
* `KR_TraceID` (ID genealogii / partii roboczej)
Parametry:
* `Tryb traceability`: brak / partia / serial
* `Wymagaj Lot/Serial na`: IN / START / STOP / OUT
* `Generuj LotOut automatycznie`: T/N
Efekt: wejście w branże regulowane bez osobnego MES.
2.6 Quality checkpoint (QA)Nowe pola:
* `KR_QARequired` (wynikające z technologii)
* `KR_QAStatus` (PENDING/OK/NOK)
* `KR_QAUser`, `KR_QATime`
* `KR_QARef` (link do protokołu pomiarów, jeśli pomiary osobno)
Parametry:
* `Włącz QA checkpoint`: T/N
* `QA blokuje przejście`: T/N (co blokuje: OUT / następna operacja / PR)
* `Wymagaj QA dla operacji oznaczonych`: T/N
Efekt: kontrola przepływu jakości, mniej przepuszczonych wad.
2.7 Multi-person / brygadyNowe pola:
* `KR_PeopleCount`
* `KR_TeamID`
* Relacja: `KR_PeopleList` (tabela powiązana KRPracownik z czasem dołączenia/odłączenia)
Parametry:
* `Tryb brygady`: wspólny czas *N / dzielenie / per osoba
* `Dopuszczaj dołączanie w trakcie`: T/N
Efekt: naturalne wdrożenia w montażu zespołowym.
2.8 Antybłędowe walidacje + audit trailNowe pola:
* `KR_AnomalyFlag`
* `KR_ApprovalRequired`, `KR_ApprovedBy`, `KR_ApprovedAt`
* `KR_ChangeReason`, `KR_ChangedBy`, `KR_ChangedAt`, `KR_RevisionNo`
Parametry:
* `Max czas operacji bez zgody` (min/godz)
* `Max ilość na zapis` (szt / % normy)
* `Wymagaj powodu korekty`: T/N
* `Workflow korekt`: operator/brygadzista/planista
Efekt: firmy audytowe + mniej błędów terminalowych.
2.9 Rozszerzenie kosztów (opcjonalne, ale otwiera kolejne firmy)Nowe pola:
* `KR_CostingMode` (stawka z pracownika / z operacji / z gniazda)
* `KR_MachineRate` (jeśli rozliczacie maszynogodzinę)
* `KR_PayComponentID` (już macie składnik płacowy można go rozszerzyć o reguły)
Parametry:
* `Źródło stawki`: pracownik/operacja/gniazdo
* `Rozliczaj koszt maszynowy`: T/N
Efekt: dokładniejszy koszt rzeczywisty w firmach maszynowych.
3) Jak to spiąć z istniejącym `ZP_PRS10`
(żeby nie zrobić 'parametrozy')
Proponuję dopisać w `ZP_PRS10` sekcje/grupy zamiast pojedynczych pól rozsianych:
1. Tryb rejestracji: klasyczny / dispatch / WIP IN-OUT
2. Czas: normatywny/rzeczywisty/mieszany + przerwy
3. Jakość: braki / rework / QA checkpoint
4. Traceability: partie / seriale
5. Zasoby: multi-person / maszyna/gniazdo / narzędzia
6. Walidacje i workflow: progi, zatwierdzanie, audit
7. Integracje: SOA/Machine events + mapowania
To pozwoli wdrażać profile firm (job-shop, linia, lean, proces, regulowane).
4) Minimalny 'pakiet rozwojowy' vs 'pakiet dla firm wymagających'
Jeżeli chcesz nadać temu priorytety:
Pakiet minimalny (największy zasięg wdrożeń)
* Dispatch list (EPIC A)
* WIP IN/OUT (EPIC B)
* Downtime + przyczyny (EPIC D)
* Audit trail + walidacje (EPIC I)
Pakiet branże wymagające
* Traceability (EPIC F)
* QA checkpoint (EPIC G)
* Rework (EPIC E)
* Machine events / rozszerzone SOA (EPIC J)
W następnym kroku mogę:
* rozpisać to na konkretne user stories (np. 3060 sztuk) z kryteriami akceptacji,
* albo zrobić mapę danych: które pola są w [KR] (nagłówek/pozycja/tabela powiązana)
+ indeksy pod raporty + konsekwencje dla wydajności.
***********************************************************************************************************
Parametry rejestracjiZlecenia produkcyjneStanowiska roboczeDC Data CollectionSF Shop Floor Control Słowa kluczowe#Produkcja-Dokumenty#Produkcja-Kalkulacje#Produkcja-Zlecenia#Produkcja-Technologia