Opis struktury dokumentu

Ogólny opis struktury

Wszystkie dokumenty systemu SAFE X3 są zapisane w bazie danych.

• Tabela ADOCUMENT dla struktury akapitów,
• tabela ADOCCLB dla tekstów,
• tabela ADOCBLB dla pozostałych plików,
• tabela ADOCFNC dla połączeń.

Generowanie dokumentu

• Pierwsza funkcja generowania umożliwia tworzenie, w przypadku każdego podmiotu, którym ma być udokumentowany, struktury dokumentów, składających się z wielu zestandaryzowanych akapitów.
• Druga funkcja generowania używa te dane i wprowadzony tekst do generowania ostatecznego dokumentu w formacie HTML. Każdy rekord odnosi się do akapitu, gdy dane dokumenty są uporządkowane na liście akapitów.

Struktura kodu języka

• i typu dokumentu
• akapitu:
• Dokumentacja funkcjonalna (zawierająca wyjaśnienia an temat sposobu używania danej funkcji) jest identyfikowana przez typ AFC.
• Dokumenty opisujące ustawienia (konfiguracje, kody czynności, dzienniki, itd.) są identyfikowane za pomocą kodu obiektu, który je obsługuje (ADP, ACV, GAU w poprzednich przykładach).
• Pozostałe dokumenty (załączniki, np. takie ja niniejszy dokument) są identyfikowane za pomocą kod DI. Menu i podmenu są definiowane za pomocą kodu APM.
• kod używany do identyfikacji dokumentu, który powiązany jest z tym, co jest w nim udokumentowane: np. kod funkcji, kod konfiguracji, kod czynności, kod dziennika, itp.
• Poziom i podpoziom, które opisują nakładanie się akapitów.
  Tytuł pierwszego akapitu każdego poziomu jest ponownie użyty w spisie treści, umożliwiając bezpośredni dostęp do poszczególnych sekcji dokumentu. Jeżeli w danym podpoziomie występuje więcej niż jeden akapit, tworzony jest pomocniczy spis treści dla odpowiednich poziomów.
• Kod akapitu określa sposób, w jaki tekst HTML ma być generowany.
• Kod ekranu określa, czy należy w odpowiednim akapicie wstawiać ikonę, która umożliwia rozwijanie pomocy dla pola, powiązanej z danym ekranem.
• Kod czynności dziedziczony ze słownika podczas ponownego generowania umożliwia rozróżnienie szczególnie rekordów standardowych od rekordów specjalnych, ale także tworzenie dokumentów dostosowanych do określonych folderów poprzez generowanie tylko akapitów i dokumentów odnoszących się do kodów czynności, które aktywne są dla danego folderu.

Należy zauważyć, że akapit z kodem czynności FAL (zawsze „FALSE”) nigdy nie jest brany pod uwagę podczas procesu generowania, jeżeli pożądane jest kompletne generowanie. Umożliwia to wyłączenie generowanych akapitów, które nie powinny być wyszukiwane w dokumencie.

Gdy proces generowania ze słownika dobiega końca, możliwe jest uzupełnianie utworzonych rekordów w tabeli ADOCUMENT i dodawanie innych (w szczególności innego typu). Kasowanie rekordu w tabeli ADOCUMENT oznacza usuwanie danego akapitu w ostatecznym dokumencie. Jednakże, jeżeli ze słownika jest generowany akapit, uruchamianie ponownego generowania ze słownika powoduje ponowne utworzenie danego akapitu.

Koniecznie należy zauważyć, że akapity są wyszczególniane w takiej kolejności, w jakiej muszą być wyświetlane (np. na pierwszym miejscu znajdzie się akapit TIT). Zalecane jest zachowanie odpowiedniej kolejności, poza szczególnymi przypadkami, a także w przypadku typowych akapitów.

Istniejące akapity są powiązane z wieloma kategoriami.

Akapity generowane automatycznie

Niektóre akapity pozyskują automatycznie elementy ze słownika lub tabeli powiązania, wraz z określonym układem.
Są one nazywane wygenerowanymi akapitami. W tym wypadku, gdy generowana jest tabela ADOCUMENT, tworzony jest akapit bez tekstu, jeśli elementy słownika lub tabeli to umożliwiają. Jeżeli nie jest wymagane wprowadzenie tekstu, elementy słownika są wyświetlane automatycznie w akapicie.
Jeżeli w rekordzie jest wprowadzany tekst, jest on automatycznie dodawany na końcu akapitu. W takim wypadku, ponowne generowanie doprowadza do skasowania danego akapitu, nawet jeśli występowanie tego akapitu nie jest już uzasadnione z uwagi na ewolucję słownika.

Tworzenie pustych akapitów oraz zwykłych akapitów

Niektóre akapity są tworzone automatycznie podczas generowania ze słownika, ale bez tekstu, ponieważ są to dowolne akapity zazwyczaj występujące w określonych typach dokumentów. Tekst wprowadzony w tabeli ADOCUMENT jest następnie pozyskiwany dla ostatecznego dokumentu bez konkretnego układu. Niektóre akapity nie są tworzone automatycznie podczas generowania słownika, ale mogą być one tworzone później. Są one nazywane dowolnymi akapitami w dalszej części dokumentacji.

Łącze hipertekstowe

