# Dokumentation: Fachliche Prozesse der Legacy-PHP-Anwendung

Stand: 2026-03-31

## 1. Ziel und Leselogik

Dieses Dokument beschreibt die produktiv erreichbaren fachlichen Prozesse der Legacy-PHP-Anwendung unter `html/`.

Der Aufbau ist bewusst fuer fachliche Leser optimiert. Jeder fachliche Vertikalschnitt folgt derselben Reihenfolge:

1. Was passiert fachlich?
2. Was muss der Benutzer tun, um den Schritt erfolgreich abzuschliessen?
3. Welche Eingabefelder sind zu fuellen?
4. Woher kommen die Daten?
5. Was passiert mit den Daten?
6. Wohin werden die Daten geschrieben?
7. Wodurch wird der Ablauf gesteuert?

Die Beschreibung basiert auf den real erreichbaren Legacy-Pfaden und den zentralen Includes, insbesondere:

- `index.php`, `admin/start.php`, `admin/menu.php`
- `include/auth.inc.php`, `include/dbglobal.inc.php`, `include/mcglobal.inc.php`, `include/caglobal.inc.php`
- `html/index_php_reachable_paths.txt`, `html/index_php_call_graph.txt`
- `MIGRATION_BACKLOG.md`, `LEGACY_SIDEPATH_AUDIT.md`

Nicht im Fokus stehen rein technische Drittbibliotheken unter `lib/`, `PEAR_XXXX/`, `js/`, `css/` sowie bewusst archivierte Altpfade ohne regulaeren Fachzugriff.

---

## 2. Systemrahmen

### 2.1 Einstieg und organisatorischer Kontext

Die Anwendung startet ueber `index.php` und leitet auf `admin/start.php` weiter. Fachlich ist das System ein Multi-Tenant-Portal mit gemeinsamem Code, aber HQ-bezogener Daten- und Parametersteuerung.

Zentrale fachliche Scope-Felder:

- `md_id`: Mandant
- `hq_id`: Niederlassung / Standort
- `emp_id`: Mitarbeiterkontext
- `usr_type`: Benutzertyp

Benutzertypen:

| `usr_type` | Rolle | Hauptprozesse |
|---|---|---|
| `1` | HQ-Benutzer | Verwaltung, Auftraege, Listen, Rechnungen, Vertrieb, Nachrichten, Datentransfer, Statistik, Formulare |
| `2` | Kundenbenutzer | Kostenstellen, Auftragserfassung, Auftragslisten, Datenexport, Statistik, Rechnungen |
| `3` | Kurierbenutzer | Eigene Auftraege, Passwort, mobile Kommunikation |
| `4` | Lagerbenutzer | Lagerverwaltung |

### 2.2 Parameter- und Konfigurationslogik

Die zentrale Steuerung liegt in der Tabelle `parameter` und in den Funktionen aus `include/dbglobal.inc.php`.

Wesentliche Zugriffsfunktionen:

- `getParameterArray($empId, $hqId)`
- `defineGlobalParameters($hqId)`
- `getParameterValue($empId, $key, $hqId)`
- `getObjectBasedParameterValue($key, $objId, ...)`
- `setParameterValue(...)`

Typische Parameterfamilien:

- `MASK_*`: Masken-, Anzeige- und Prozesssteuerung
- `CUSTOMER_*`, `CS_*`: Kundenlogik
- `CR_*`, `CRVH_*`: Kurier- und Fahrzeuglogik
- `RANKING_*`, `AUTORANKING_*`, `LONGHAUL_*`: Disposition
- `EXPORT_*`, `FTP_*`, `DATATRANSFER_*`: Export und Datentransfer
- `MAIL_*`, `AUTOMAILER_*`: Mail- und Versandlogik
- `LOCATING_*`, `GEO_*`, `PZM_*`: Geocoding, Ortung und Routing

Viele Regeln liegen nicht als feste Tabellenfelder, sondern als dynamische Parameterschluessel vor, zum Beispiel:

- `CUSTOMER_MASK_JOBLIST_CANCELLATION_ENABLED_<cs_id>`
- `ORDER_REQUEST_VHT_ID_DEFAULT_<cs_id>`
- `TRACKING_ENABLED_CS_<cs_id>`
- `EXPORT_SPECIAL_FUNCTIONNAME_SUFFICES_CS_<cs_id>`

### 2.3 Zentrale Datenbereiche

| Bereich | Typische Tabellen / Schemas |
|---|---|
| Benutzer und Organisation | `user`, `employee`, `headquarters`, `mandatorheadquarters`, `company`, `rights`, `employeerights` |
| Kunden und Kostenstellen | `customer`, `costcenter`, `costcenteraddress`, `customercourier` |
| Transporteure und Fahrzeuge | `courier`, `couriervehicle`, `messagegroup` |
| Auftraege | `job`, `tour`, `tourservice`, `jobprice`, `invoice`, `jobbatch`, `jobbatchlist` |
| Preise und Services | `service`, `servicetype`, `servicehistory`, `servicecustomer`, `serviceplz*`, `serviceplzarea*`, `serviceradius`, `servicezone*` |
| Kommunikation und Vertrieb | `phoenix_group.appointment`, `phoenix_group.report_process`, `phoenix_group.tickerforum`, `phoenix_log.messageforum` |
| Logging und technische Steuerung | `phoenix_log.log`, `phoenix_log.semaphor`, `phoenix_log.locating`, `phoenix_log.route`, `phoenix_pda.commandexec` |
| Flexible Zusatzdaten | `genericdatacontainer`, `metafield*`, `metatype` |
| Geo- und Adressdaten | `address`, `phoenix_special.street`, `address_geo.address_geo`, `address_geo.distance`, `serviceplztraveltime`, `publicholiday` |
| Lager | `stock`, `stockarticle`, `article`, `articlegroup*`, `articleitem`, `stockmove` |
| Externe Identitaeten | `meta_object.metaobject` |

### 2.4 Dateibasierte Speicherorte

Neben der Datenbank nutzt die Anwendung mehrere fachlich relevante Verzeichnisse:

- `html/import/upload/`: Uploads und Importstaging
- `html/export/download/`: erzeugte Exporte
- `html/temp/download/`: temporaere Downloads
- `html/temp/pdf/`: PDF-Zwischenablage
- `html/temp/photos/`: Stations- und POD-Fotos
- `html/temp/signs/`: Signaturen
- `html/images/external/`: Logos und externe Bilder
- `html/log/`: XML-, Prozess-, Export- und Mail-Logs

---

## 3. Fachliche Vertikalschnitte

### 3.1 Authentifizierung, Session und Startseite

#### Was passiert?

Benutzer melden sich an, werden einem HQ- und Mitarbeiterkontext zugeordnet, durchlaufen bei Bedarf 2FA und landen anschliessend auf einer rollenabhaengigen Startseite.

#### Was muss der Benutzer tun, um den Schritt erfolgreich abzuschliessen?

- gueltige Zugangsdaten eingeben
- den richtigen Benutzer- und HQ-Kontext verwenden
- bei aktivierter 2FA den Code bestaetigen
- einen geforderten Passwortwechsel oder Reset vollstaendig abschliessen

#### Welche Eingabefelder sind zu fuellen?

- Benutzerkonto oder Anmeldename (`f_chk_account`)
- Passwort (`f_chk_password`)
- bei SSO-Faellen die Kontoauswahl (`sso_selected_account`)
- bei aktivierter Zusatzsicherung 2FA-Code oder Geraetebestaetigung

#### Woher kommen die Daten?

- aus `user`, `employee`, `headquarters`, `mandatorheadquarters`
- aus `parameter` fuer Login- und Spracheinstellungen
- aus `genericdatacontainer` fuer Passwortwechselpflicht
- aus den HTTP-Parametern und der PHP-Session

#### Was passiert mit den Daten?

- Zugangsdaten werden geprueft.
- HQ, `emp_id`, `usr_type` und Mandant werden aufgeloest.
- Sessiondaten werden aufgebaut oder verworfen.
- TOTP-Status wird geprueft.
- Bei Passwort-Reset wird ein Einmalpasswort erzeugt und per Mail versendet.
- Die Startseite liest Geburtstage, offene Mitteilungen, Reporthinweise und Suchdaten nur zur Anzeige aus.

#### Wohin werden die Daten geschrieben?

- in die PHP-Session
- bei Passwort-Reset nach `user.usr_password` und `user.usr_password_modify`
- indirekt in Mailversand und Mail-Logs

