1216 lines
48 KiB
Markdown
1216 lines
48 KiB
Markdown
# 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.
|