Z wyjątkiem szczególnych przypadków, o których mowa poniżej, proces tworzenia akapitów generuje kotwicę z taką samą nazwą w tekście. Dzięki temu możliwie jest tworzenie łącza hipertekstowego do przedmiotowego akapitu (ścieżka łącza przyjmuje postać w tym przypadku document.htm#kotwicazamiast document.htm ). Tak więc, aby uzyskać bezpośredni dostęp do dokumentacji na trzeciej zakładce funkcji „Zarządzanie użytkownikami (GESAUS), należy używać łącza GESAUS.htm#ON3.

Kody akapitów, które można znaleźć w dokumentacji, w niektórych przykładach muszą posiadać łącze dla akapitu. W tym przypadku, łącze wyświetlane jest w następującej postaci: PARAG_LEV_SLEV. PARAG jest kodem akapitu, LEV jest kodem poziomu, a SLEV jest kodem podpoziomu. A zatem, dla akapitu MIS, usytuowanego na poziomie 140 i podpoziomie 40 dokumentu ADO_FCT, łączem będzie ADO_FCT#MIS_140_40.

Różne typy dokumentów

Pole „Typ dokumentu” określa, co zostanie udokumentowane.

Poniższa tabela opisuje możliwe typy dokumentów:

Szczegółowe informacje na temat niektórych dokumentów

Dokumenty typu AFC

Dokumenty typu AFC są najbardziej obszerne. Są one używane do opisywania szczegółowo funkcji, ich warunków wstępnych (zestawu zautomatyzowanych podakapitów), interfejsu użytkownika (zakładki z pomocą dla pól, przyciski, pozycje menu) oraz załączników (raporty, lista błędów i obsługiwanych tabel).
Część akapitów tworzących te dokumenty jest w pełni generowana ze słownika, ale większość akapitów musi być wprowadzana. Kod powiązany z tą dokumentacją jest kodem funkcji (zgodne z definicją w słowniku funkcji). Nazwa odpowiedniego pliku HTML będzie generowana w podkatalogu FCT katalogu dokumentacji.
Może być on przywoływany z dowolnego ekranu funkcji poprzez klucz F1.

Dokumenty typu DI

Dokumenty typu DI nie są powiązane z elementem słownika. Są one używane do tworzenia załączników technicznych i dokumentacji ogólnej. Na przykład, w standardowej dokumentacji, GESAWA.htm jest dokumentacją powiązaną ze zdarzeniami Workflow. GES_AWA.htm jest dokumentem typu DI i jest to powiązany załącznik techniczny.
Dokumenty typu DI są generowane w słowniku FCT.
Aby zapobiec mieszaniu się dokumentacji funkcjonalnej z dokumentacją DI, konieczne jest wstawienie przynajmniej znaku „_” w kodzie dokumentacji DI.

Dokumenty typu ACV, ADM, ADP, AOE, ARP, AWA, CDA, CDE, GAU, PS1, ADC

Dokumenty typu ACV, ADM, ADP, AOE, ARP, AWA, CDA, CDE, GAU, PS1, ADC są typu obiektowego, do których dostęp można uzyskać poprzez użycie kombinacji Alt + F1 z funkcji konfiguracji. Dokumenty te służą do opisania warunków konfiguracji bieżącego rekordu. Ogólną zasadą jest, aby ten typ dokumentu zawierał jakiś tekst (głównie tekst na temat użytkowania lub opis danego kodu, a czasami nawet pewne uwagi).
Niektóre kody akapitów są specjalne dla tego typu dokumentów. Kod powiązany z tą dokumentacją jest kodem odpowiedniego rekordu. Plik dokumentacji jest generowany w podkatalogu OBJ. Składa się on z kodu obiektu, po którym występuje klucz rekordu.

Przykłady
- Kod czynności BPA jest wygenerowany z nazwy ACV_BPA.htm.
- Szablon importu/ eksportu BPR jest generowany z nazwy AOE_BPR.htm.

Należy zwrócić uwagę, że klucz konfiguracji w dwóch częściach zintegrowany jest z odpowiednim rozdziałem. Przykładowo, pomoc dla konfiguracji ADMUSR (rozdział SUP) jest wtedy generowana pod nazwą ADP_SUP_ADMUSR.htm.

Dokumenty typu AML, ATB, ATY

Dokumenty typu AML, ATB, ATY są dokumentami opisującymi strukturę danych.
Dostęp do nich jest możliwy z zawartości pomocy.
Ten typ dokumentu składa się tylko z jednego akapitu (akapitu tytułu. który służy do dodawania opcjonalnego komentarza przed wygenerowaniem dokumentu). Są on generowane w katalogu MCD i ponownie używają kodu tabeli (bez prefiksu), kod typu danych z prefiksem ATY_ oraz numer menu lokalnego w postaci MEN####.htm (gdzie #### jest numerem menu składającym się z 4 cyfr, z zerami dodanymi po lewej stronie).

Dokumenty typu APM

Dokumenty typu APM są menu pomocy.
Dokumenty te są generowane z katalogu i występuje w nich tylko jeden akapit. Możliwe jest tworzenie innych dokumentów w celu opisania dodatkowych menu, które porządkują dokumentację (w tym przypadku akapit zawiera listę przywołanych dokumentów). Możliwe jest także dodanie dodatkowych powiązań dokumentów w generowanej dokumentacji tego typu.

Dokumenty typu FI

Dokumenty typu FI są po prostu używane do ekstrakcji dokumentacji. Reguła nazewnictwa tych dokumentów wskazuje miejsce tworzenia plików. Szczegóły można znaleźć w odpowiednim akapicie.

Menu dokumentów

Wszystkie funkcje obsługują rekordy, które mogą być udokumentowane za pomocą funkcji zarządzania dokumentacją przy uwzględnieniu następujących warunków:

• Określanie w tabeli dodatkowej 910 kodu dokumentów powiązanego z kodem obiektu, dla którego obsługiwana ma być dokumentacja rekordu.
• Typ dokumentu odnosi się do typu obiektu, a klucz powiązany jest z kluczem głównym rekordu, który jest dokumentowany (jeśli jest to klucz w wielu częściach, są one rozdzielone znakiem podkreślenia „_”).
• Generowanie dokumentów w formacie HTML (są one tworzone domyślnie w katalogu OBJ, katalogu dla pomocy obiektu).
• Pomoc jest wywoływana dla danego rekordu za pomocą kombinacji Alt + F1.

Przykłady
AFC (pomoc funkcjonalna) odnosi się do pomocy funkcji i funkcji obsługujących obiekt AFC. Jest tym samym dla dokumentów ADP (ustawienia), ACT (działania) oraz ACV (kod czynności, etc.).

Niezwłocznie po wystąpieniu kodu obiektu w tabeli dodatkowej 910, menu „Dokumentacja” jest automatycznie wyświetlane we pasku menu odpowiedniego obiektu.
Funkcje, do których dostęp jest możliwy poprzez menu, opisane są poniżej.

Dokumentacja/ Akapity

Funkcja ta służy do uzyskania dostępu do zarządzania dokumentacją dla pierwszego akapitu dokumentu (jeżeli jakiś istnieje), powiązanego z bieżącym rekordem.

Dokumentacja/ Powiązania

Funkcja ta służy do uzyskania dostępu do zarządzania powiązaniami. Jest to używane do określania powiązań pomiędzy bieżącymi a pozostałymi rekordami (np. powiązań między funkcjami a ustawieniami). Połączenia te są specyficzne dla dokumentów i są one używane do wczytywania generowania struktur dokumentów.

Dokumentacja/ Generowanie

Wstępne akapity

Akapity te są wprowadzeniem dla dokumentów funkcjonalnych.

Kod TIT (tytuł)

Rozdział ten określa tytuł dokumentu w jego tytule.

Podczas generowania dokumentów funkcjonalnych ze słownika, rozdział ten jest automatycznie tworzony na poziomie (10,10).

W przypadku dokumentów słownika (tabele, menu lokalne, typy danych), dla których jest to jedyny akapit, wprowadzany tekst jest tekstem wstawianym przed tabelami opisującymi strukturę techniczną słownika.

W przypadku dokumentów opisujących menu APM), możliwe jest dodawanie powiązań z innymi pomocami poprzez ich identyfikację z odpowiednimi kodami. Następnie kodowana jest pozycja w następujący sposób:

• albo kod funkcji (pomoc funkcjonalna). Na przykład: GESAUS
• albo kod pomocy z jego typem jako prefiks, a znak „/” jako rozdzielenie. Na przykład: DI/ADO_FCT
• albo jedna z poprzednich składni, po której występuje znak „#” oraz nazwa etykiety, aby ustawić na środku dokumentu. Na przykład: GESAUS#ON3

W przypadku pozostałych typów dokumentów, możliwe jest wstawianie do tekstu jedynie ciągu wyrazów rozdzielonych przecinkiem, które wprowadzane są w polu „Słowo kluczowe” (słowa kluczowe dla wyszukiwania, które nie są wyświetlane w tekście). W tym przypadku, nie występują żadne powiązane akapity (a także żadne kotwice) w ostatecznym dokumencie HTML.

Ten typ akapitów jest zapewniany dla wszystkich typów dokumentów. Jeżeli akapit posiada kod czynności i generowany jest dokument dla folderu, dla którego kod ten nie jest aktywny, dany dokument nie zostanie wygenerowany.

Szczególnie, jeśli akapit ten posiada kod czynności FAL:

• ostateczny dokument nie jest generowany.
• ponowne generowanie struktury dokumentu nie wpływa na proces generowania (generowanie jest zatrzymywane, jeśli akapit TIT posiada kod czynności FAL).

Jeżeli tytuł nie jest wprowadzony w rekordzie, jest on wyszukiwany w słowniku zgodnie z kontekstem. W ten sposób możliwa jest obsługa szczególnych przypadków, np. pomoc dla pola dla funkcji RPT*, gdzie nazwa grupa musi być nazwą słownika.

Kod PRE (prezentacja)

Ten akapit określa prezentację udokumentowanego podmiotu (funkcji, kodu czynności, konfiguracji wymiarowania, ustawienia, itd. Brane są pod uwagę wszystkie dokumenty). Akapit ten jest automatycznie tworzony pusty na tym poziomie (10,20).

To jest pierwszy wyświetlany akapit w ostatecznym dokumencie funkcjonalnym.

Nie ma potrzeby wprowadzania tekstu dla prezentacji kodów czynności zależnych od innego kodu (używany jest automatyczny tekst, jeśli pole tekstu jest puste).

Akapity dla wstępnych warunków funkcjonalnych

Akapity te opisują wstępne warunki, jakie są konieczne do wykonania danej funkcji. Tak więc, są one obecne w dokumentach funkcjonalnych, nawet jeśli niektóre mogą występować także w innych dokumentach (dokumenty dla kodów czynności, raportów, zdarzeń Workflow, itd.).

Są to:

Kod PRQ (wstępne warunki)

Akapit ten, określający wstępne warunki, występuje w dokumentacji dla funkcji, raportów, szablonów importu/ eksportu.