#### Wodurch wird der Ablauf gesteuert?

- `LOGIN_FORGOT_PASSWORD_ENABLED`
- `MAXIMUM_LOGIN_TRIALS`
- `SYSTEM_LANGUAGE_DEFAULT`
- `HEADQUARTERS_MULTIPLE_ACCESS_EMPLOYEES`
- `HTTP_VARS_SEC_STATE`
- `HTTP_VARS_SEC_SEQ`

### 3.2 HQ-, Mitarbeiter- und Rechteverwaltung

#### Was passiert?

HQ-Benutzer, Kundenbenutzer und Lagernutzer werden angelegt, gepflegt und mit Rechten, HQ-Freigaben, Kostenstellenrechten, Lagerrechten und individuellen Maskeneinstellungen versehen.

#### Was muss der Benutzer tun, um den Schritt erfolgreich abzuschliessen?

- Benutzerkonto und Mitarbeiterstammdaten vollstaendig erfassen oder oeffnen
- den richtigen Benutzertyp festlegen
- Rechte, HQ-Freigaben, Kostenstellen- und Lagerzugaenge passend setzen
- Aenderungen speichern und bei Bedarf Passwort oder 2FA-Status initialisieren

#### Welche Eingabefelder sind zu fuellen?

- HQ-, Mitarbeiter- und Benutzerkontext (`f_hq_id`, `emp_id_act`, Benutzertyp)
- Name, Vorname, E-Mail, Telefon, Zusatztelefon und Geburtsdatum (`usr_name`, `usr_firstname`, `usr_email`, `usr_phone`, `usr_phone2`, `f_usr_birthdate_*`)
- Benutzerkonto, Passwort und Passwortwiederholung (`usr_account`, `usr_password`, `usr_password2`)
- Rechte-, HQ-, Kostenstellen-, Lager- und Listenparameter (`emp_rights`, `par_*`, `par_stock_access`)

#### Woher kommen die Daten?

- aus `user`, `employee`, `headquarters`, `rights`, `employeerights`, `costcenter`
- aus `parameter` fuer Layout-, Listen- und Lagerkonfiguration
- aus `meta_object.metaobject` fuer externe Objektkopplungen

#### Was passiert mit den Daten?

- Benutzerkonten und Mitarbeiterdatensaetze werden erstellt oder geaendert.
- Passwortaenderungen werden ausgefuehrt.
- HQ-Freigaben und Rechtebits werden gesetzt.
- Lagerzugriffe und Kostenstellenzugriffe werden auf Mitarbeiterebene verdrahtet.
- Mitarbeiterbezogene Listen- und Maskenparameter werden gesetzt.

#### Wohin werden die Daten geschrieben?

- nach `user`
- nach `employee`
- nach `employeerights`
- nach `parameter`
- nach `meta_object.metaobject`

#### Wodurch wird der Ablauf gesteuert?

- `EMP_BITSTR_MAXLEN`
- `MASK_EMP_CSC_MATRIX_ENABLED`
- `GLOBAL_CUSTOMER_READONLY_DISABLED`
- `USERTYPE_2FA_ENABLED`
- `USER_2FA_NO_DEACTIVATION`
- `HEADQUARTERS_MULTIPLE_ACCESS_EMPLOYEES`
- `MASK_JOBLIST_*`
- `MASK_CS_LIST_*`
- `MASK_CR_LIST_*`
- `MASK_STK_*`
- `LOCATING_PDA_ENABLED`
- `LOCATING_PDA_INTERVAL`

### 3.3 Kundenstammdaten, Kostenstellen und Kundenspezifika

#### Was passiert?

Kundenfirmen, Kunden, Root- und Unterkostenstellen, Rechnungs- und Lieferadressen sowie kundenspezifische Verhaltensregeln werden gepflegt. Ausserdem werden bevorzugte Kuriere und Servicezuordnungen hinterlegt.

#### Was muss der Benutzer tun, um den Schritt erfolgreich abzuschliessen?

- Firma, Kunde und Kostenstelle im richtigen organisatorischen Kontext anlegen oder auswaehlen
- Pflichtdaten wie Namen, Kennungen, Kontakt- und Adressdaten vollstaendig pflegen
- Rechnungs-, Liefer- und Abrechnungsbezug korrekt zuordnen
- kundenspezifische Regeln, Favoritenkuriere und Services speichern

#### Welche Eingabefelder sind zu fuellen?

- Firmenname, Zusatznamen und Identifikatoren (`f_cmp_comp`, `f_cmp_comp2`, `f_cmp_comp3`, `f_cmp_comp4`, `f_cs_eid_old`)
- Ansprechpartner-, Login- und Kommunikationsfelder (`f_usr_name`, `f_usr_firstname`, `f_usr_email`, `f_usr_phone`, `f_usr_phone2`, `f_usr_fax`, `f_usr_inv_email`, `f_usr_reminder_email`, `f_usr_account`)
- Steuer-, Bank- und Zahlungsfelder (`f_cmp_tax_idno`, `f_cmp_stax_idno`, `f_cmp_bank*`, `f_cmp_iban`, `f_cmp_swift`, `f_cmp_bankmode`)
- Adressfelder fuer Haupt-, Rechnungs-, Leistungs- und Abhol-/Lieferadressen (`f_ad_street`, `f_cmp_hsno`, `f_ad_zipcode`, `f_ad_city`, `f_ad_country`, `f_cscad_*`)
- Kundenoptionen wie Tracking, Statusmail, Foto, Newsletter, DSGVO, POD und Zeitsteuerung (`f_cs_tracking[]`, `f_cs_jbstatusmail*`, `f_cs_photo_*`, `f_cmp_newsletter`, `f_cmp_dsgvo`, `f_cmp_proof_delivery`, `f_cs_charging_time`)

#### Woher kommen die Daten?

- aus `company`, `customer`, `costcenter`, `costcenteraddress`, `address`
- aus `customercourier`
- aus `service`, `servicetype`, `customerservice`, `customerservicetype`
- aus `serviceradius`, `servicezone`, `servicezonemapping`
- aus `genericdatacontainer`
- aus `parameter`

#### Was passiert mit den Daten?

- Firmen- und Kundendaten werden validiert.
- Root- und Unterkostenstellen werden erzeugt oder geaendert.
- Rechnungs- und Lieferadressen werden auf bestehende Adressen gemappt oder neu angelegt.
- Kundenspezifische Regeln fuer Joblisten, Tracking, Mailsprache, Standardpreisunterdrueckung und Self-Service-Verhalten werden gepflegt.
- Favoritenkuriere und Services werden dem Kunden zugeordnet.

#### Wohin werden die Daten geschrieben?

- nach `user`
- nach `employee`
- nach `company`
- nach `customer`
- nach `costcenter`
- nach `costcenteraddress`
- nach `customercourier`
- nach `customerservice`
- nach `customerservicetype`
- nach `genericdatacontainer`
- bei externer Kopplung nach `meta_object.metaobject`

#### Wodurch wird der Ablauf gesteuert?

- `CS_EID_PREFIX`
- `CS_PHONE_MINIMUM_LENGTH`
- `CS_TRACKING_ENABLED`
- `MASK_CS_SPECIAL_TAX_IDS_CHANGE_MSG`
- `CS_JB_JAM_WAITTIME_*`
- `MASK_CS_NEW_SIMILARITY_SEARCH`
- `MASK_CS_CHECK_INTERNAL_BOOKING_ACCOUNT`
- `MASK_CS_PROV_RANGE_*`
- `MASK_CS_SHOW_LAST_JOB`
- `CUSTOMER_MASK_JOBLIST_*`
- `CUSTOMER_MASK_CALCULATOR_USAGE_ONLY_<cs_id>`
- `MASK_CS_DONT_MAKE_STANDARD_PRICE_<cs_id>`
- `JOBDETAILS_EMAIL_LANGUAGE_<cs_id>`
- `JOB_MAIL_STATION_ARRIVAL_TIME_<cs_id>`

### 3.4 Kundenservice-Konfiguration: Delivery Reasons und Acceptance Protocols

#### Was passiert?

Pro Kunde und Service werden mobile Abliefergruende, Codes, Mailregeln, Fragen fuer Abnahmeprotokolle und Textbausteine gepflegt.

#### Was muss der Benutzer tun, um den Schritt erfolgreich abzuschliessen?

