votianng/html/DOKUMENTATION.md

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.