Jest to akapit wprowadzający,tworzony pusty na poziomie (30,10). W dokumentacji dla funkcji akapit ten jest tworzony tylko wtedy, gdy inny akapit wstępnego warunku jest tworzony (zważywszy, że jest tworzony dla dokumentacji na temat importu/ eksportu oraz raportów).

Tekst ten nie jest obowiązkowy (jeżeli tekst nie występuje, akapit istnieje jako śródtytuł).

Kody ACV (kody czynności)

Akapit ten występuje w dokumentacji dla funkcji, ustawień oraz kodów czynności. Jest to akapit wygenerowany na poziomie (30,20) za pomocą stylu 4:

• w dokumentacji dla funkcji, jest to generowane ze słownika, gdy można znaleźć co najmniej jeden kod czynności (są one wyszukiwane w funkcji, oknie powiązanym z funkcją, obiekcie, zapytaniu oraz w powiązanych tabelach). Można również powiązać kod z funkcją poprzez tabelę powiązań ADOCFNC. Wtedy jest to podakapit akapitu PRQ.
• w dokumentacji dla ustawień, jest to generowane poprzez wyszukiwanie w słowniku oraz poprzez powiązania między ustawieniem a kodem czynności.
• W dokumentacji opisującej kod czynności. Jest to generowanepoprzez uwzględnienie kodów czynności zależnie od dokumentowanego kodu czynności (to powiązanie występuje również w słowniku).

Podczas generowania ostatecznego dokumentu, wykonywane jest wyszukiwanie w celu znalezienia kodów czynności z takim samym algorytmem w słowniku. Są one wyświetlane w postaci tabeli z powiązaniami, aby udokumentować opisywany kod czynności.

Należy zauważyć, że system automatycznie przeszukuje cały słownik i dlatego może zwracać kaskadowo istotną liczbę niepożądanych kodów czynności na liście. Dostępna jest szczególna funkcjonalność do sortowania listy: Obecność kodu czynności FAL (zawsze „False”) w powiązaniach dokumentacji blokuje wyszukiwanie kodów czynności w słowniku. Pozostają tylko powiązania z kodami czynności (z wyłączeniem FAL), które zostały uwzględnione w tych powiązaniach.

Kod ADP (ustawienia)

Akapit ten występuje w dokumentacji dla funkcji, ustawień oraz szablonów importu/ eksportu. Jest to akapit wygenerowany na poziomie (30,30) za pomocą stylu 4:

• w dokumentacji dla funkcji akapit ten określa listę ustawień powiązanych z daną funkcją i jest on generowany za pomocą powiązań pomiędzy funkcją a ustawieniem, bądź ustawieniem a funkcją (powiązania wzajemne są także analizowane). Jest to podakapit akapitu PRQ.
• w dokumentacji dla ustawień akapit jest generowany poprzez wyszukiwanie w słowniku (uwzględniane są ustawienia z tej samej grupy oraz z tego samego rozdziału) oraz przy użyciu powiązań między ustawieniem a ustawieniem tabeli powiązań.
• w dokumentacji opisującej szablon importu/ eksportu, akapit opisuje powiązane ustawienia (wyszukiwane poprzez przechodzenie przez powiązania między szablonami i ustawieniami, bądź odwrotnie w tabeli powiązań).

Podczas generowania ostatecznej dokumentacji, ustawienia są sortowane wg grupy i wyświetlane na listach z powiązaniami z dokumentacją opisującą parametry ogólne.

Kod ANM (liczniki numerów sekwencji)

Jest to akapit wygenerowany na poziomie (30,40) za pomocą stylu 4, który jest obecny w dokumentacji dla funkcji i podaje listę liczników numerów sekwencji, używanych przez daną funkcję. Jest to generowane, jeśli znaleziony jest co najmniej jeden licznik w tabeli powiązań (możliwe jest powiązanie licznika z funkcją). Jest to podakapit akapitu PRQ.

Podczas generowania ostatecznej dokumentacji, liczniki wyświetlane są na liście.

Kod GAU (automaty księgujące)

Jest to akapit generowany na poziomie (30,50) za pomocą stylu 5, który jest obecny w dokumentacji dla funkcji i podaje listę automatów księgujących używanych przez daną funkcję. Jest to generowane, jeśli znaleziono co najmniej jeden automat księgujący w tabeli powiązań (możliwe jest powiązanie automatu księgującego z funkcją). Podakapit akapitu PRQ wprowadza globalnie akapity GAU i CDE. Poprzedzane jest to przez dodatkowy śródtytuł o stylu podrzędnym w stosunku do stylu akapitu (domyślnie 4), nazywany interfejsem księgowym.

Podczas generowania ostatecznej dokumentacji, automaty księgujące wyświetlane są w tabeli z powiązaniem do dokumentacji je opisujących.

Kod CDE (analityki/ domyślnie)

Jest to akapit generowany na poziomie (30,60) za pomocą stylu 5, który jest obecny w dokumentacji dla funkcji i podaje listę kodów analityki, używanych przez daną funkcję. Jest to generowane, jeśli znaleziony jest co najmniej jeden kod analityki w tabeli powiązań (możliwe jest powiązanie kodu analityki z daną funkcją). Podakapit akapitu PRQ wprowadza globalnie akapity GAU i CDE. Poprzedzane jest to przez dodatkowy śródtytuł o stylu podrzędnym w stosunku do stylu akapitu (domyślnie 4), nazywany interfejsem księgowym.

Podczas generowania ostatecznej dokumentacji, wyświetlane są w tabeli kody analityki z powiązaniem do dokumentacji, które je opisują.

Kod HAB (autoryzacje)

W dokumentacji funkcjonalnej ten opcjonalny akapit jest z reguły podakapitem akapitu PRQ.

Jest to akapit generowany domyślnie na poziomie (30,70) za pomocą stylu 4 po zatwierdzeniu jednego z poniższych warunków:

• funkcja posiada prawo dostępu, które obsługiwane jest zgodnie z lokalizacją.
• w słowniku istnieją opcje autoryzacji dla danej funkcji.
• funkcja jest typu obiektowego (a zatem, istnieją domyślne opcje tworzenia/ usuwania/ modyfikacji).
• kod dostępu jest deklarowany na poziomie obiektu, jeśli funkcja jest typu obiektowego.

Podczas generowanie ostatecznej dokumentacji, tworzony jest zestaw automatycznych tekstów na podstawie kontekstu (zarządzanie poprzez kody dostępu, opcje autoryzacji dla słownika, itp.)

Kod TRS (transakcje)

W dokumentacji funkcjonalnej ten opcjonalny akapit jest z reguły podakapitem akapitu PRQ. Jest on generowany z powiązań między funkcjami a transakcjami (powiązanie typu TRS łączące daną funkcję z funkcją używaną do ustawienia transakcji). Generowanie odbywa się na poziomie (30,80) za pomocą stylu 4.

Podczas generowania ostatecznej dokumentacji, układ transakcji jest aktualizowany i wstawiane są powiązania z odpowiednią dokumentacją funkcjonalną.

Kody ECC (ekrany zapytań)

W dokumentacji funkcjonalnej ten opcjonalny akapit jest z reguły podakapitem akapitu PRQ. Jest on generowany ze słownika poprzez wyszukanie listy kodów zapytań, które można znaleźć w folderze, w którym generowana jest dokumentacja.

Należy zauważyć, że ten akapit jest generowany z takim samym wierszem jaki występuje w akapicie TRS, który jest logiczny, ponieważ oba akapity nie mogą współistnieć (jeden z nich dotyczy zapytań, drugi dotyczy obiektów) i oba odnoszą się do wariantów ekranu. Generowanie odbywa się na poziomie (30,80) za pomocą stylu 4.

Podczas generowania ostatecznej dokumentacji, wyświetlane są w tabeli te kody ekranu.

Kod PRD (inne wstępne warunki)

Jest to akapit generowany na poziomie (30,90) za pomocą stylu 4, który jest obecny w dokumentacji dla funkcji i podaje serię innych wstępnych warunków, wyświetlanych w postaci podakapitów ze śródtytułami stylu 5.