- den richtigen Kunden und den betroffenen Service auswaehlen
- Abliefergruende, Codes und Textbausteine fachlich vollstaendig pflegen
- Fragen und Mailstatus fuer das Abnahmeprotokoll definieren
- die Konfiguration speichern und je Service pruefen

#### Welche Eingabefelder sind zu fuellen?

- Kunden- und Serviceauswahl
- Abliefercode und Abliefergrund je Zeile (`f_code_XX`, `f_reason_XX`)
- Mailkennzeichen je Grund oder Frage (`f_mail_XX`)
- Fragen des Abnahmeprotokolls (`f_question_XX`)
- Freitextbausteine fuer Delivery Reasons und Acceptance Protocols

#### Woher kommen die Daten?

- aus `genericdatacontainer`
- aus `metatype` fuer die Serviceauswahl
- aus Formulardaten der Admin-Masken

#### Was passiert mit den Daten?

- Abliefergruende werden je Liste oder Service gesammelt.
- Fragen und Mailstatus fuer Abnahmeprotokolle werden je Service verdichtet.
- Texte werden nicht als einzelne Tabellenfelder, sondern als serialisierte Objektzusaetze abgelegt.

#### Wohin werden die Daten geschrieben?

- nach `genericdatacontainer`

Verwendete `gdc_gen_fieldname`-Werte:

- `service_delivery_reasons`
- `service_delivery_reasons_mail_state`
- `service_delivery_reasons_text`
- `service_acceptance_protocol_questions`
- `service_acceptance_protocol_mail_state_question`
- `service_acceptance_protocol_text`

#### Wodurch wird der Ablauf gesteuert?

- `CUSTOMER_SERVICE_DELIVERY_REASONS`
- die allgemeine Kundenservice-Konfiguration des Kunden

### 3.5 Transporteur-, Fahrer- und Fahrzeugstammdaten

#### Was passiert?

Transporteur-Firmen, Fahrerkonten, Fahrzeugstammdaten, mobile Geraetemerkmale, Nachrichtengruppen und Kundenzuordnungen werden gepflegt.

#### Was muss der Benutzer tun, um den Schritt erfolgreich abzuschliessen?

- Transporteur, Fahrer oder Fahrzeug im richtigen Pflegebereich auswaehlen oder neu anlegen
- Kennungen, Accountdaten, Fahrzeugmerkmale und mobile Eigenschaften vollstaendig erfassen
- Kundenzuordnungen und Nachrichtengruppen fachlich passend hinterlegen
- die Stammdaten speichern und bei Bedarf Dokumentbezug oder Lagerbezug ergaenzen

#### Welche Eingabefelder sind zu fuellen?

- Transporteurstammdaten wie Firmenname, EID/SID, Vertragsdatum und Bemerkungen (`f_cmp_comp*`, `f_cr_eid`, `f_cr_sid`, `f_cmp_contract_date_*`, `f_cmp_remark*`)
- Fahrer- und Loginfelder (`f_usr_name`, `f_usr_firstname`, `f_usr_country`, `f_usr_phone*`, `f_usr_email`, `f_usr_inv_email`, `f_usr_account`, `f_usr_password*`, `f_usr_birthdate_*`)
- Adress-, Bank- und Steuerfelder (`f_ad_*`, `f_cmp_hsno`, `f_cmp_bank*`, `f_cmp_iban`, `f_cmp_swift`, `f_cmp_tax_idno`, `f_cmp_stax_idno`)
- Mobile und Verfuegbarkeitsfelder (`f_cr_imei`, `f_cr_serialno`, `f_cr_mobile_pda`, `f_cr_disposition[]`, `f_cr_price_show[]`, `f_cr_app_blocked[]`, `f_cmp_no_longhaul[]`)
- Fahrzeug- und Beziehungsfelder wie Typ, SID, Kennzeichen, Masse, Versicherungen, Partnerkonditionen und Kundenrelation (`f_vht_id`, `f_crvh_sid`, `f_crvh_vh_sign`, `f_crvh_payload`, `f_crvh_totalweight`, `f_crvh_length`, `f_crvh_width`, `f_crvh_height`, `f_crvh_*insurance*`, `f_crvh_partner_*`, `f_cscr_description_new`, `f_relationStatus`, `f_msggrp`)

#### Woher kommen die Daten?

- aus `company`, `courier`, `couriervehicle`, `user`, `address`
- aus `customercourier`
- aus `messagegroup`
- aus `stock`
- aus `genericdatacontainer`
- aus `parameter`

#### Was passiert mit den Daten?

- neue Fahrer und Transporteurkonten werden erzeugt
- EID, SID und Accountdaten werden validiert
- Fahrzeuge werden mit Typ, Groessen, Provisionen und Dokumentbezug gepflegt
- Nachrichtengruppen werden einem Kurier zugeordnet
- Kunden und Transporteure werden als Favoritenbeziehung verdrahtet

#### Wohin werden die Daten geschrieben?

- nach `user`
- nach `company`
- nach `courier`
- nach `couriervehicle`
- nach `customercourier`
- nach `courier.cr_msggrp`
- indirekt in Uploadverzeichnisse fuer Fahrzeugdokumente

#### Wodurch wird der Ablauf gesteuert?

- `CR_EID_PREFIX`
- `CR_SID_PREFIX`
- `MASK_COURIER_EID_LENGTH`
- `MASK_COURIER_EID_MAX_LENGTH`
- `MASK_CR_MOBILE_PDA_EDIT`
- `MASK_HIDE_CR_VHT_INV`
- `MASK_CR_CARTAGE_LINKS_DISABLED`
- `GLOBAL_VEHICLE_COURIER_RELATION`
- `GLOBAL_VEHICLE_STOCK_RELATION`
- `VEHICLE_STOCK_PARENT_ID`
- `MASK_CRVH_TOTALWEIGHT_MANDATORY`
- `MASK_CRVH_PARTNER_PROV_RANGE_*`
- `DATATRANSFER_DIRECTORY_CRVH`
- `DPF_CR_ENABLED`
- `MASK_EXCLUDE_VHT_IDS`

### 3.6 Service-, Preis-, Rabatt- und Gebietsverwaltung

#### Was passiert?

Standardpreise, kundenbezogene Preise, Kurierpreise, Rabatte, PLZ-Matrizen, Bereichsmatrizen und Nachbargebiete werden gepflegt. Diese Stammdaten sind die Basis fuer die operative Preisfindung im Auftrag.

#### Was muss der Benutzer tun, um den Schritt erfolgreich abzuschliessen?

- den richtigen Service, Kundenbezug oder Gebietsbezug auswaehlen
- Preis-, Rabatt- oder Gebietszeilen mit allen Pflichtwerten erfassen
- Gueltigkeiten, Historie und Fahrzeugtypbezug korrekt pflegen
- die Pflege speichern und die betroffene Preislogik fachlich gegenpruefen

#### Welche Eingabefelder sind zu fuellen?

- Gueltigkeitsdatum und Arbeitsmodus (`day_from`, `month_from`, `year_from`, Preis-/Rabattmodus)
- Service- und Servicetyppflege (`f_service_id`, `f_service_new`, `f_servicetype_id`, `f_servicetype_new`)
- Preis- und Rabattmatrix je Service/Servicetyp (`service_<srv>_<srvt>`, `service_cr_<srv>_<srvt>`)
- Kundenservices, Zeitfenster und Rabattmodi (`f_cs_service[]`, `f_cs_servicetype[]`, `f_day_time_*`, `f_delivery_time_*`, `f_sms_time_*`, `f_cartage_time_*`, `f_discount_mode_*`)
- Radius-, PLZ- und Zonenfelder (`f_radius_zipcode_new`, `f_radius_district_new`, `f_radius_zone_new`, `f_zone_name_new`, `f_zone_zipcode_new`, `f_zone_zone_new`)

#### Woher kommen die Daten?

- aus `service`, `servicetype`
- aus `servicehistory`, `servicecustomer`
- aus `serviceplz`, `serviceplzhistory`, `serviceplzcustomer`, `serviceplzneighbour`
- aus `serviceplzarea`, `serviceplzareahistory`, `serviceplzareacustomer`, `serviceplzareamapping`, `serviceplzareaneighbour`
- aus `serviceradius`
- aus `parameter` und `metatype`

#### Was passiert mit den Daten?

- Preis- und Rabattzeilen werden gelesen, geaendert oder neu historisiert.
- Kundenoverrides werden getrennt von der allgemeinen Historie gepflegt.
- PLZ- und Bereichszuordnungen werden fuer die spaetere Preisaufloesung vorbereitet.
- Fahrzeugtyp-Mapping und Nachbarrelationen beeinflussen die spaetere Preis- und Dispositionslogik.

