---
title: "Szablon: Specyfikacja funkcjonalna integracji lub modyfikacji (IDK-11)"
date: 2026-09-22
description: "Gotowy do użycia szablon IDK-11: Specyfikacja funkcjonalna integracji lub modyfikacji dla projektów IFS Cloud, zgodny z metodyką wdrożeniową IFS."
author: "Dariusz Mysliwiec"
categories:
  - name: "Zestaw dokumentów wdrożeniowych"
    url: "https://www.ifs-erp.com/zestaw-dokumentow-wdrozeniowych.md"
---

# Szablon: Specyfikacja funkcjonalna integracji lub modyfikacji (IDK-11)

Szablon IDK-11, wersja 1.0. Faza: Establish Solution.

 ## Jak korzystać z tego szablonu

 
- Użyj jednej specyfikacji na każdą integrację lub modyfikację w rejestrze CRIM (szablon [Rejestr CRIM (IDK-10)](https://www.ifs-erp.com/pl/dokumentacja-wdrozeniowa/10-rejestr-crim)). Konfiguracje i raporty używają zamiast tego szablonu [IDK-12](https://www.ifs-erp.com/pl/dokumentacja-wdrozeniowa/12-specyfikacja-konfiguracji-i-raportu).
- Nie zaczynaj tego dokumentu, dopóki rejestr CRIM nie pokazuje decyzji „Zatwierdzona do specyfikacji". Nie zaczynaj rozwoju, dopóki sekcje 13 i 14 nie są podpisane.
- Napisz sekcje 1-4 językiem biznesowym, żeby właściciel procesu mógł je zatwierdzić. Sekcje 5-9 mogą być techniczne.
- Sekcja 11 nie jest opcjonalna. Integracja lub modyfikacja bez zapisanego wpływu na aktualizacje zaskoczy kogoś przy pierwszym release update.
- Utrzymuj ten dokument aktualny po starcie produkcyjnym. Wsparcie otrzymuje najnowszą wersję przy przekazaniu, razem ze scenariuszami testowymi w sekcji 10.
- Zastąp każde pole `[...]`. Usuń wiersze oznaczone `Przykład:` przed zatwierdzeniem.

 | Field | Value |
| --- | --- |
| ID szablonu | IDK-11 |
| Faza | Establish Solution |
| Właściciel | Konsultant aplikacyjny, wspólnie z kierownikiem rozwiązania technicznego |
| Zatwierdzający | Właściciel procesu po stronie klienta i kierownik projektu po stronie klienta, zatwierdzenie komercyjne przez obu kierowników projektu, autoryzacja komitetu sterującego |
| Bramka kwalifikacyjna | Solution Established |
| Wersja | 1.0 |

 ## Spis treści

 
- [Kontrola dokumentu](#kontrola-dokumentu)
- [1. Potrzeba biznesowa](#1-potrzeba-biznesowa)
- [2. Kontekst procesu](#2-kontekst-procesu)
- [3. Obecne zachowanie standardowe](#3-obecne-zachowanie-standardowe)
- [4. Wymagane zachowanie](#4-wymagane-zachowanie)
- [5. Projekt funkcjonalny](#5-projekt-funkcjonalny)
- [6. Wykorzystane dane i projekcje](#6-wykorzystane-dane-i-projekcje)
- [7. Bezpieczeństwo](#7-bezpiecze-stwo)
- [8. Obsługa błędów](#8-obs-uga-b-d-w)
- [9. Wolumeny i wydajność](#9-wolumeny-i-wydajno)
- [10. Scenariusze testowe](#10-scenariusze-testowe)
- [11. Wpływ na aktualizacje](#11-wp-yw-na-aktualizacje)
- [12. Wdrożenie i przekazanie](#12-wdro-enie-i-przekazanie)
- [13. Wycena i zatwierdzenie komercyjne](#13-wycena-i-zatwierdzenie-komercyjne)
- [14. Zatwierdzenie](#14-zatwierdzenie)

 ## Kontrola dokumentu

 | Pole | Wartość |
| --- | --- |
| Projekt | [nazwa projektu] |
| ID rejestru CRIM | [ID] |
| Typ | [Integracja / Modyfikacja] |
| ID rejestru interfejsów (integracje) | [ID] |
| Obszar rozwiązania i proces | [obszar, proces, link do modelu procesów] |
| Autor | [imię i nazwisko, rola] |
| Projektant techniczny | [imię i nazwisko] |
| Status | [Szkic / W przeglądzie / Zatwierdzona / Zaktualizowana] |
| Lokalizacja przechowywania | [link] |

 | Wersja | Data | Autor | Zmiana | Zatwierdził |
| --- | --- | --- | --- | --- |
| 0.1 | [YYYY-MM-DD] | [imię i nazwisko] | Pierwszy szkic |   |
| [x.y] | [YYYY-MM-DD] | [imię i nazwisko] | [zmiana] | [imię i nazwisko] |

 ## 1. Potrzeba biznesowa

 Zapisz potrzebę, nie rozwiązanie. Podaj, kto ma tę potrzebę i co stanie się z biznesem, jeśli nie zostanie zaspokojona.

 | Pozycja | Opis |
| --- | --- |
| Potrzeba | Przykład: Kupcy muszą widzieć potwierdzenia zamówień od dostawcy w IFS Cloud bez ręcznego wprowadzania, żeby opóźnione lub zmienione daty były widoczne w dniu, w którym dostawca je zgłasza |
| Kto ma tę potrzebę | Przykład: Kupcy we wszystkich lokalizacjach, kierownik zakupów |
| Konsekwencja, jeśli nie zaspokojona | Przykład: Potwierdzone daty pozostają w e-mailu, planowanie działa na żądanych datach, opóźnione dostawy są wykrywane na doku |
| Odniesienie do Księgi reguł | [dokument, ID decyzji] |
| Korzyść oczekiwana przez sponsora | [tekst, link do pozycji business case, jeśli istnieje] |

 ## 2. Kontekst procesu

 | Pozycja | Opis |
| --- | --- |
| Proces i krok, którego dotyczy | [proces, krok w modelu procesów] |
| Role, których dotyczy | [role biznesowe] |
| Lokalizacje i spółki objęte zakresem | [lista] |
| Zależność poprzedzająca | [co musiało się wydarzyć wcześniej] |
| Efekt następczy | [co korzysta z wyniku] |
| Powiązane inne obiekty CRIM | [ID] |

 ## 3. Obecne zachowanie standardowe

 Opisz, co robi dziś standardowy IFS Cloud dla tego kroku. Zweryfikuj to w środowisku projektowym przed pisaniem. Nie opisuj z pamięci ani z poprzedniej wersji.

 | Pozycja | Opis |
| --- | --- |
| Zweryfikowana funkcjonalność standardowa | Przykład: Ręczne wprowadzanie potwierdzonej daty i ilości na pozycji zamówienia zakupu. Standardowa obsługa komunikatów przychodzących dla potwierdzeń zamówień przez IFS Connect. |
| Środowisko i wersja, w której zweryfikowano | [nazwa środowiska, release i poziom service update] |
| Pokazano | [nazwiska, data] |
| Dlaczego standard nie wystarcza | Przykład: Portal dostawcy nie potrafi wygenerować standardowego formatu komunikatu, a ręczne wprowadzanie nie skaluje się do liczby pozycji |
| Odrzucone alternatywy standardowe, z powodem | [alternatywa, powód] |

 ## 4. Wymagane zachowanie

 Ponumeruj każde wymaganie. Każde musi być testowalne i musi mapować się na co najmniej jeden scenariusz w sekcji 10.

 | ID wym. | Wymaganie | Priorytet | Źródło |
| --- | --- | --- | --- |
| Przykład: R1 | Gdy portal dostawcy zgłasza potwierdzenie, odpowiadająca pozycja zamówienia zakupu pokazuje potwierdzoną datę i ilość dostawy | Konieczne | Księga reguł PUR-D07 |
| Przykład: R2 | Potwierdzenie, które nie pasuje do żadnej otwartej pozycji, nie jest stosowane. Jest wymienione dla kupca wraz z powodem. | Konieczne | Warsztat [YYYY-MM-DD] |
| [ID] | [wymaganie] | [Konieczne / Pożądane / Możliwe] | [źródło] |

 Poza zakresem tej specyfikacji: [lista jawna].

 ## 5. Projekt funkcjonalny

 
### 5.1 Przegląd

 [Krótki opis narracyjny rozwiązania, z diagramem przepływu lub linkiem. Wskaż, gdzie działa każda część: wewnątrz IFS Cloud, w middleware, w drugim systemie.]

 
### 5.2 Kroki projektu

 | Krok | Aktor lub komponent | Działanie | Wynik |
| --- | --- | --- | --- |
| Przykład: 1 | Portal dostawcy | Publikuje potwierdzenie z numerem zamówienia, pozycją, uwolnieniem, datą i ilością | Komunikat dostępny dla warstwy integracyjnej |
| Przykład: 2 | Warstwa integracyjna | Wyszukuje pozycję zamówienia zakupu przez projekcję, sprawdza status i otwartą ilość | Pozycja znaleziona albo błąd wg sekcji 8 |
| Przykład: 3 | Warstwa integracyjna | Wywołuje standardową akcję potwierdzającą pozycję | Standardowa logika biznesowa waliduje i aktualizuje pozycję |
| [n] | [aktor] | [działanie] | [wynik] |

 
### 5.3 Zmiany widoczne dla użytkownika

 | Strona lub lobby | Zmiana | Role, które ją widzą |
| --- | --- | --- |
| [strona] | [zmiana lub „brak"] | [role] |

 
### 5.4 Zastosowane zasady projektowe

 
- Aktualizacje przechodzą przez standardowe projekcje i ich logikę biznesową. Żadnych bezpośrednich zapisów do bazy danych.
- Preferuj konfigurację i opublikowane interfejsy zamiast zmienionego kodu aplikacji. Podaj poziom dostosowania z rejestru CRIM: [Rozszerzenie interfejsowe / Modyfikacja].
- [zasada specyficzna dla projektu]

 ## 6. Wykorzystane dane i projekcje

 Potwierdź nazwy projekcji, entity set i akcji w API Explorer środowiska projektowego. Nazwy poniżej są zastępcze, dopóki nie zostaną zweryfikowane.

 | Projekcja | Entity set lub akcja | Operacja | Odczytywane lub zapisywane pola | Zweryfikowano w środowisku, data |
| --- | --- | --- | --- | --- |
| Przykład: [projekcja obsługi zamówień zakupu] | [entity set pozycji zamówienia zakupu] | Odczyt | Numer zamówienia, pozycja, uwolnienie, status, żądana data, otwarta ilość | [środowisko], [YYYY-MM-DD] |
| Przykład: [projekcja obsługi zamówień zakupu] | [akcja potwierdzenia pozycji] | Zapis | Potwierdzona data, potwierdzona ilość | [środowisko], [YYYY-MM-DD] |
| [projekcja] | [entity set / akcja] | [Odczyt / Zapis] | [pola] | [zweryfikowano] |

 Mapowanie pól:

 | Pole źródłowe | Pole docelowe | Transformacja lub reguła | Obowiązkowe |
| --- | --- | --- | --- |
| [pole] | [pole] | [reguła] | [Tak / Nie] |

 Pola niestandardowe, encje niestandardowe lub konfiguracja potrzebne dla tego projektu: [lista z ID CRIM albo „brak"].

 ## 7. Bezpieczeństwo

 | Pozycja | Opis |
| --- | --- |
| Konto integracyjne | [nazwa konta. Jedno konto na integrację, nigdy konto nazwanej osoby.] |
| Metoda uwierzytelniania | [np. OAuth client credentials przez dostawcę tożsamości IFS] |
| Permission set | [nazwa. Przyznaje wyłącznie projekcje i akcje z sekcji 6.] |
| Tylko odczyt czy zapis | [Tylko odczyt / Zapis. Dostęp do zapisu wymaga autoryzacji komitetu sterującego zapisanej w sekcji 13.] |
| Opiekun poświadczeń | [rola, która przechowuje i rotuje sekret] |
| Rotacja i odwołanie | [jak sekret jest rotowany, jak dostęp jest usuwany przy wycofaniu] |
| Przenoszone dane osobowe lub wrażliwe | [brak / opis, z odniesieniem do zatwierdzenia właściciela prywatności] |
| Ścieżka sieciowa | [źródło, cel, porty, szyfrowanie w tranzycie] |
| Logowanie | [co jest logowane, gdzie, retencja, potwierdzenie, że logi zawierają wyłącznie klucze, a nie treść biznesową, jeśli wymagane] |

 ## 8. Obsługa błędów

 | ID błędu | Sytuacja | Wykrycie | Reakcja systemu | Kto jest powiadamiany i jak | Odzyskanie |
| --- | --- | --- | --- | --- | --- |
| Przykład: E1 | Pozycja zamówienia nie znaleziona lub już zamknięta | Wyszukanie nie zwraca otwartej pozycji | Komunikat zaparkowany z powodem, nic nie zaktualizowane | Kupiec, przez [element lobby / zdarzenie e-mail] | Kupiec poprawia odniesienie w portalu, komunikat jest przetwarzany ponownie |
| Przykład: E2 | IFS Cloud niedostępny | Wywołanie zawodzi lub przekracza limit czasu | Ponowienie `[ustalić w projekcie]` razy, następnie zaparkowanie | Właściciel integracji, przez alert monitoringu | Automatyczne ponowne przetworzenie po powrocie połączenia |
| [ID] | [sytuacja] | [wykrycie] | [reakcja] | [powiadomienie] | [odzyskanie] |

 Zasady: żaden komunikat nie ginie po cichu, żaden komunikat nie jest stosowany dwukrotnie, a każdy zaparkowany komunikat ma właściciela.

 ## 9. Wolumeny i wydajność

 Uzupełnij liczbami od biznesu. Nie szacuj ich w zespole projektowym.

 | Miara | Wartość | Źródło liczby |
| --- | --- | --- |
| Transakcje dziennie, normalnie | `[ustalić w projekcie]` | [imię i nazwisko, rola] |
| Transakcje dziennie, w szczycie | `[ustalić w projekcie]` | [imię i nazwisko, rola] |
| Największy pojedynczy komunikat lub plik | `[ustalić w projekcie]` | [imię i nazwisko, rola] |
| Wymagany czas przetwarzania | `[ustalić w projekcie]` | [imię i nazwisko, rola] |
| Okno operacyjne | `[ustalić w projekcie]` | [imię i nazwisko, rola] |
| Oczekiwany wzrost | `[ustalić w projekcie]` | [imię i nazwisko, rola] |

 Test wolumenowy wymagany przed SAT: [Tak / Nie, odniesienie do planu testów].

 ## 10. Scenariusze testowe

 Pokryj najpierw przepływ typowy, potem wyjątki normalne, potem wyjątki specyficzne. Te scenariusze stają się specyfikacją testową przekazywaną do wsparcia.

 | ID testu | Pokrywa | Klasa | Warunki wstępne i dane | Kroki | Oczekiwany wynik | Wynik, tester, data |
| --- | --- | --- | --- | --- | --- | --- |
| Przykład: T1 | R1 | Typowy | Zwolnione zamówienie zakupu z jedną otwartą pozycją | Opublikowanie potwierdzenia dla pełnej ilości z datą późniejszą niż żądana | Pozycja pokazuje potwierdzoną datę i ilość. Historia zamówienia pokazuje zmianę. Brak zaparkowanego błędu. | [Zaliczony / Niezaliczony], [imię i nazwisko], [YYYY-MM-DD] |
| Przykład: T2 | R2, E1 | Wyjątek normalny | Pozycja zamówienia zakupu już zamknięta | Opublikowanie potwierdzenia dla tej pozycji | Nic nie zaktualizowane. Komunikat zaparkowany z powodem. Kupiec widzi go w [miejscu]. |   |
| [ID] | [ID wym.] | [Typowy / Wyjątek normalny / Wyjątek specyficzny] | [dane] | [kroki] | [oczekiwane] |   |

 Środowiska testowe: test jednostkowy w [środowisko], test integracyjny w [środowisko], uwzględniony w skrypcie SAT [ID]. Testy wykonywane na rzeczywistym koncie integracyjnym i permission secie, nie na koncie administratora.

 ## 11. Wpływ na aktualizacje

 | Pozycja | Opis |
| --- | --- |
| Poziom dostosowania | [Rozszerzenie interfejsowe / Modyfikacja, z rejestru CRIM] |
| Dotknięte obiekty dostarczone | [projekcje, encje, strony, moduły kodu] |
| Co musi być ponownie zweryfikowane przy każdym release update | Przykład: Nazwy i sygnatury entity set i akcji z sekcji 6, zachowanie akcji potwierdzającej, uprawnienia permission setu, scenariusze T1 i T2 |
| Co musi być sprawdzone przy każdym service update | [zazwyczaj smoke test scenariusza T1, podaj to] |
| Przebudowa lub uplift potrzebne przy release update | [Nie dla Rozszerzenia interfejsowego / Tak dla Modyfikacji, z szacowanym nakładem `[ustalić w projekcie]`] |
| Właściciel ponownej weryfikacji | [rola po stronie klienta po starcie produkcyjnym] |
| Warunek wycofania | [w jakich okolicznościach ten obiekt może zostać wycofany, np. gdy standard pokryje potrzebę] |

 ## 12. Wdrożenie i przekazanie

 | Pozycja | Opis |
| --- | --- |
| Trasa dostawy | [Build Place do środowisk Use Place dla kodu, pakiety konfiguracji dla konfiguracji, wdrożenie komponentów zewnętrznych] |
| Potrzebne kroki cutover | [pozycje do dodania do planu cutover] |
| Monitoring po starcie produkcyjnym | [co jest monitorowane, przez kogo] |
| Właściciel wsparcia | [rola] |
| Zawartość przekazania | Ta specyfikacja, scenariusze testowe z sekcji 10, wiersz rejestru interfejsów, dane opiekuna poświadczeń |

 ## 13. Wycena i zatwierdzenie komercyjne

 Rozwój nie zaczyna się przed ukończeniem tej sekcji.

 | Pozycja | Wartość |
| --- | --- |
| Wycena specyfikacji, budowy, testów, dokumentacji | `[ustalić w projekcie]` |
| Wycena cyklicznego nakładu na aktualizacje | `[ustalić w projekcie]` |
| Założenia i wyłączenia | [tekst] |
| Odniesienie do wniosku o zmianę | [ID] |
| Autoryzacja komitetu sterującego | [data spotkania, odniesienie do protokołu] |

 | Rola | Imię i nazwisko | Decyzja | Data | Podpis |
| --- | --- | --- | --- | --- |
| Kierownik projektu po stronie dostawcy | [imię i nazwisko] | [Zatwierdzono / Odrzucono] | [YYYY-MM-DD] |   |
| Kierownik projektu po stronie klienta | [imię i nazwisko] |   |   |   |
| Sponsor po stronie klienta (jeśli wymagane umową) | [imię i nazwisko] |   |   |   |

 ## 14. Zatwierdzenie

 Zatwierdzając, klient potwierdza, że sekcje 1-4 poprawnie opisują potrzebę i wymagane zachowanie, że scenariusze testowe w sekcji 10 są podstawą odbioru, oraz że wpływ na aktualizacje w sekcji 11 jest zrozumiały.

 | Rola | Imię i nazwisko | Decyzja | Data | Podpis |
| --- | --- | --- | --- | --- |
| Właściciel procesu po stronie klienta | [imię i nazwisko] | [Zatwierdzono / Zatwierdzono z uwagami / Odrzucono] | [YYYY-MM-DD] |   |
| Kierownik projektu po stronie klienta | [imię i nazwisko] |   |   |   |
| Kierownik rozwiązania technicznego (przegląd projektu technicznego) | [imię i nazwisko] |   |   |   |
| Architekt rozwiązania (przegląd spójności) | [imię i nazwisko] |   |   |   |

 Uwagi i warunki: [tekst]

 Niezależny szablon zgodny z metodyką wdrożeniową IFS. Nie jest oficjalnym dokumentem IFS. IFS jest zastrzeżonym znakiem towarowym IFS AB.