• pierwszy z nich podaje listę tabel dodatkowych do aktualizacji. Jest ona ładowana pomiędzy funkcją a tabelami dodatkowymi.
• drugi podaje listę tabel bazy danych do aktualizacji. Jest ona ładowana pomiędzy funkcją a tabelami (poprzez kody AT2 i ATB, wczytujące zaktualizowane tabele).
• trzeci podaje listę menu lokalnych, które należy wprowadzić. Jest ona ładowana przez powiązania między funkcją a menu lokalnymi.
• ostatni podakapit, nazywany „Inne wstępne warunki”, występuje, jeśli do dokumentu został dodany tekst. Jeżeli tekst rozpoczyna się od tytułu (z etykietą typu Hn, gdzie n jest liczbą), śródtytuł „Inne wstępne warunki” nie jest wstawiany.

Opis interfejsu

Te generowane akapity opisują organizację okna wprowadzania, które powiązane jest z daną funkcją. Są one jedynie generowanie automatycznie, jeśli istnieje okno powiązane z daną funkcją. Ostateczne generowanie obejmuje pomoc funkcjonalną, jeśli wprowadzane jest pole „Ekran” występujące w rekordzie.

Do tych akapitów należą:

Kod ECR (opis ekranu)

Akapit ten jest wprowadzeniem, które umożliwia definiowanie w szczególności liczby etykiet, aby opisać specyficzność lewej listy, jeśli występuje.

Podczas generowania dokumentów funkcjonalnych ze słownika, rozdział ten jest automatycznie tworzony na poziomie (40.50) za pomocą stylu 3.

Kod ENT (nagłówek ekranu)

Akapit ten opisuje pola nagłówka okna (jeżeli istnieje). Tekst, który jest tutaj wprowadzany, wstawiany jest do ostatecznej dokumentacji w postaci, w jakie istnieje. Po wprowadzeniu kodu ekranu podczas konfiguracji, pasek tytułu zawiera niewielką ikonę w postaci strzałki skierowanej do dołu, która rozwija automatycznie listę pól nagłówka (i odpowiednie pliki pomocy). Generalną zasadą jest to, że tekst ten używany jest do podawania szczegółów dla pól tworzących klucz obiektu lub kryterium zapytania.

Podczas generowania dokumentów funkcjonalnych ze słownika, rozdział ten jest automatycznie tworzony na poziomie (40,100) za pomocą stylu 3, gdy okno powiązane z daną funkcją używa maski nagłówka.

Kody ON1 do ONF (etykiety)

Te akapity opisują każdą etykietę okna, które powiązane jest z daną funkcją. Pasek tytułu zawiera niewielką ikonę w postaci strzałki skierowanej do dołu, która rozwija automatycznie listę pól nagłówka (i odpowiednie pliki pomocy), jeśli pole ekranu jest wprowadzane w rekordzie, który nie jest przypadkiem dla automatycznego generowania.

Generalną zasadą jest to, że tekst ten jest używany do podania informacji na temat pól występujących w danej etykiecie (bez konieczności podawania szczegółów dla pomocy dla każdego pola, ponieważ pomoc online dla pola jest także dostępna poprzez rozwinięcie). Jeżeli nie jest przypisany żaden tekst, typowy tekst proponuje rozwinięcie pomocy dla pola.

Podczas generowania dokumentów funkcjonalnych ze słownika, rozdział ten jest automatycznie tworzony na poziomie 40 z opisu okna, które powiązane jest z daną funkcją. Podpoziomy generowania są obliczane z wiersza etykiety (pole ROWMSK), aby zapewnić zgodność z kolejnością prezentacji etykiet funkcji podczas dodawania specjalnych etykiet, które muszą być wstawiane pomiędzy dwoma istniejącymi etykietami. Podpoziom jest równy wierszowi pomnożonemu przez wartość 200. Dlatego też, jeśli wiersze są numerowane co 10, uzyskane wiersze to 2000, 4000, 6000. Najwyższy możliwy wiersz to 19800, a najniższy 200.

Podczas generowania dokumentacji tworzone są automatyczne akapity opisujące działania „Przycisk na tabelach” (kliknięcie prawym przyciskiem myszy), poprzedzające akapit powiązany z każdą etykietą. Są one numerowane co 5, aby podać możliwość wstawiania akapitów dodatkowych.

Kody BOT (kliknięcia na tabelach)

Te akapity opisują każdą z dostępnych funkcji poprzez kliknięcie tabeli prawym przyciskiem myszy. Występować może wiele akapitów (z takim samym kodem: wtedy odpowiednią kotwicą jest BOT_LEV_SLEV, gdzie LEV reprezentuje poziom, a SLEV podpoziom). Każdy z tych przycisków należy wprowadzać w kolejności akapitów, tuż po akapicie opisującym etykietę, w której jest on umieszczany.

Podczas generowania dokumentacji funkcjonalnej ze słownika, akapity te są automatycznie tworzone na poziomie 40 za pomocą zakresu numerowania od 5 do 5, rozpoczynając od numeru etykiety (np. 2005, 2010, 2015, itd. po etykiecie wiersza 10). Domyślnie użytym stylem jest numer 6, a śródtytuł o nazwie „Funkcje dostępne poprzez kliknięcie tabeli prawym przyciskiem myszy”stylu 5 jest używany w kolejnych akapitach tego typu.

Kody BOU (przyciski)

Akapity opisują każdy z przycisków, które dostępne są w dolnej części ekranu. Występować może wiele akapitów (z takim samym kodem: wtedy odpowiednią kotwicą jest BOU_LEV_SLEV, gdzie LEV reprezentuje poziom, a SLEV podpoziom). Te przyciski są zazwyczaj umieszczane po akapitach powiązanych z etykietami. Pierwszy z nich jest akapitem wprowadzającym, którego tytuł używa standardowego stylu (domyślnie 3). Tytuł kolejnych rozdziałów BOU jest wyświetlany w środowisku przycisków, co oznacza, że tekst musi odpowiadać tekstowi dla przycisku. Następnie odpowiedni tekst jest wstawiany po prawej stronie każdego przycisku.

Podczas generowania dokumentacji funkcjonalnej ze słownika, akapity te są automatycznie tworzone na poziomie 70, z podpoziomem rozpoczynającym się od wartości 19 (tytuł rozdziału dotyczącego przycisku), a następnie przyjmując wartość 10 zwiększaną o 10 (20 dla pierwszego przycisku, 30 dla drugiego, itd.).

Kody BME (paski menu)

Te akapity opisują każdą z dostępnych funkcji za pomocą paska menu. Występować może wiele akapitów (z takim samym kodem: wtedy odpowiednią kotwicą jest BME_LEV_SLEV, gdzie LEV reprezentuje poziom, a SLEV podpoziom). Te akapity ustawiane są po akapitach. Pierwszy z nich jest akapitem wprowadzającym, którego tytuł używa standardowego stylu (domyślnie 3). Tytuł kolejnych rozdziałów posiada styl 4.

Podczas generowania dokumentacji funkcjonalnej ze słownika, akapity te są automatycznie tworzone na poziomie 80, z podpoziomem rozpoczynającym się od wartości 19 (tytuł rozdziału dotyczącego menu), a następnie przyjmując wartość 10 zwiększaną o 10 (20 dla pierwszego przycisku, 30 dla drugiego, itd.).

Akapity załączników

Te akapity zakończeń podają informacje na temat załączników (lista błędów, raportów, zadań przetwarzania w tle, itp.) Są to:

Kod RPT (raporty)

Jest to akapit generowany na poziomie (50,10) za pomocą stylu 4, który jest obecny w dokumentacji dla funkcji i podaje listę raportów, używanych przez daną funkcję. Jest on generowany ze słownika (wyszukiwany w kodach drukowania określonych w słowniku funkcji dla „Drukuj” oraz „Lista”, poprzez wyszukiwanie, jeśli raporty są powiązane z nimi w tabeli kodu drukowania). Raport ten jest uzupełniany przez raporty głównie znalezione poprzez wyszukiwanie powiązań między funkcją a raportami w tabeli powiązań.

Podczas generowania ostatecznej dokumentacji, generowana jest tabela zawierająca uruchomione raporty za pomocą funkcji ze złączami hipertekstowymi nakierowanymi na odpowiednie dokumenty.

Kod ABT (zadania przetwarzania w tle)