#### Wohin werden die Daten geschrieben?

- nach `servicehistory`
- nach `servicecustomer`
- nach `serviceplzhistory`
- nach `serviceplzcustomer`
- nach `serviceplzneighbour`
- nach `serviceplzareahistory`
- nach `serviceplzareacustomer`
- nach `serviceplzareamapping`
- nach `serviceplzareaneighbour`
- nach `serviceradius`

#### Wodurch wird der Ablauf gesteuert?

- `MANDATOR_SERVICE_ENABLED`
- `MANDATOR_SERVICE2_ENABLED`
- `SERVICE_DISPLAY_MODE_DEFAULT`
- `SERVICE_VEHICLE_TYPE_ENABLED`
- `RIGHTS_TABLE_SERVICE`
- `MASK_EXCLUDE_VHT_IDS`
- `CUSTOMER_SERVICE_RADIUS_INTERVALS_<cs_id>`

### 3.7 Adress-, Geo-, Feiertags-, Anfahrtszeit-, Gruppen-, Filter- und Formularpflege

#### Was passiert?

Stammadressen, Strassenkatalog, Fahrzeiten je PLZ und HQ, Feiertage, Gruppenkataloge, Kurierfilter und dynamische Formulare werden gepflegt.

#### Was muss der Benutzer tun, um den Schritt erfolgreich abzuschliessen?

- den passenden Pflegebereich fuer Adresse, Fahrzeit, Feiertag, Gruppe, Filter oder Formular oeffnen
- die Stammdaten mit eindeutigen und vollstaendigen Werten erfassen oder bereinigen
- bei Filtern und Formularen die spaetere Nutzung fuer Kunden, Kuriere oder Fahrzeuge beachten
- Aenderungen speichern und bei Filterloeschungen die Folgen fuer bestehende Zuordnungen pruefen

#### Welche Eingabefelder sind zu fuellen?

- allgemeine Adressfelder wie Strasse, Hausnummer, PLZ, Ort und Land
- Fahrzeitfelder je Start-/Ziel-PLZ oder Matrixzelle (`zipcodeFrom`, `zipcodeTo`, `f_<plz>`)
- Feiertagsfelder wie Datum, Zeitraum und Bezeichnung (`f_year`, `f_month`, `f_day`, `f_time_from`, `f_time_to`)
- Filterfelder (`f_crf_type`, `f_crf_status`, `f_crf_short`, `f_crf_text`, `f_crf_sort`)
- Metafeld- und Formularfelder (`f_mtfc_mnemonic`, `f_mtfc_description`, `f_mtfk_type`, `f_mtfk_name`, `f_mtft_name`, `f_filter_mtfk_name`)

#### Woher kommen die Daten?

- aus `address`
- aus `phoenix_special.street`
- aus `serviceplz`, `serviceplztraveltime`
- aus `publicholiday`
- aus `groups`, `courierfilter`
- aus `metafieldcategory`, `metafieldkey`, `metafieldtemplate`, `metafieldcategorykey`, `metafieldvalue`
- aus `customer`, `courier`, `company`

#### Was passiert mit den Daten?

- Adressen und Strassen werden angelegt, bereinigt oder gesucht.
- Anfahrtszeiten werden HQ-bezogen gepflegt.
- Feiertage werden jahresbezogen gepflegt.
- Gruppen und Filter werden als Stammdaten fuer andere Module bereitgestellt.
- Metafeldkategorien, Templates und Werte definieren flexible Formulare und Sondermasken.
- Beim Loeschen von Filtern werden bestehende Kunden-, Kurier- und Fahrzeugzuordnungen bereinigt.

#### Wohin werden die Daten geschrieben?

- nach `address`
- nach `serviceplztraveltime`
- nach `publicholiday`
- nach `groups`
- nach `courierfilter`
- nach `metafieldcategory`
- nach `metafieldkey`
- nach `metafieldtemplate`
- nach `metafieldcategorykey`
- nach `metafieldvalue`
- bei Filterbereinigung zusaetzlich nach `customer.cs_filter`, `courier.cr_filter`, `couriervehicle.crvh_filter`

#### Wodurch wird der Ablauf gesteuert?

- `MASK_ZIP_CHK_SYNTAX_DISABLED`
- `FILTER_TO_BE_DELETED`
- `MASK_CONTACT_*`
- `MTFC_TPL_MODE`
- `MASK_FORMS_CR`
- `SIMILARITY_SEARCH_FILTER_HQ`

### 3.8 Auftragserfassung, Auftragsaenderung und Batch-Erfassung

#### Was passiert?

Auftraege werden einzeln oder als Batch angelegt, geaendert, storniert, kopiert oder als Kinder-/Kettenauftrag fortgeschrieben. Dabei werden Stationen, Services, Preise, Artikel, Zahler und Status verdrahtet.

#### Was muss der Benutzer tun, um den Schritt erfolgreich abzuschliessen?

- Auftraggeber, Kostenstelle und Abrechnungsbezug korrekt auswaehlen
- alle benoetigten Stationen, Zeiten, Services, Artikel und Zusatzinformationen erfassen
- Pflichtpruefungen fuer Adresse, Preis, Zahlart und Status aufloesen
- den Auftrag speichern und bei Bedarf direkt disponieren, kopieren oder als Batch verarbeiten

#### Welche Eingabefelder sind zu fuellen?

- Auftraggeber- und Zahlerfelder (`csc_id_orderer`, `csc_id_payer`, `jb_orderer`, `jb_commission_no`)
- Termin- und Ablaufdaten (`tag`, `monat`, `jahr`, `stunde`, `minute`, `endetag`, `endemonat`, `endejahr`, `jb_warn*`, `jb_waittime_*`)
- Fahrzeug-, Sendungs- und Leistungsdaten (`vht_id`, `jb_weight`, `jb_crvh_length`, `jb_crvh_width`, `jb_crvh_height`, `jb_crvh_position`, Services, Artikel)
- Preis- und Zusatzkostenfelder (`jb_fixprice`, `jb_serviceprice`, `jb_cr_price`, `jb_cr_serviceprice`, `jb_discount`, `jb_discount_rate`, `jb_markup`, `jb_cr_markup`, `jb_toll`, `jb_km`, `jb_value_of_goods`, `jb_insurance_rate`)
- Steuerungsfelder fuer Status und Abwicklung (`jb_type`, `jb_globaljob`, `jb_status`, `jb_status_manual`, `jb_freetext_1`, `jb_hiddenFreetext_1`, `jb_costsplit`, `jb_permanent`, `jb_multi_factor`, `jb_cash`, `jb_offer`, `jb_origin`, `jb_origin_other`, `jb_dispoinfo`)
- Stationsfelder in den Tourmasken wie Name, Person, Strasse, Hausnummer, PLZ, Ort, Land, Bemerkung, Kommissionsnummer und Stationsstatus

#### Woher kommen die Daten?

- aus `job`, `tour`, `tourservice`, `jobprice`
- aus `jobbatch`, `jobbatchlist`
- aus `customer`, `costcenter`, `costcenteraddress`, `address`
- aus `service*`, `serviceplz*`, `serviceplzarea*`
- aus `metatype`, `tax`, `headquarters`
- aus `genericdatacontainer`
- aus `phoenix_log.semaphor`, `phoenix_log.log`

#### Was passiert mit den Daten?

- Auftragskopf, Stationen und Preispositionen werden validiert und zusammengesetzt.
- Adressen werden wiederverwendet oder neu angelegt.
- Preise werden ueber Service-, PLZ-, Bereichs- und Spezialregeln berechnet.
- Jobstatus, Langstreckenflag und Dispositionsrelevanz werden gesetzt.
- Kundenseitige Stornos erzeugen Statuswechsel, Gegenbelege und Logeintraege.
- Batch-Erfassung verdichtet Listenvorlagen zu mehreren Auftraegen.

#### Wohin werden die Daten geschrieben?

- nach `address`
- nach `job`
- nach `tour`
- nach `tourservice`
- nach `jobprice`
- nach `jobbatch`
- nach `jobbatchlist`
- nach `genericdatacontainer`
- nach `phoenix_log.semaphor`
- nach `phoenix_log.log`
- in Einzelfaellen nach `user.usr_inv_email`
- in Einzelfaellen nach `company.cmp_postage`

#### Wodurch wird der Ablauf gesteuert?

- `MASK_SINGLE_JOBEDIT`
- `MASK_MANUAL_DISPOSITION`
- `MASK_MANUAL_DISPOSITION_CUSTOMER_MANDATORY`
- `MODE_COPY_JOB`
- `MODE_LATER_JOB`
- `GLOBAL_USE_RELATED_CUSTOMER`
- `CUSTOMER_MASK_JB_CREATOR_DISCOUNT_<cs_id>`
- `MASK_CS_SELF_SERVICE_DISCOUNT`
- `MASK_MANDATORY_FILTERS`
- `MASK_CS_DONT_MAKE_STANDARD_PRICE_<cs_id>`
- `CUSTOMER_MASK_CALCULATOR_USAGE_ONLY_<cs_id>`
- `COSTCENTER_INV_MODE_<csc_id>`
- `EU_COUNTRYCODES`
- `MASK_CR_PRICE_MODE`
- `MASK_CR_PRICE_MODE_DATE`
- `INV_SERVICEPRICE_DISCOUNT`
- `CS_JB_JAM_WAITTIME_*`
- `MASK_INSERTADDRESS_DISTRICT_<cs_id>`
- `MASK_TR_PHOTO_FORCE`
- `MASK_MIN_MAX_TR_PHOTO_FORCE`
- `JB_EDITBATCH_*`
- `LONGHAUL_ACTIVE`
- `LONGHAUL_KM`

### 3.9 Disposition, Ranking, Favoriten, Push und Longhaul

#### Was passiert?

Offene Auftraege werden manuell oder automatisch Kuriere zugeordnet. Dabei spielen Fahrzeugtyp, Verfuegbarkeit, Favoriten, Sperren, Gebiete, Ortung und Langstreckenlogik zusammen.

#### Was muss der Benutzer tun, um den Schritt erfolgreich abzuschliessen?

- einen offenen Auftrag und einen fachlich passenden Kurier auswaehlen
- Ranking, Favoriten, Sperren, Fahrzeugtyp und Verfuegbarkeit pruefen
- die Zuordnung, Rueckgabe oder Vermittlung bewusst bestaetigen
- bei Bedarf Push oder Autoranking ausloesen und das Ergebnis kontrollieren

#### Welche Eingabefelder sind zu fuellen?

- Auftragsreferenz (`jb_id`)
- Kurierauswahl und Reihenfolge (`cr_id_order`, `cr_id_orders`, `cr_sid`)
- Filter- und Favoritensteuerung (`jb_cr_filter`, `jb_cr_filter_opt`, `ignore_fav_only`)
- manuelle Dispositionsangaben (`jb_status_manual`, `jb_dispoinfo`, `jb_jam_waittime`)
- Push-, Rueckgabe- oder Vermittlungsaktion im jeweiligen Dispositionsfenster

#### Woher kommen die Daten?

- aus `job`, `tour`, `address`
- aus `courier`, `couriervehicle`
- aus `customercourier`
- aus `serviceplz`, `serviceplzneighbour`, `serviceplzarea`, `serviceplzareamapping`, `serviceplzareaneighbour`
- aus `metatype`, `headquarters`
- aus `phoenix_log.locating`
- aus `parameter`

#### Was passiert mit den Daten?

- offene Jobs werden nach Rankingregeln bewertet
- Favoriten- und Sperrbeziehungen werden geprueft
- manuelle Rueckgabe in die Vermittlung oder in manuelle Disposition wird ausgefuehrt
- bei Langstrecken werden zusaetzliche HQ- und Distanzregeln geprueft
- fuer entfernte oder unplausible PDA-Zustaende werden Warnungen abgeleitet

#### Wohin werden die Daten geschrieben?

- nach `job.cr_id`
- nach `job.cr_id_order`
- nach `job.cr_sid`
- nach `job.jb_status`
- nach `job.jb_globaljob`
- nach `job.jb_longhaul`
- nach `genericdatacontainer` mit `jb_ignore_fav_only`
- nach `autoranking`
- nach `phoenix_pda.commandexec`
- nach `phoenix_log.log`

#### Wodurch wird der Ablauf gesteuert?

- `AUTORANKING_*`
- `RANKING_*`
- `MODE_INTERMEDIATION`
- `MASK_COURIER_SORT_BY_OCCUPIED`
- `MASK_MANDATORY_FILTERS`
- `LOCATING_*`
- `LONGHAUL_ACTIVE`
- `LONGHAUL_ACTIVE_REMOTE_DB`
- `LONGHAUL_KM`
- `BWV_CR_PRICE_RETOUR`

### 3.10 Karten, Ortung, Strecken und Tracking-Ausgaben

#### Was passiert?

Kartenansichten, Kurierortung, Distanzberechnung, Toursortierung, Trackingabfragen und partnerbezogene Trackingformate werden bereitgestellt.

#### Was muss der Benutzer tun, um den Schritt erfolgreich abzuschliessen?

- den richtigen Auftrag, Kurier, Zeitraum oder Trackingkontext auswaehlen
- Karten-, Ortungs- oder Routenansicht gezielt aufrufen
- bei Sortierung oder Distanzpruefung die vorgeschlagenen Ergebnisse fachlich kontrollieren
- die benoetigte Ausgabe oder Trackingansicht fuer den weiteren Prozess verwenden

#### Welche Eingabefelder sind zu fuellen?

- Auftrags- oder Kurierreferenz (`jb_id`, `cr_sid`)
- Trackingcode und Sprache (`trackingID`, `selectedLanguage`)
- Kartenkontext oder Aktualisierungsaktion fuer die Live-Ansicht
- bei Routenneuberechnung die Auswahl der betroffenen Tour oder Anzeigevariante

#### Woher kommen die Daten?

- aus `headquarters`, `courier`, `job`, `tour`, `address`, `stock`
- aus `phoenix_log.route`
- aus `tourarticle`, `tourarticleprocess`
- aus `address_geo.address_geo`, `address_geo.distance`
- aus `genericdatacontainer`

#### Was passiert mit den Daten?

- HQ- und Kurierpositionen werden auf Karten verdichtet.
- Adressen werden geocodiert oder aus dem Cache gelesen.
- Entfernungen und Fahrzeiten werden berechnet oder aus dem Distanzcache gelesen.
- Tourreihenfolgen werden optimiert und umgeschrieben.
- Trackingformate fuer verschiedene Partner werden aus Job- und Stationsdaten erzeugt.

#### Wohin werden die Daten geschrieben?

- nach `address`
- nach `address_geo.address_geo`
- nach `address_geo.distance`
- nach `address_geo.distance_osm`
- nach `tour.tr_sort`
- nach `tourarticle.tr_sort`
- nach `job.jb_tourdata`
- nach `jobprice` mit `mt_sort = 11`
- nach `courier.cr_gps_*`

#### Wodurch wird der Ablauf gesteuert?

- `MASK_JB_MAP_VIEW_ENABLED_<cs_id>`
- `MASK_JB_MAP_VIEW_COURIERS_<cs_id>`
- `GEOCACHE_LIFETIME`
- `LOCATING_MODE`
- `LOCATING_LBS_*`
- `LOCATING_ZIPCODE_COMPARISON_MODE`
- `LOCATING_PLAUSIBLE_VELOCITY`
- `PZM_ROUNDTRIPKM`
- `PZM_SHORTEST`
- `GEO_EARTH_RADIUS`
- `CO2_FORMULAR_*`

### 3.11 Auftragsdetail, POD, Signatur, Mail und PDF-Detailausgabe

#### Was passiert?

Im Auftragsdetail werden alle fachlichen Detaildaten angezeigt, Signaturen und Fotos verarbeitet, Statusmails erzeugt und PDF-Ausgaben pro Auftrag oder Rechnungsnummer erzeugt.

#### Was muss der Benutzer tun, um den Schritt erfolgreich abzuschliessen?

- den richtigen Auftrag oder die richtige Rechnungsnummer oeffnen
- POD-Daten, Fotos und Signaturen pruefen oder nachreichen
- bei Mailversand Empfaenger, Sprache und Inhalt fachlich kontrollieren
- die gewuenschte Detail-, Mail- oder PDF-Aktion aktiv ausloesen

#### Welche Eingabefelder sind zu fuellen?