Jest to akapit generowany na poziomie (60,10) za pomocą stylu 4, który jest obecny w dokumentacji dla funkcji i podaje listę zadań przetwarzania w tle, używanych do uruchamiania funkcji w trybie przetwarzania. Jest on generowany ze słownika (wyszukiwany w tabeli zadania przetwarzania w tle). Ta lista zadań jest uzupełniana przez zadania potencjalnie znalezione podczas wyszukiwania powiązań między funkcją a zadaniami przetwarzania w tle w tabeli powiązań.

Podczas generowania ostatecznej dokumentacji, generowana jest tabela zawierająca listę istniejących zadań.

Kod ERR (błędy)

Akapit ten jest dedykowany liście błędów, która może być wyświetlana podczas używania danej funkcji. Wprowadzony tekst jest bezpośrednio wstawiany do dokumentu. Jedynie błędy szczególne dla danej funkcji są tutaj wstawiane. Faktycznie w dedykowanym dokumencie wyszczególniane są typowe błędy, a łącze do tego dokumentu jest automatycznie wstawiane do tego akapitu. Ponadto, akapit jest tworzony pusty.

Ten typ akapitu jest również używany w dokumentacji na temat szablonów importu/ eksportu, z takimi samymi właściwościami.

Podczas generowania dokumentów funkcjonalnych ze słownika, rozdział ten jest automatycznie tworzony na poziomie (80,10) za pomocą stylu 3. Jeżeli z akapitem nie jest powiązany żaden tekst, tekst ostrzega, że jedynymi znanymi błędami są typowe błędy, do których dostęp można uzyskać przy użyciu łącza). W przeciwnym razie, tekst wyszczególnia błędy oraz odpowiednie wyjaśnienia. Zalecane jest używanie stylu H5 dla tekstu błędów oraz domyślny styl akapitu dla wyjaśnień, który doprowadza do uzyskania następującego wyniku:

Możliwe jest zastosowanie składni „mess”() 4GL dla tekstu błędu. Umożliwia to uzyskanie stałego tłumaczenia dla tekstu błędu.

Na przykład:

doprowadza do poniższego podczas generowania:

Kod ATB (obsługujący tabele)

Akapit ten występuje w dokumentacji na temat funkcji i ustawień wymiarowania, szablonów importu/ eksportu, raportów, reguł Workflow oraz zdarzeń wywołujących statystyki. Jest to akapit generowany na poziomie (90,10) za pomocą stylu 3:

• w dokumentacji dla funkcji, jest to generowane ze słownika, gdy znajdowana jest co najmniej tabela (tabele są wyszukiwane w zapytaniu obiektu). Można również powiązać tabelę z funkcją poprzez tabelę powiązań.
• W innych dokumentach zastosowanie ma ta sama zasada: akapit jest generowany, jeśli do wyszukiwania tabel używany jest słownik, bądź jeśli znalezione zostały powiązania.
• w przypadku dokumentacji na temat ustawień wymiarowania, wyszczególniane tabele są tymi, których rozmiar uzależniony jest od ustawienia.

Podczas generowania ostatecznej dokumentacji, wyświetlane są w tabeli tabele, zawierające powiązanie ze słownikiem tabeli oraz obiektem, kiedy istnieje, co umożliwia obsługę tabeli branej pod uwagę. Jeżeli występują tabele wspólne dla wszystkich folderów, są one odseparowane w dedykowanym akapicie.

Akapity specjalne

Akapity te mogą być wstawiane w dowolnym miejscu w dokumentacji, aby obsługiwać wyjątki lub nieplanowane dodatkowe akapity. Są one również używane do segmentowania akapitu, gdy jest on zbyt długi (długość tekstu wprowadzanego bez akapitu ograniczany jest przez budowę). Ze względu na możliwość powtarzania kodu używanego dla tych akapitów, nie występuje żadna kotwica, która ma taką samą nazwę (ponadto tworzone są kotwice techniczne, które są numerowane przy użyciu kodu akapitu, po którym występuje poziom lub podpoziom, rozdzielony za pomocą znaku „_”). Do tych akapitów należą:

Kody MIS (dodatkowe)

Jest to dodatkowy akapit występujący w tabeli zawartości, powiązanej z odpowiednim poziomem. Wprowadzany jest tytuł, styl oraz tekst do wstawienia.

Ze względu na możliwość występowania w dokumentacji wielu akapitów tego typu, kotwicą powiązaną z tymi akapitami jest MIS_LEV_SLEV, gdzie LEV reprezentuje poziom, a SLEV podpoziom.

Kody MIN (dodatkowe)

Ten dodatkowy akapit nie występuje w tabeli zawartości, powiązanej z odpowiednim poziomem. Wprowadzany jest tytuł, styl oraz tekst do wstawienia.

Ze względu na możliwość występowania w dokumentacji wielu akapitów tego typu, kotwicą powiązaną z tymi akapitami jest MIS_LEV_SLEV, gdzie LEV reprezentuje poziom, a SLEV podpoziom.

Kody LNK (powiązania)

Ten typ akapitu służy do wstawiania tabel zawartości w postaci:

• albo listy powiązań nagłówka (umieszczanych na pasku tytułu dokumentu). To sugeruje, że akapit typu LNK jest umieszczony na tym samym poziomie, co akapit TIT odpowiedniej dokumentacji. Tytuł akapitu podaje tytuł aktualnego dokumentu zdefiniowanego na liście powiązań.
• bądź listy powiązań (jak tabela zawartości) w ogólnym przypadku. Ten typ akapitu służy do wstawiania powiązań z dokumentami, do których nie można uzyskać bezpośredniego dostępu w hierarchii dokumentu.

Gdy powiązanie określa osobny akapit, tytuł i styl nie są brane pod uwagę, a w tabeli zawartości nie jest wyświetlany żaden wpis. Gdy konieczne jest dodanie tytułu do tego akapitu powiązań, wystarczające jest, gdy przed tym występuje akapit typu MIS lub MIN.

Powiązania są określane w tekście akapitu w jednej z następujących postaci:

• CODE_FONCTION
• CODE_FONCTION#kotwica
• TYPE/CODE
• TYPE/CODE#kotwica

Znaczenie poszczególnych elementów jest następujące:

• CODE_FONCTION jest kodem dokumentacji funkcjonalnej (typu AFC lub DI): punkty połączeń z podkatalogiem FCT, w którym można znaleźć ten typ dokumentów.
• TYPE odnosi się do różnych typów dokumentów: np. ADC, AD, ACV, itp. Kod, występujący po tym jest kodem dokumentów.
• kotwica odnosi się do kotwicy akapitu, kiedy wymagane jest bezpośrednie umieszczenie w danym akapicie. Kotwica nie jest brana pod uwagę, jeśli jest to powiązanie nagłówka.

Każde powiązanie jest badane podczas generowania: odpowiednia dokumentacja jest przeszukiwana w tabeli ADOCUMENT (jeżeli nie istnieje, powiązanie nie jest wstawiane) a tytuł dokumentacji jest wstawiany wraz z tekstem zawierającym dane powiązanie.

Kody INC (włączanie)

Ten akapit służy do włączania takich akapitów lub tych, które już występują w innych dokumentach.

Można uwzględnić dowolny akapit, oprócz akapitów typu TIT. Gdy wymagane jest ponowne użycie akapitu prezentacji powiązanego z innymi dokumentami, akapit INC, który zastępuje go, musi być pierwszym tego typu w dokumentacji i musi być powiązany z innym akapitem typu PRE.

Ze względu na możliwość występowania w dokumentacji wielu akapitów tego typu, kotwicą powiązaną z tymi akapitami jest INC_LEV_SLEV, gdzie LEV reprezentuje poziom, a SLEV podpoziom.

Akapit do ponownego użycia musi następnie być identyfikowany w tekście akapitu włączania w jednej z następujących postaci:

• TYPE/CODE
• TYPE/CODE/NIVEAU/SOUS-NIVEAU

Poziom i podpoziom nie są obowiązkowe (akapit o takim samym poziomie i podpoziomie jest pozyskiwany domyślnie w powiązanej dokumentacji).