- Auftragsreferenz und Historienkontext (`job_id`, `dbhistory`)
- Empfaenger- und Buchungsfelder (`f_email`, `f_crvh_sid_book`, `f_crvh_sid_order`, `f_jbp_*`)
- Detail- und Zusatzfelder (`f_tourname`, `f_jb_incomplete`, `f_jb_freetext_3_new`, `f_jb_finishtime4booking`)
- interne Bemerkung, POD-/Foto-/Signaturbezug und ausgeloeste Mail- oder PDF-Aktion (`f_int_rem_text`)

#### Woher kommen die Daten?

- aus `job`, `tour`, `tourservice`, `jobprice`
- aus `courier`, `customer`, `costcenter`, `company`
- aus `genericdatacontainer`
- aus `phoenix_log.route`, `phoenix_log.log`
- aus `invoice`
- aus vorhandenen Bild- und Signaturdateien

#### Was passiert mit den Daten?

- Detaildaten werden fuer Anzeige, Mail und PDF zusammengesetzt.
- Signaturen und POD-Fotos werden dem Auftrag zugeordnet.
- Mails werden mit kundenspezifischen Texten, Logos und Sprachregeln aufgebaut.
- PDF-Ausgaben aggregieren mehrere Auftraege ueber eine Rechnungsnummer.

#### Wohin werden die Daten geschrieben?

- in `html/temp/signs/`
- in `html/temp/photos/`
- in temporaere PDF- und Downloadpfade
- in Mail- und Automailer-Logs
- in Einzelfaellen nach `genericdatacontainer`

#### Wodurch wird der Ablauf gesteuert?

- `MASK_JOBDETAILS_*`
- `MAIL_*`
- `JOBDETAILS_EMAIL_LANGUAGE_<cs_id>`
- `JOB_MAIL_STATION_ARRIVAL_TIME_<cs_id>`
- `AUTOMAILER_*`

### 3.12 Rechnungswesen und Rechnungszuordnung

#### Was passiert?

Auftraege werden Rechnungsnummern und Rechnungsdaten zugeordnet. Aus diesen Zuordnungen entstehen Rechnungsuebersichten, Kurieransichten und PDF-Sammelausgaben.

#### Was muss der Benutzer tun, um den Schritt erfolgreich abzuschliessen?

- die abzurechnenden Auftraege oder die Zielrechnung eindeutig auswaehlen
- Rechnungsnummer, Rechnungsdatum und Zusatzangaben korrekt pflegen
- bei Bedarf Kurierbemerkungen oder Zahlungsbezug ergaenzen
- die Zuordnung speichern und die Rechnungs- oder PDF-Ausgabe pruefen

#### Welche Eingabefelder sind zu fuellen?

- Datumsbereich (`day_from`, `month_from`, `year_from`, `day_to`, `month_to`, `year_to`)
- Kostenstellen- oder Kurierbezug (`jb_costcenter`, `cr_sid`)
- Kundenfilter (`cs_eid`, `cmp_name`)
- Status- und Anzeigeoptionen (`jb_status`, `show_invoice_text`)
- in der Detailpflege zusaetzlich Rechnungsnummer, Rechnungsdatum und Bemerkungen

#### Woher kommen die Daten?

- aus `invoice`
- aus `job`, `tour`, `jobprice`
- aus `costcenter`, `customer`, `employee`, `user`, `courier`
- aus `jobpayment`, `jobpaymentcollection`

#### Was passiert mit den Daten?

- mehrere Jobs werden einer Rechnungsnummer zugeordnet
- Rechnungsdatum und Rechnungsnummer werden je Job gesetzt oder aktualisiert
- Kurierbemerkungen koennen gepflegt werden
- fuer die PDF-Ausgabe werden alle Jobs einer Rechnungsnummer geladen

#### Wohin werden die Daten geschrieben?

- nach `invoice`
- nach `job.jb_cr_remark`

#### Wodurch wird der Ablauf gesteuert?

- `INV_*`
- `JB_PAYMODE_CASH`
- `JB_TAX_RATE_SIGN`

### 3.13 Statistik und Kennzahlen

#### Was passiert?

Die Statistik stellt Kennzahlen zu Jobs, Kunden, Kurieren, Services, Preisen, Surveys und Umsaetzen bereit. Der Schwerpunkt liegt auf Selektion, Aggregation und Gruppierung.

#### Was muss der Benutzer tun, um den Schritt erfolgreich abzuschliessen?

- Zeitraum, HQ-Kontext und die fachlich passenden Filter setzen
- die benoetigte Kennzahlensicht oder Gruppierung auswaehlen
- die Auswertung starten und auf Plausibilitaet pruefen
- das Ergebnis bei Bedarf exportieren oder fuer Folgeprozesse verwenden

#### Welche Eingabefelder sind zu fuellen?

- Zeitraum mit Datum und optional Uhrzeit (`day_*`, `month_*`, `year_*`, `hour_*`, `minute_*`)
- Statistiktyp, Kategorie, Sortierung und Datumsmodus (`f_category`, `f_statistic`, `f_sort`, `f_direction_sort`, `f_dateMode`, `f_statusMode`, `f_priceMode`)
- Objektfilter fuer Kunde, Kurier, Fahrzeug und HQ (`g_cs_eid`, `g_cr_eid`, `f_crvh_sid`, `f_hq_id`, `f_filter*`)
- Leistungs-, Service-, Gruppen- und Groessenfilter (`f_service`, `f_servicetype`, `f_jb_service`, `f_jb_specifics`, `f_group`, `f_staticGroup`, `f_filter_jb_*`)
- Ausgabefelder fuer Datei, Diagramm, Netto/Brutto und Zusatzdaten (`fileOutput`, `f_type_chart`, `f_net_gross`, `f_show_*`)

#### Woher kommen die Daten?

- aus `job`, `tour`, `jobprice`
- aus `courier`, `couriervehicle`
- aus `customer`, `costcenter`, `company`, `branch`
- aus `user`
- aus `genericdatacontainer`
- aus `phoenix_log.log`
- aus Archivtabellen ueber `getDBNames`

#### Was passiert mit den Daten?

- Zeitraeume und HQ-Filter werden aufgeloest.
- Auftraege, Kunden und Kuriere werden nach vielen Kriterien gefiltert.
- Kennzahlen werden gruppiert, summiert und fuer UI oder Dateioutput aufbereitet.
- Survey-, Preis- und Zusatzdaten werden optional in die Statistik eingeblendet.

#### Wohin werden die Daten geschrieben?

- standardmaessig nirgends in die Datenbank
- optional in Dateioutput fuer Exporte oder Druckausgabe

#### Wodurch wird der Ablauf gesteuert?

- `GLOBAL_USE_RELATED_CUSTOMER`
- `MASK_STATISTIC_*`
- `STATISTIC_DATE_MODE`
- `STATISTIC_INTERVALS_*`
- `STATISTIC_YEAR_OF_BEGIN_HISTORY`
- `STATISTIC_NO_STORNOJOBS`
- `STATISTIC_EXCLUDED_CS`
- `STATISTIC_CSEIDS_EXCLUDED*`
- `STATISTIC_CREIDS_EXCLUDED*`
- `STATISTIC_CRVHSIDS_EXCLUDED`
- `STATISTIC_PREFERED_CATEGORY_INDEX_JB`

### 3.14 Vertrieb, Termine, Aufgaben und Berichte

#### Was passiert?

Termine, Wiedervorlagen, Aufgaben und Vertriebsberichte fuer Kunden, Transporteure und Interessenten werden geplant, angezeigt und abgeschlossen.

#### Was muss der Benutzer tun, um den Schritt erfolgreich abzuschliessen?

- den richtigen Objektbezug wie Kunde, Transporteur oder Interessent auswaehlen
- Termin, Aufgabe oder Bericht mit Datum, Teilnehmern und Inhalt pflegen
- den Bearbeitungsstatus aktuell halten und offene Punkte dokumentieren
- nach Abschluss den Termin oder Bericht sauber abschliessen

#### Welche Eingabefelder sind zu fuellen?

- Termin- und Wiedervorlagefelder (`f_day`, `f_month`, `f_year`, `f_hour`, `f_minute`, `f_day_to`, `f_month_to`, `f_year_to`, `f_hour_to`, `f_minute_to`)
- Kategorien und Verantwortliche (`f_ap_cat_1` bis `f_ap_cat_4`, `f_selUsrId`, `f_grp_id`)
- Objekt- und Kundenbezug (`g_cs_eid` sowie Objektreferenzen aus Kunde, Transporteur oder Interessent)
- Inhalt und Teilnehmer (`f_text`, Teilnehmerauswahl, Gruppenwahl)
- Benachrichtigungsfelder (`f_sendmail[]`, `f_sendmail_cs[]`, `f_emailAdrCs`, `f_mail_salutation`, `f_mail_greetings`)