Na przykład, gdy wymagane jest wstawienie akapitu powiązanego z pierwszą etykietą rekordu użytkownika, który jest określany na poziomie 40 i podpoziomie 200, tekst w akapicie wyłączenia jest następujący:

AFC/GESAUS/40/200

Należy zauważyć, że wszystko jest pozyskiwane z akapitu źródła (tytuł, tekst, układ, pomoce dla pól), z wyjątkiem dla poziomu i podpoziomu, które pozostają takie same jak w oryginalnym akapicie (w ten sposób uwzględniane są podziały w tabelach). Tytuł tabeli zawartości odnosi się do tytułu oryginalnego akapitu INC; utworzona kotwica może być używana do powiązań i odnosi się do typowej kotwicy INC_row_sub-row.

Akapity zarezerwowane dla innych dokumentów

Te akapity są charakterystyczne dla typów dokumentów innych niż dokumenty na temat funkcji. Są to:

Kod LEV (poziom)

Akapit ten jest charakterystyczny dla dokumentacji na temat ustawień. Jest on generowany ze słownika na poziomie (30,10).

Podczas ostatecznego generowania, generowany tekst określa poziom definicji ustawienia, a także nazwę powiązanej zmiennej ogólnej, jeśli istnieje. Jeżeli nie można znaleźć żadnej zmiennej ogólnej, tekst informuje, że nic nie jest wstawione, z wyjątkiem sytuacji, gdy tekst rekordu jest przypisany (w tym przypadku tekst może odnosić się do zmiennej, która nie jest zadeklarowana w słowniku).

Kod REM (uwagi)

Akapit ten jest charakterystyczny dla dokumentacji na temat ustawień, automatów księgujących oraz domyślnych kodów analityk. Jest on tworzony pusty ze słownika na poziomie (70.10).

Tekst w rekordzie staje się dostępny dla wprowadzania dodatkowych uwag.

Kod PAR (ustawienia dla działań)

Akapit ten jest charakterystyczny dla dokumentacji na temat działań. Jest on generowany ze słownika na poziomie (30,10), aby umożliwić wyświetlanie listy ustawień działań.

Podczas generowania ostatecznej dokumentacji, tworzone jest twierdzenie wprowadzające, po którym tabela wyświetla ustawienia, ich tytuł oraz typ danych. Gdy nie występują żadne ustawienia, wstawiane jest zaprzeczenie.

Kod UTI (użycie działania)

Akapit ten jest charakterystyczny dla dokumentacji na temat działań. Jest on tworzony pusty ze słownika na poziomie (40,10).

Zakłada się, że tekst wprowadzony do rekordu opisuje użycie działania.

Jeżeli akapit ten pozostaje pusty w momencie generowania ostatecznego dokumentu, nie jest on generowany.

Kod ACT (działania powiązane z działaniami)

Akapit ten jest charakterystyczny dla dokumentacji na temat działań. Jest on generowany na poziomie (50,10), aby umożliwić wyświetlanie listy działań powiązanych z udokumentowanym działaniem. Generowanie jest wykonywane z powiązań (i wzajemnych powiązań) znajdywanych między jednym działaniem a drugim.

Podczas generowania ostatecznej dokumentacji, tworzone jest twierdzenie wprowadzające, po którym tabela wyświetla działania z powiązaniem do określonej dokumentacji.

Kod REC (zalecane wartości)

Akapit ten jest charakterystyczny dla dokumentacji na temat ustawień i ustawień wymiarowania. Jest on tworzony pusty w przypadku ustawień oraz generowany w przypadku zmiennych wymiarowania (tworzona jest domyślna pozycja, jeśli akapit jest pusty, zawierający znalezioną wartość w folderze odniesienia). Tworzenie jest dokonywane na poziomie (30,10).

Zakłada się, że tekst wprowadzony do rekordu opisuje zalecane wartości dla przedmiotowego ustawienia.

Kod AFC (uwzględniane funkcje)

Akapit ten jest charakterystyczny dla dokumentacji na temat kodów czynności, parametrów ogólnych oraz raportów. Jest on generowany na poziomie (40,10) dla kodów czynności oraz raportów oraz na poziomie (50,10) dla parametrów ogólnych w celu wyświetlenia:

• listy funkcji uwzględnianych przez kod czynności. Generowanie jest wykonywane z powiązań, które są wspólne dla powiązań między funkcjami a kodami czynności, a także z kodów czynności znalezionych podczas szybkiego przeszukiwania słownika (pozyskiwane są tylko funkcje uzależnione bezpośrednio od kodu czynności). Podczas generowania ostatecznej dokumentacji, tworzone jest twierdzenie wprowadzające, po którym wyświetlana jest lista funkcji z łączem do określonej dokumentacji.
• sposób uzyskiwania dostępu do raportu (grupy drukowania oraz lista funkcji prawdopodobnie uruchamiające dany raport). Wtedy wykonywane jest generowanie poprzez analizę słownika oraz odczyt powiązań wspólnych dla powiązań pomiędzy funkcjami a raportami. Podczas generowania ostatecznej dokumentacji, tworzone jest twierdzenie wprowadzające, po którym występuje tekst określający, czy raport może być uruchamiany bezpośrednio, do które grupy drukowania on należy, a także określający listę funkcji prawdopodobnie uruchamiających raport z powiązaniem z odpowiednią dokumentacją.
• funkcje, na które wpływa ustawienie.

Kod AT2 (tabele, które mają być wprowadzane)

Akapit ten jest charakterystyczny dla dokumentacji na temat szablonów importu/ eksportu. Jest on generowany na poziomie (30,30) za pomocą stylu 4, aby wyświetlać listę tabel, które zakłada się, że są wprowadzane, aby mogły one używać odpowiedni szablon. Jest to podakapit akapitu PRQ. Generowanie jest wykonywane z powiązań między szablonami importu/ eksportu a tabelą (typu AT2).

Podczas generowania ostatecznej dokumentacji, tabele są wyświetlane w tabeli, a także poprzedzone przez twierdzenie wprowadzające. Powiązanie zawierające wskazanie do słownika tabeli oraz do obiektu, jeśli istnieje, co umożliwia obsługę przedmiotowej tabeli. Jeżeli występują tabele wspólne dla wszystkich folderów, są one odseparowane w dedykowanym akapicie.

Kod CHO (pola obowiązkowe)

Akapit ten jest charakterystyczny dla dokumentacji na temat szablonów importu/ eksportu. Jest on tworzony pusty na poziomie (40,10) w celu wyświetlania listy pól, które wydają się być obowiązkowe dla szablonu, aby działał.

Kod CRI (uruchamianie kryterium)

Akapit ten jest charakterystyczny dla dokumentacji na temat raportów oraz podprogramów.

W przypadku raportów, jest to akapit generowany domyślnie na poziomie (30,30) za pomocą stylu 4 używając danych słownika raportu, aby generować następujące teksty automatyczne:

• twierdzenie wprowadzające, po którym występuje lista ustawień raportu (zaprzeczenie jest wyświetlane, jeśli nie ma żadnych ustawień).
• twierdzenie określające szczególne zachowanie ustawień rozpoczęcia/ zakończenia, jeśli jakieś występują.
• twierdzenie określające, że jedno z ustawień może być wprowadzone z wieloma wartościami, jeżeli jest to taki przypadek (segmentacja raportu).
• twierdzenie określające, jeżeli jest to taki przypadek, że dane są filtrowane zgodnie z lokalizacją uzależniona od uprawnień użytkownika.
• twierdzenie określające, jeżeli jest to taki przypadek, że raport może być tylko drukowany przy użyciu drukarki określonego rodzaju.

W przypadku podprogramów, jest to akapit generowany domyślnie na poziomie (20,30) za pomocą stylu 4 używając danych słownika podprogramu, aby wyszczególniać ustawienia do przenoszenia do podprogramu.

Kod DES (opis raportu)

Akapit ten jest charakterystyczny dla dokumentacji na temat raportów. Jest on tworzony pusty na poziomie (40,10), aby opisywać zawartość raportu.

Kod CTX (kontekst)

Akapit ten jest charakterystyczny dla dokumentacji na temat Workflow, zdarzeń wyzwalający statystyki oraz entry points.