#### Woher kommen die Daten?

- aus `phoenix_group.appointment`
- aus `phoenix_group.report_process`
- aus `user`, `employee`
- aus `customer`, `courier`, `company`, `headquarters`
- aus `metatype`

#### Was passiert mit den Daten?

- Termine werden angelegt, aktualisiert oder geloescht.
- Teilnehmerlisten und Sichtbarkeiten werden ausgewertet.
- Aufgaben sind fachlich Sonderfaelle von Terminen.
- Berichte werden objektspezifisch gespeichert und koennen gleichentags offene Termine auf erledigt setzen.

#### Wohin werden die Daten geschrieben?

- nach `phoenix_group.appointment`
- nach `phoenix_group.report_process`

#### Wodurch wird der Ablauf gesteuert?

- `MASK_AP_BTN_*`
- `MASK_AP_CATEGORY_*`
- `MASK_AP_CAT_*`
- `MASK_AP_WARNING_DISABLE_QUESTION_NO_REPORT_OF_SAME_DAY`
- `MASK_CS_REPORT_*`
- `MASK_CR_REPORT_*`
- `MASK_PT_REPORT_*`
- `MASK_RP_ENABLE_DEACTIVATION_APPOINTMENT_WARNING_OF_SAME_DAY`
- `IMG_LOGO_*`

### 3.15 Kommunikation, Mitteilungen und Endgeraetehistorie

#### Was passiert?

HQ-interne Ticker-Meldungen, Kuriernachrichten, Zustellbestaetigungen, Antworten und Nachrichtengruppenzuordnungen werden verwaltet.

#### Was muss der Benutzer tun, um den Schritt erfolgreich abzuschliessen?

- die passende Zielgruppe, den Kurier oder die Nachrichtengruppe auswaehlen
- den Nachrichtentext fachlich eindeutig formulieren
- Versand oder Veroeffentlichung gezielt ausloesen
- Rueckmeldungen, Antworten und Lesestatus im Nachgang kontrollieren

#### Welche Eingabefelder sind zu fuellen?

- Tickerfelder wie Geltungszeitraum, Betreff, Text und Sichtbarkeit (`day_from`, `month_from`, `year_from`, `day_to`, `month_to`, `year_to`, `f_tif_subject`, `f_tif_text`, `f_tif_unerasable`, `f_hq_id_insert`, `f_emp_id_insert`)
- Nachrichtenfilter wie Zeitraum, Prioritaet, Status und Empfaengertyp (`day_*`, `month_*`, `year_*`, `f_prio`, `f_state`, `f_usr_type`, `f_filter`)
- Gruppen- und Einzelnachrichtenfelder (`f_msggrp`, `f_subject_group`, `f_body_group`, `f_usr_sender`, `f_usr_receiver`, `f_cr_sid_msg`)
- Zuordnung von Nachrichtengruppen zu Kurieren (`f_msggrp` in der Kurierpflege)

#### Woher kommen die Daten?

- aus `phoenix_group.tickerforum`
- aus `phoenix_log.messageforum`
- aus `messagegroup`
- aus `courier`, `user`, `company`, `headquarters`, `employee`

#### Was passiert mit den Daten?

- Ticker-Nachrichten werden erstellt, ausgesteuert und abgelaufene Eintraege geloescht.
- Nachrichten an Fahrer oder Fahrergruppen werden erzeugt.
- Lese- und Antwortstatus werden nachgefuehrt.
- Nachrichtengruppen werden einzelnen Kurieren zugewiesen.

#### Wohin werden die Daten geschrieben?

- nach `phoenix_group.tickerforum`
- nach `phoenix_log.messageforum`
- nach `courier.cr_msggrp`

#### Wodurch wird der Ablauf gesteuert?

- `NEWSTICKER_MAX_BODY_LENGTH`
- `MESSAGE_MAX_BODY_LENGTH`
- `MESSAGE_MIN_DAYS_BEFORE`

### 3.16 Datenexport, Datentransfer, Dokumente und Dateistaging

#### Was passiert?

Stamm- und Bewegungsdaten werden exportiert, Dokumente werden hochgeladen oder heruntergeladen, FTP/SFTP-Transfers werden ausgefuehrt und Importdateien werden bereitgestellt.

#### Was muss der Benutzer tun, um den Schritt erfolgreich abzuschliessen?

- das richtige Exportprofil, Zielsystem oder Uploadziel auswaehlen
- Dateien oder Objektmengen fachlich korrekt zusammenstellen
- bei externem Transfer Zugangsdaten, Zielpfade und Dateinamenskonventionen beachten
- den Transfer starten und Ergebnis, Protokolle und Ablage pruefen

#### Welche Eingabefelder sind zu fuellen?

- Exportkategorie, Exportmodus und Parameterprofil (`f_exp_category`, `f_export_mode`, `f_parname`, `f_parname_export`, `f_expp_id`)
- Dateiaufbau und Dateiname (`f_fileName`, `f_delimiter`, `f_fillUpChar`, `f_headline`, `f_bolchars`, `f_eolchars`, `f_bofchars`, `f_eofchars`)
- Datenfilter (`day_from`, `month_from`, `year_from`, `day_to`, `month_to`, `year_to`, `f_cs_eid_filter`, `f_status_filter`, `f_vht_filter`, `f_jbp_filter`, `f_csId`, `f_grpId`)
- Administrationsfelder fuer Parameterpflege und Dateiloeschung (`f_parname_new`, `f_exportFileToDelete`, `adminInterfacePassword`)

#### Woher kommen die Daten?

- aus `exportparameters`, `exportfiles`, `exportcategory*`
- aus `job`, `jobpayment`, `jobpaymentcollection`
- aus `company`, `couriervehicle`, `customer`
- aus dem lokalen Dateisystem unter `import/upload/`
- aus entfernten FTP-/SFTP-Verzeichnissen

#### Was passiert mit den Daten?

- Exportprofile bestimmen Struktur und Inhalt der Dateien.
- Exportdateien werden generiert und archiviert.
- Uploads werden objektbezogen in statische oder HQ-bezogene Verzeichnisse einsortiert.
- FTP-Serverlisten und Remoteziele werden aus Parametern aufgeloest.
- Exportmarkierungen an Firmen, Fahrzeugen und Jobs verhindern Doppelverarbeitung oder dokumentieren den Exportzeitpunkt.

#### Wohin werden die Daten geschrieben?

- in `html/export/download/`
- in `html/import/upload/...`
- nach `exportfiles`
- nach `company.cmp_export_time`
- nach `couriervehicle.crvh_export_time`
- nach `job.jb_export_time`
- nach `jobpayment.jbp_export_time`
- nach `jobpaymentcollection.jbpc_export_time`

#### Wodurch wird der Ablauf gesteuert?

- `EXPORT_PATH`
- `EXPORT_FILES_ON_SERVER`
- `EXPORT_FILES_ON_SERVER_CUSTOMER`
- `EXPORT_SEMAPHORE_*`
- `EXPORT_CSV_HEADLINE_CS_<cs_id>`
- `EXPORT_CAT_09_FILE_EXTENSION`
- `EXPORT_MASK_FTP_*`
- `EXPORT_FTP_FILE_EXTENSIONS_ENABLED`
- `FTP_IMPORT_SERVERLIST`
- `FTP_SERVER_*`
- `FTP_USER_*`
- `FTP_PASSWORD_*`
- `FTP_REMOTEPATH_*`
- `DATATRANSFER_DIRECTORY_*`
- `DATATRANSFER_HQ_PATH_*_ENABLED`
- `DATATRANSFER_MAX_*`
- `DATATRANSFER_UPLOAD_PREFIX_RENAME`
- `MASK_DATATRANSFER_NAV2ROOTDIR_ENABLED`

### 3.17 XML-, Mobile- und Partner-Schnittstellen

#### Was passiert?

Externe Systeme koennen Kunden, Transporteure, Auftraege, Stationen, Preise, Filter, Metadaten, Groupware-Daten und mobile Zeit- oder Positionsmeldungen ueber XML austauschen.

#### Was muss der Benutzer tun, um den Schritt erfolgreich abzuschliessen?

- als technischer Benutzer den richtigen Endpunkt und den passenden Mandantenkontext verwenden
- Requests mit korrekten IDs, Hashes, Pflichtfeldern und Nutzdaten senden
- Rueckmeldungen fachlich auswerten und Fehlerfaelle sauber behandeln
- bei Produktivnutzung die erzeugten XML-Logs und Seiteneffekte kontrollieren

#### Welche Eingabefelder sind zu fuellen?

- Request-Nutzlast als XML (`orderReq`, `customerReq`, `contractorReq`)
- Sprach- und Aktionsfelder (`selectedLanguage`, `f_act`)
- Authentifizierungsfelder in XML wie `auth_type`, `auth_id`, `auth_eid`, `account`, `password`, `session_id`
- Objektfelder in XML wie Kunde/Kostenstelle, Transporteur/Fahrzeug, Station, Gruppe, Service, Trackingcode oder Operation

#### Woher kommen die Daten?

- aus XML-Requests ueber `service/*.php`
- aus `customer`, `costcenter`, `costcenteraddress`, `company`
- aus `courier`, `couriervehicle`, `user`, `address`
- aus `job`, `tour`, `tourservice`, `jobprice`
- aus Preis- und Gebietsstammdaten
- aus `courierfilter`
- aus `phoenix_group.timetracking`
- aus `meta_object.metaobject`

#### Was passiert mit den Daten?

- Requests werden geparst, authentifiziert und in Fachobjekte zerlegt.
- Fachlich relevante IDs wie `cs_id`, `cr_id`, `csc_id`, `jb_id` oder externe Hashes werden aufgeloest.
- Je nach Endpunkt werden Objekte gelesen, angelegt, aktualisiert, geloescht oder angereichert.
- Alle Requests werden zusaetzlich in XML-Logdateien protokolliert.

#### Wohin werden die Daten geschrieben?

Je nach Endpunkt unter anderem:

- nach `company`, `customer`, `costcenter`, `costcenteraddress`
- nach `courier`, `couriervehicle`, `user`, `address`
- nach `job`, `tour`, `tourservice`, `jobprice`
- nach `courierfilter`
- nach `phoenix_group.timetracking`
- nach `meta_object.metaobject`
- in `html/log/*.log`

#### Wodurch wird der Ablauf gesteuert?

- `GLOBAL_USE_RELATED_CUSTOMER`
- `GLOBAL_UNIQUE_DB_INSTANCE_NO`
- `HQ_INSTANCE`
- `DISPOSITION_JB_STATUS_MODE`
- `FDS_CUSTOMER_ENABLED_CS_<cs_id>`
- `ORDER_REQUEST_VHT_ID_DEFAULT_<cs_id>`
- `ORDER_REQUEST_INVTEXT_DAYTIME_DISABLED`
- `ORDER_REQUEST_NO_PRICE_CS_<cs_id>`
- `TRACKING_ENABLED_CS_<cs_id>`
- `ORDER_REQUEST_ERR_115_DISABLED`
- `ORDER_REQUEST_AUTORESPONSE_ENABLED_CS_<cs_id>`
- `STATION_REQUEST_ERROR_HANDLER_DISABLED*`
- `STATION_REQUEST_CHECK_EXISTENCE_COMMISSION_NO`
- `STATION_REQUEST_CHECK_OPERATION_EXISTENCE_COMMISSION_NO`
- `SYSTEM_FORM_SINGLE_HQ*`
- `MAXIMUM_LOGIN_TRIALS`
- `CR_ADD_TO_ASSET_ENABLED`

### 3.18 Lager und Artikelwirtschaft

#### Was passiert?

Lagerstrukturen, Artikel, Bestandsmengen, Serien- bzw. Scanvorgaenge, Lagerjournale und Lageradressen werden gepflegt.

#### Was muss der Benutzer tun, um den Schritt erfolgreich abzuschliessen?

- das richtige Lager, Unterlager oder den betroffenen Artikel auswaehlen
- Mengen, Bewegungsart, Bezug und gegebenenfalls Scan- oder Serieninformationen erfassen
- die Buchung oder Stammdatenpflege speichern
- das Ergebnis im Lagerjournal oder Bestandsbild fachlich kontrollieren

#### Welche Eingabefelder sind zu fuellen?

- Lagerstammdaten wie Maximalbestand, Barcode und Adressdaten (`f_stk_maxquantity`, `f_stk_barcode`, `f_ad_*`, `f_stk_hsno`)
- Such- und Filterfelder fuer Artikel und Lager (`f_stkat_search_at_misc`, `f_stkat_search_atg`, `f_displayModeStockArticle`, `f_mv_mode*`)
- Bewegungsfelder (`f_mv_stk_from`, `f_mv_stk_to`, `f_mv_at`, `f_mv_stk_itemquantity`, `f_mv_tan`, `f_mv_remark`, `f_mv_serialno`, `f_mv_jb_id`)
- frei konfigurierbare Zusatzfelder fuer Lagerbewegungen (`f_mv_datafield_01` bis `f_mv_datafield_15`)
- Scan- und Journalfelder (`f_scan`, `f_stkat_scanmode`, `f_store`, `f_mv_search_*`, Datumsfilter)

#### Woher kommen die Daten?

- aus `stock`, `stockarticle`, `article`, `articlegroup`, `articlegroupitem`
- aus `address`
- aus `customer`, `company`
- aus `parameter`

#### Was passiert mit den Daten?

- Lagerbaeume und Unterlager werden aufgelistet und gefiltert.
- Artikelzugriffe werden je Mitarbeiter und Lagerkontext eingeschraenkt.
- Bestandsbewegungen erzeugen Journal- und Bewegungsdaten.
- Lageradressen werden ueber die allgemeine Adresslogik gelesen oder gepflegt.

#### Wohin werden die Daten geschrieben?

- nach `stock`
- nach `stockarticle`
- nach `articleitem`
- nach `stockmove`
- bei Lageradresspflege nach `address`

#### Wodurch wird der Ablauf gesteuert?

- `MASK_STK_ROOT_ACCESS`
- `MASK_STK_READONLY`
- `MASK_STK_READONLY_WHERE_DEFINED_WRITEACCESS`
- `MASK_STK_ARTICLE_ACCESS`
- `MASK_STK_SUBSTOCK_ACCESS`
- `MASK_STKAT_SHOW_PERMANENT_<stk_id>`
- `MASK_STK_JOURNAL_*`
- `MASK_STK_DATAFIELDS_*`
- `MASK_LINK_DISPOSITION_STKTO_EQ_STKFROM_<stk_id>`
- `MASK_AT_LIST_COLS`

---

## 4. Wichtigste fachliche Schreibziele im Ueberblick

Wenn die Frage nicht pro Prozess, sondern uebergreifend gestellt wird, schreibt die Legacy-PHP-Anwendung fachlich vor allem in diese Speicherbereiche:

- Stamm- und Bewegungsdaten: `user`, `employee`, `company`, `customer`, `costcenter`, `courier`, `couriervehicle`, `job`, `tour`, `tourservice`, `jobprice`, `invoice`, `stock*`
- Konfiguration: `parameter`
- flexible Objektzusaetze: `genericdatacontainer`
- Audit und technische Steuerung: `phoenix_log.log`, `phoenix_log.semaphor`, `phoenix_log.locating`, `phoenix_log.route`, `phoenix_pda.commandexec`
- Kommunikation und Vertrieb: `phoenix_group.appointment`, `phoenix_group.report_process`, `phoenix_group.tickerforum`, `phoenix_log.messageforum`
- Geo- und Routingcache: `address_geo.address_geo`, `address_geo.distance`, `address_geo.distance_osm`
- externe Objektkopplung: `meta_object.metaobject`
- Dateisystem: `import/upload/`, `export/download/`, `temp/download/`, `temp/pdf/`, `temp/photos/`, `temp/signs/`, `images/external/`, `log/`

---

## 5. Zusammenfassung

Die Legacy-PHP-Anwendung ist fachlich ein komplettes Betriebsportal und kein einzelner Auftragserfassungsdialog. Die Fachlogik verteilt sich ueber:

- klassische relationale Tabellen
- die Parametrisierung in `parameter`
- flexible Zusatzdaten in `genericdatacontainer`
- Protokoll- und Nebensteuerung in `phoenix_log.*`
- Dateiablagen, Exportpfade und XML-Endpunkte

Fuer Migration und Analyse ist deshalb entscheidend, jeden Vertikalschnitt nicht nur ueber seine Haupttabellen, sondern immer auch ueber Parameter, Zusatzspeicher, Logs und Dateipfade zu betrachten.