W przypadku zdarzeń wyzwalających statystyki oraz Workflow, akapit ten jest tworzony pusty na poziomie (30,10), aby opisywać wyzwalaną zawartość.

W przypadku entry points, może występować wiele akapitów tego typu. W rzeczy samej, dokumentacja na temat entry point może integrować wiele punktów wprowadzania. Przy każdorazowym tworzeniu akapitu APE, określanego na poziomie 20 i podpoziomie 10, z przyrostem o wartości 10 na wszystkich poziomach. Akapit CTX jest tworzony na tym samym poziomie odpowiedniego akapitu APE, na podpoziomie 20. Kotwica powiązana z tymi akapitami przyjmuje wtedy postać CTX_LEV_SLEV, gdzie LEV reprezentuje poziom, a SLEV podpoziom.

Podczas generowania ostatecznego dokumentu, akapit ten integruje automatyczne twierdzenia, wskazujące, że:

• istniej bądź nie istnieje bieżąca transakcja (powiązanie typu TRS ze słownika procesu; powiązana wartość 1 oznacza, że nie ma żadnej transakcji, a wartość 2, że dostępne jest transakcja).
• istnieje bądź nie istnieje otwarty log (powiązanie typu TRS ze słownika procesu; powiązana wartość 1 oznacza, że nie ma żadnego otwartego pliku rejestru, a wartość 2, że taki plik istnieje).

Akapit może również integrować listę tabel online w postaci tabeli. Listę tę można uzyskać przy użyciu powiązań ze słownika procesu do tabel, powiązanie typu ATB oznacza, że tabela jest otwarta i wprowadzona do kontekstu, a powiązanie typu AT2oznacza, że tabela jest otwarta. Należy zauważyć, że powiązania te mogą być wprowadzane w postaci CODE_TABLE [ABBREVIATION] gdy tabela nie jest otwarta pod swoim głównym skrótem.

Kod APE (entry point)

Akapit ten jest charakterystyczny dla dokumentacji na temat entry points.

W przypadku entry points, może występować wiele akapitów tego typu. Faktycznie, dokumentacja na temat entry point może integrować wiele punktów wprowadzania i tworzony jest akapit APE, określany z poziomu 20, podpoziomu 10, z przyrostem o wartości 10 dla poziomów. Kotwica powiązana z tymi akapitami przyjmuje wtedy postać APE_LEV_SLEV, gdzie LEV reprezentuje poziom, a SLEV podpoziom. Powiązany akapit CTX jest tworzony na tym samym poziomie jako odpowiedni akapit APE, na podpoziomie 20.

Podczas generowania dokumentów funkcjonalnych ze słownika, pierwszy z tych akapitów jest automatycznie tworzony na poziomie 20, podpoziomie 10. Kolejne akapity są tworzone z poziomów numerowanych z przyrostem o wartości 10. Kod punktów wprowadzania jest pozyskiwany przez powiązanie typu APE, powiązany opis zawierający kod entry point. Za tym powiązaniem mogą występować powiązania typu ATB, AT2, TRA oraz TRS. Kolejność deklaracji jest istotna: ze względu na możliwość występowania wielu powiązań APE, zakłada się, że pozostałe powiązania odnoszą się do ostatniego zadeklarowanego powiązania.

Kod entry point można również znaleźć w tytule akapitu. Kod ten musi pozostawać w nagłówku tytułu (może być zakończony wykrzyknikiem, oddzielony od kodu spacją lub nawiasem otwartym). Jeżeli nie są brane pod uwagę środki ostrożności, ostateczne dokumentacja nie może być generowana prawidłowo.

Podczas generowania ostatecznego dokumentu, akapity ten integrują automatyczne twierdzenia, wskazujące, że:

• istnieje bądź nie istnieje bieżąca transakcja (powiązanie typu TRS ze słownika procesu; powiązana wartość 1 oznacza, że nie ma żadnej transakcji, a wartość 2, że dostępne jest transakcja).
• istnieje bądź nie istnieje otwarty log (powiązanie typu TRS ze słownika procesu; powiązana wartość 1 oznacza, że nie ma żadnego otwartego pliku rejestru, a wartość 2, że taki plik istnieje).

Integrują one także listę tabel online w postaci tabeli. Listę tę można uzyskać przy użyciu powiązań ze słownika procesu do tabel, powiązanie typu ATB oznacza, że tabela jest otwarta i wprowadzona do kontekstu, a powiązanie typu AT2oznacza, że tabela jest otwarta. Należy zauważyć, że powiązania te mogą być wprowadzane w postaci CODE_TABLE [ABBREVIATION] gdy tabela nie jest otwarta pod swoim głównym skrótem.

Kod OPM (tryb roboczy)

Akapit ten jest charakterystyczny dla dokumentacji na temat automatów księgujących oraz domyślnych kodów analityki. Jest on tworzony pusty na poziomie (30,10), aby opisywać tryb roboczy.

Kod FLW (opis strumieni informacji)

Akapit ten jest charakterystyczny dla dokumentacji na temat raportów. Nie jest on tworzony automatycznie, ale zalecane jest jego umieszczenie w pozycji (40,10). Jest on używany do opisania kolejności Workflow, w jakiej zdarzenie to występuje.

Zestawienie struktur akapitu

Dla każdego typu dokumentacji występują generowane akapity oraz ich domyślna struktura przedstawiona poniżej (akapity INC, LNK, MIS oraz MIN mogą być dowolnie wstawiane).

AFC (dokumentacja na temat funkcji)

Ten dokument, który jest tworzony w katalogu FCT, może zawierać następujące akapity:

ADP (dokumentacja na temat ustawień)

Dokumentacja ta, która tworzona jest w katalogu OBJ, może zawierać następujące akapity:

ACT (dokumentacja na temat działań)

Dokumentacja ta, która tworzona jest w katalogu OBJ, może zawierać następujące akapity:

Uwzględniane akapity PRE:

• jego zawartość może być bezpośrednio przeglądana w katalogu działań i może on być modyfikowany z poziomu tego katalogu.
• domyślny tekst zostaje wygenerowany w akapicie, jeśli jest on pusty. Tekst ten wskazuje, że jest to wewnętrzne działanie, które nie będzie używane w określonym rozwiązaniu.

ACV (dokumentacja na temat kodów czynności)

Dokumentacja ta, która tworzona jest w katalogu OBJ, może zawierać następujące akapity:

ADM (dokumentacja na temat zmiennych wymiarowania)

Dokumentacja ta, która tworzona jest w katalogu OBJ, może zawierać następujące akapity:

AOE (dokumentacja na temat szablonów importu/ eksportu)

Dokumentacja ta, która tworzona jest w katalogu OBJ, może zawierać następujące akapity:

ARP (dokumentacja na temat raportów)

Dokumentacja ta, która tworzona jest w katalogu OBJ, może zawierać następujące akapity:

AWA (dokumentacja na temat Workflow)

Dokumentacja ta, która tworzona jest w katalogu OBJ, może zawierać następujące akapity:

CDE (dokumentacja na temat kodów analityki)

Dokumentacja ta, która tworzona jest w katalogu OBJ, może zawierać następujące akapity:

CDA (dokumentacja na temat miejsc docelowych)

Dokumentacja ta, która tworzona jest w katalogu OBJ, może zawierać następujące akapity:

GAU (dokumentacja na temat automatów księgujących)

Dokumentacja ta, która tworzona jest w katalogu OBJ, może zawierać następujące akapity:

PS1 (dokumentacja na temat wyzwalania statystyk)

Dokumentacja ta, która tworzona jest w katalogu OBJ, może zawierać następujące akapity:

ATB (słownik dla tabel)

Występuje tylko jeden akapit dla tego typu dokumentacji, który jest tworzony w katalogu MCD:

AML (słownik dla menu lokalnych)

Występuje tylko jeden akapit dla tego typu dokumentacji, który jest tworzony w katalogu MCD:

ATY (słownik dla typów danych)

Występuje tylko jeden akapit dla tego typu dokumentacji, który jest tworzony w katalogu MCD:

ADC (słownik dla entry points)

Dokumentacja ta, która tworzona jest w katalogu OBJ, może zawierać następujące akapity:

ASU (dokumentacja na temat podprogramów)

Dokumentacja ta, która tworzona jest w katalogu OBJ, może zawierać następujące akapity:

Uwzględniane akapity PRE:

• jego zawartość może być bezpośrednio przeglądana w katalogu podprogramów i może on być modyfikowany z poziomu tego katalogu.
• domyślny tekst zostaje wygenerowany w akapicie, jeśli jest on pusty. Tekst ten wskazuje, że jest to wewnętrzny podprogram, które nie będzie używany w określonym rozwiązaniu.

AGB (dokumentacja na temat zmiennych)

Dokumentacja ta, która tworzona jest w katalogu OBJ, może zawierać następujące akapity:

Uwzględniane akapity PRE:

• jego zawartość może być bezpośrednio przeglądana w katalogu zmiennych i może on być modyfikowany z poziomu tego katalogu.
• domyślny tekst zostaje wygenerowany w akapicie, jeśli jest on pusty. Tekst ten wskazuje, że jest to wewnętrzna zmienna, które nie będzie używana w określonym rozwiązaniu.

APM (menu pośrednie)

Ten typ dokumentacji jest używany w dwóch przypadkach:

• gdy funkcja typu „Menu” istnieje, generowanie powoduje utworzenie dokumentacji typu APM, tylko z jednym akapitem typu TIT. Ostateczne generowanie wyszukuje listę funkcji powiązanych z menu, aby wyszczególnić odpowiednie funkcje. W tym szczególnym przypadku, powiązania można dodawać bezpośrednio w akapicie (składnia taka sama, jak w przypadku akapitów LNK), aby dodawać pozycje menu poniżej tych, które zostały znalezione w dowolnym miejscu słownika.
• wszystkie pośrednie menu, powiązane z dodatkowymi dokumentami (kody czynności, zdarzenie Workflow, itd.), są typu APM, z nazwą rozpoczynającą się kodem powiązanym z typem dokumentu, po którym występuje znak „_” oraz kwalifikator (moduł, grupa), jeśli konieczne jest posiadanie dostępnych pośrednich menu, menu głównego posiadającego kod TYPE_0. Na przykład:
• pośrednie menu, powiązane z kodami czynności, są następujące: ACV_0 (źródło), ACV_1 (kody czynności powiązane z numerem modułu 1, ACV_2, itd.
• pośrednie menu, powiązane z ustawieniami, są następujące: ADP_0 (źródło), ADP_TC (ustawienia kategorii TC), ADP_SUP (ustawienia kategorii SUP), itd.

Należy zauważyć, że tworzenie innych dokumentów umożliwiające posiadanie pośrednich menu musi być wykonane w postaci dokumentu typu DI z następującymi akapitami: akapit TIT w pozycji (10,10), akapit PRE w pozycji (10,20), który może być pusty, możliwie pierwszy akapit LNK w wierszu (10,30), aby wprowadzać powiązania nawigacyjne w pasku tytułu, a także akapit LNK z wierszem większym lub równym 20, aby wyszczególniać pozycje powiązań menu.

AD (pomoc on-line dla języka)

Ten typ dokumentacji jest tworzony w katalogu 4GL: Dokumentacja ta ma swobodną strukturę. Jedynie obowiązkowym akapitem jest:

Gdy jest to jedyny akapit, nie można wygenerować żadnego pliku powiązanego z rekordem, a jedynie powiązany plik, o ile istnieje, może być poddany ekstrakcji pod nazwą dokumentacji. Ta funkcjonalność ma zapewnić pełne pozyskiwanie istniejących dokumentów 4GL, a każdy z dokumentów widziany jest jako plik w bazie.

Jeżeli istnieje więcej niż jeden akapit (szczególnie podczas dodawania akapitów typu MIS lub MIN), dokumentacja jest tworzona zgodnie z typowymi zasadami.

Należy zauważyć, że dokumentacja, dla której kod zakończony jest znakami „_D”, jest tworzona z plikiem, który zakończony jest znakiem „$”. W rzeczy samej, aby zapobiec tworzeniu kluczy zawierających znaki specjalne, zastosowanie ma ta reguła zmiany nazw. Dlatego też, funkcje seg$, chr$ oraz getenv$ są reprezentowane przez rekordy SEG_D, CHR_D oraz GETENV_D.

FI (pliki, które mają być objęte ekstrakcją)

Jest to szczególny typ: jest to jedynie etykieta dla plików, które mają być objęte ekstrakcją. Zasady nazewnictwa są następujące:

• dokumentacja typu FI oraz kod XXXXX_nnn jest etykietą dla plików do ekstrakcji w katalogu XXXXX (dowolny standardowy katalog może być określany w ten sposób). Możliwe jest tworzenie tylu akapitów, ile jest wymaganych, aby określać np. różne grupy plików.
• dokumentacja _nnn jest etykietą dla plików do ekstrakcji we wszystkich katalogach XXXXX, dla których istnieje dokument typu FI z kodem XXXXX_nnn. Zasadniczo, podczas generowania dokumentów typu FI oraz z kodem XXXXX_nnn, dostępna jest kontrola, podczas której weryfikowane jest, czy występują akapity tego samego poziomu i podpoziomu w odpowiedniej dokumentacji typu FI i z kodem _nnn (numer musi być taki sam). Jeżeli występują, pliki te podlegają ekstrakcji w pierwszej kolejności. Pliki powiązane z dokumentem z kodem XXXXX_nnn mogą być poddane ekstrakcji jedynie w dalszej kolejności. Dlatego możliwe jest definiowanie w takim dokumencie wspólnych plików, z czego niektóre z nich mogą być nadpisywane podczas ekstrakcji odpowiednimi dokumentami z kodem XXXXX_nnn.
• dokumentacja typu FI oraz kod „_” (tylko jeden znak „podkreślenia”) jest etykietą dla plików, których generowanie wyzwala tworzenie plików w katalogu źródłowym plików pomocy. Podczas generowania dokumentów, wszystkie pliki podłączone do dokumentacji typu FI oraz z kodem _nnn objęte są ekstrakcją, jeśli pierwszą cyfrą kodu jest 0 (i jeśli poziom i podpoziom są odpowiednie).

Pozostałe typy dokumentów

Inne typy dokumentów (DI, IN, CS, DL, AM) są dokumentami, które nie posiadają zdefiniowanej struktury (ale dal których zdefiniowane są katalogi generowania w odniesieniu do typu). Jedynym obowiązkowym akapitem jest TIT.

Gdy jest to jedyny akapit, nie można wygenerować żadnego pliku powiązanego z rekordem, a jedynie powiązany plik, o ile istnieje, może być poddany ekstrakcji pod nazwą dokumentacji.

Jeżeli istnieje więcej niż jeden akapit (szczególnie podczas dodawania akapitów typu MIS lub MIN), dokumentacja jest tworzona zgodnie z typowymi zasadami.

Katalogi generowania są wyszczególniane w poniższej tabeli:

Tabele zawartości dokumentacji

Tabele zawartości, tworzące dokumentację, są powiązane z dokumentacją typu APM. W tym przypadku jest to zazwyczaj tylko jeden akapit:

Akapit może zawierać listę kodów dokumentów w postaci tekstowej. W tym przypadku, każda pozycja listy jest dodawana jako złącze do przedmiotowej dokumentacji (tytuł powiązanej dokumentacji, który jest ponownie używany w przedmiotowej dokumentacji). Umożliwia to tworzenie tabel zawartości w sposób ręczny, bądź dodawanie dodatkowych powiązań do istniejącej tabeli zawartości.

W rzeczy samej, podczas generowania dokumentacji z katalogu, dokumenty typu APM są generowane automatycznie jedynie z akapitem TIT. Tabela przedstawiona poniżej opisuje kodu utworzonych dokumentów oraz tabele zawartości, generowane w dokumentach tworzonych podczas ostatecznego generowania:

Dla wszystkich typów dokumentów, innych niż te, które wyszczególnione są powyżej, możliwe jest tworzenie dokumentacji, dla której kodem jest INDEX. Jeżeli taka dokumentacja istnieje, tworzone jest łącze bezpośrednio z każdego dokumentu tego typu na pasku tytułu. Na przykład, dokumentacja typu IN, DL używa indeks tego typu.