14.08.2013 / LE
Übersicht und Prozessbeschreibungen KO
Inhaltsverzeichnis
- Kooperation SBB/TM - Übersicht
- Kooperation SBB/TM - Prozess
- Kooperation BV - Übersicht
- Kooperation BV - Prozess
- Kooperation RM - Übersicht
- Kooperation RM - Prozess
- Kooperation SK - Übersicht
- Kooperation SK - Prozess
Kooperation SBB/TM - Übersicht
Der Sendungsaustausch mit KO SBB ist wie folgt:
Dargestellt sind die Sortierzentren der beiden Kooperationspartner (KoP) A und B. Der KoP A holt die Sendungen beim Absender ab und übergibt diese an KoP B, welcher die Sendung zustellt.
Mit dem Modul KO SBB - Kooperation Sendung, Box, Bündel werden Sendungsdaten vom KoP A zum KoP B übertragen. Dies erleichtert dem zustellenden KoP B die Feinsortierung. Zusätzlich müssen auch die Leistungen mit KO TM übertragen werden, damit eine korrekte Zuweisung von Leistungen unterschiedlicher KoPs erfolgen kann.
Die Leistungsdaten (KO TM) werden jeweils vom KoP A der die Sendungsdaten verschickt, an den KoP B der die Sendungsdaten erhält, übertragen, somit kann KoP B die Leistungen von KoP A seinen eigenen Leistungen zuweisen.
Selbstverständlich können KoP's mehrere Kooperationen eingehen:
Kooperation SBB/TM - Prozess
Der Gesamtprozess mit KO SBB/TM beschreibt sich wie folgt:
Abholung
Der KoP A holt alle Sendungen beim Absender ab. Darunter befinden sich auch die Sendungen, welche an einen KoP geliefert werden.
Sortierung
Die Sortierung der Sendungen erfolgt nach Land, PLZ / Ort, Strasse und Hausnummernbereich.
Für jeden KoP ist ein Bezirk in der Bezirksverwaltung (BV) hinterlegt. Der Bezirk enthält alle PLZ / Orte des KoP's (Achtung: Es müssen keine Strassen hinterlegt sein!). Ein weiteres zusätzliches Kriterium zur Übertragung einer Sendung an den KoP ist der Kunde, auf den die Sendung erfasst wurde. Ist dieser Kunde ein Kooperationspartner (also ein Kooperierter Kunde) wird diese ebenfalls übertragen, unabhängig vom Bezirk.
Durch die Sortierung der Sendungen mittels Manuelle-Sortierhilfe (MS) oder durch eine Sortiermaschine werden alle Sendungen für die entsprechenden KoPs aussortiert.
Datenübertragung
Das Modul KO - Kooperation des KoP A "sucht" alle erfassten Sendungen, welche dem KoP übergeben werden müssen, aus der Datenbank heraus und überträgt alle relevanten Daten zum KoP. Zusätzlich werden alle Leistungsdaten, falls diese seit der letzten Übertragung verändert wurden, übergeben.
Das Modul KO des empfangenden KoP B liest die Sendungsdaten in die eigene Datenbank ein. Die empfangenen Leistungen werden in eine Zuweisungstabelle gespeichert, von wo aus sie mit den eigenen Leistungen des KoP B abgeglichen werden können. Damit sind alle Sendungsdaten dem KoP B bekannt.
Der Datenaustausch selbst erfolgt mit gezippten XML-Dateien über FTP/FTPS/SFTP-Server.
Feinsortierung
Die Sendungen gelangen nach dem Transport ins Sortierzentrum von KoP B. Hier unterscheidet sich die Weiterverarbeitung je nachdem, ob die Bezirksdaten mit dem KoP A kooperiert wurden oder nicht. Sind diese nicht kooperiert tritt Fall 1 ein, andernfalls Fall 2.
Fall 1: Ohne KO BV
Da die Sendung bereits einen UPOC besitzt und die Sendungsdaten in der Datenbank bereits vorhanden sind, muss nur noch der UPOC eingelesen und die Sendung mit den entsprechenden SortInfos bedruckt werden. Werden die Sendungen von Hand bearbeitet (MS-Plätze), so erhält die Sendung ein neues Sendungslabel. Werden die Sendungen mit einer Sortiermaschine bearbeitet, werden die SortInfos zusätzlich aufgedruckt. Die Sendungen werden auf den jeweiligen Zustellbezirk sortiert.
Fall 2: Mit KO BV
Die Sendungen werden feinsortiert. Da bereits alle Sortierinformationen durch den KoP A aufgedruckt wurden, können die Sendungen direkt feinsortiert und in die Zustellung übergeben werden.
Zustellung
Die Sendungen werden ganz normal zugestellt. Es gibt keine Unterschiede in der Zustellung zwischen Sendungen, welche vom KoP stammen und denen, welche von eigenen Kunden stammen.
Kooperation BV - Übersicht
Dieses Beispiel geht davon aus, dass 3 Kooperationspartner Ihre Sendungen zum Zustellen dem Kooperationspartner D liefern. Da der Zusteller die korrekten Gebiets- und Bezirksdaten seiner Kunden hat, liefert er die BV per XML-Datei an seine Kooperationspartner A, B und C. Diese übertragen die Verantwortung der Orte an den KoP D und erhalten somit von ihm die korrekten Gebiets- und Bezirksdaten mit seinen Sortierinformationen.
Der Austausch der Gebiets- und Bezirksdaten erfolgt genau gleich wie der Austausch der Sendungsdaten in einer XML-Datei über FTP/FTPS/SFTP.
Übertragene Gebietsdaten in der BV der KoP’s A, B und C sind ersichtlich, jedoch nicht mehr mutierbar, abgesehen von Aliasen. Die so übertragenen Bezirksdaten eines anderen Kooperationspartners sind in der BV sichtbar.
Kooperation BV - Prozess
Der Gesamtprozess von KO BV beschreibt sich wie folgt:
Verantwortung übertragen
Wie funktioniert die Übertragung der Verantwortung und was genau bedeutet das? Zum einfacheren Verständnis folgende Grafik:
Wir gehen davon aus, das KoP A derjenige ist, der die Sendungen sortiert und per Transport an den KoP B liefert, der diese dann zustellt. Somit muss KoP A über die korrekten Gebiets- und Bezirksdaten verfügen, damit er die Sendungen sortieren kann. Da aber nur der Zusteller die korrekten Gebietsdaten kennt, möchte KoP A diese nicht selber pflegen, sondern von KoP B erhalten. Also ist KoP B verantwortlich für die Pflege der Gebiets- und Bezirksdaten in seinem Zustellgebiet.
KoP A sagt sich nun, dass er die Verantwortung für bestimmte Gebiets- und Bezirksdaten an KoP B abtritt, dass heisst, KoP B muss diese pflegen und schickt diese per KO BV an KoP A. Bei KoP A werden alle Änderungen/Neuerfassungen und Löschungen automatisch per KO BV erledigt.
Bitte beachten Sie, dass die Übertragung der Verantwortung immer auf Ortsebene stattfindet, dass heisst das nur für einen Ort in der Gebietsverwaltung die Verantwortung übertragen werden kann.
Vorgehen zur Übertragung der Verantwortung
In der Bezirksverwaltung wird der gewünschte Ort, für den die Verantwortung an einen Kooperationspartner übertragen werden soll, ausgewählt. Bei der Verantwortungsübertragung werden alle Gebietsdaten unterhalb des Ortes, also Strassen und Häuser, sowie alle Aliase auf Ort und Strassen gelöscht. Der Ort selber wird nicht gelöscht, lediglich einem anderen Mandanten zugewiesen und somit auf nicht editierbar gesetzt.
Befindet sich dieser Ort für den die Verantwortung an einen KoP übertragen wurde in den Bezirksdaten, und ist in den Einstellungen zum Import von KO BV Gebiets- und Bezirksdaten eingestellt, werden alle Daten unterhalb des Bezirksortes inklusive des Bezirksort selber gelöscht falls sich dieser Bezirk in einer aktiven Bezirksstruktur befindet, andernfalls werden nur die Bezirksdaten unterhalb und inklusive der Bezirksstrasse gelöscht. Falls damit ein Bezirk leer wird, wird auch der leere Bezirk gelöscht.
Die Mutation respektive die Löschung von Bezirksdaten erfolgt gemäss der Verarbeitung BV, dass heisst der Bezirk wird auf editierbar geschaltet, mutiert und wieder freigeschaltet. Somit werden auch alte Versionen dieses Bezirkes angelegt.
Wenn Sie die Verantwortung einer Ortschaft zurück nehmen, gibt es eine spezielle Verarbeitung. Je nachdem ob dieser Ort in einem Bezirk mit mehreren Ortschaften oder nur diesem einen Ort liegt, ist die Veränderung unterschiedlich.
Wenn der Bezirk nur diesen einen Ort enthält, wird der ganze Bezirk wieder auf eigene Verantwortung zurückgenommen, falls noch andere Orte mit übertragener Verantwortung darin sind, sieht die Verarbeitung wie folgt aus:
| Originalzustand | Mutation | KO-Import |
| Alle Ortschaften sind unter fremder Verantwortung: |
Verantwortung für Ort 2 wird zurück genommen: |
Die neue Struktur sieht wie folgt aus: |
 |
 |
|
Der Bezirk wird kopiert und die Ortschaft, für die die Verantwortung zurückgenommen wird, wird unter der Bezirkskopie abgelegt.
Gebiets- und Bezirksdaten senden
Bei jedem Exportintervall wird geprüft, ob der nächste Exportintervall im Zeitplan (JobEngine) für einen Export von KO BV liegt. Ist dass der Fall, werden je nach Einstellungen von KO BV die Gebiets- und Bezirksdaten exportiert.
Es werden immer alle Gebietsdaten inklusive Aliasdaten und alle Bezirksdaten aus der definierten Standardbezirksstruktur inklusive alle Bezirksgruppen, Dienstleisterzonen und Depots in eine XML-Datei exportiert. Da dem Kooperationspartner der diese Daten exportiert nicht bekannt ist, welche Orte vom KoP in seine Verantwortung übertragen wurden, muss er alle Gebiets- und Bezirksdaten übertragen.
Gebiets- und Bezirksdaten empfangen
Wenn bei einer Übertragung BV Daten von einem Kooperationspartner empfangen werden, wird geprüft, ob dieser Importintervall im Zeitplan (JobEngine) für einen Import von KO BV liegt. Ist das der Fall, werden die BV Daten sofort importiert, andernfalls wird die XML-Datei mit den BV Daten in ein gesondertes Verzeichnis abgelegt und beim nächsten definierten BV Importzeitplan erneut gelesen und verarbeitet. Somit gehen keine BV Daten verloren, die zwar von einem Kooperationspartner gesendet wurden, aber aufgrund des Importzeitplans nicht verarbeitet wurden. Werden in der Zwischenzeit neue BV Daten gesendet, werden die alten BV Daten gelöscht und es wird nach dem gleichen Verfahren weitergemacht.
Beim Import werden jeweils nur die Gebiets- und Bezirksdaten eingelesen, deren Verantwortung übertragen wurde. Es wird die ganze Gebietsstruktur ab dem Ort, also Strassen und Häuser mit allen Aliasen neu angelegt, oder falls vorhanden überschrieben. Der Ortseintrag erhält den UPOC des Kooperationspartners, der die Gebietsdaten geschickt hat. Damit ist zwar die ganze Gebietsstruktur in der BV wieder sichtbar, aber nicht mehr mutierbar.
Genau gleich wird mit den Bezirksdaten verfahren. Falls der Ort mit der übertragenen Verantwortung in den Bezirksdaten des Kooperationspartners vorkommt, wird dieser neu angelegt. Dies Betrifft auch Bezirke, die einen Ort bzw. Strasse oder Haus eines vom Kooperationspartner freigeschalteten Ort enthalten, aber nicht unter eigener Verantwortung stehen. Somit werden auch Orte die durch unterschiedliche Bezirke laufen, kooperiert (weisse Flecken).
Falls nötig wird auch die Bezirksgruppe und der Bezirk selber angelegt wenn er noch nicht vorhanden ist. Dies gilt für alle aktiven Bezirksstrukturen. Wenn mehrere Bezirksstrukturen für den Import aktiviert wurden, so werden auch alle Bezirksdaten die importiert werden in den aktiven Bezirksstrukturen angelegt bzw. upgedatet.
Sortierung
Der Briefdienstleister, der die Gebiets- und Bezirksdaten empfangen hat, sortiert die Sendungen und druckt die Sortierinformation des Kooperationspartners auf, die er beim Import der Bezirksdaten erhalten hat. Da die Sendungen im Bezirk eines anderen Mandanten liegen, oder die Sendungen auf einen Kunden erfasst wurden, die einem anderen Mandanten zugewiesen sind, kommen diese Sendungen in den Datentransfer von KO SBB.
Zustellung
Der Kooperationspartner erhält die Sendungen sowohl elektronisch als auch physisch eingeliefert und kann diese direkt in die Zustellung übergeben.
Kooperation RM - Übersicht
Kooperation RM - Prozess
Beim Prozess KO RM handelt es sich um einen Abgleich von Reklamationen. Das heisst dass immer beide Kooperationspartner über alle aktuellen Reklamationsdaten von jeweils beiden KoP’s verfügen, solange der zuständige KoP der Reklamation nicht geändert wird.
Reklamationsdaten werden jeweils im Intervall für KO-Export und KO-Import verarbeitet, es existiert kein separater Zeitplan für den Datentransfer. Der Datentransfer erfolgt über eine XML-Datei die zusammen mit allen anderen KO-Dateien in eine passwortgeschützte Datei gepackt werden.
Es gibt jeweils 2 unterschiedliche Datenimporte und Datenexporte, die sich dadurch unterscheiden, ob eine Reklamation vom KoP erfasst wurde, oder ob diese von einem KoP erhalten wurde. Aufgrund dieser Unterscheidung handelt es sich auch um 2 unterschiedliche XML-Dateien die unterschiedliche Daten enthalten.
Diese beiden Prozessabläufe laufen jeweils bei jedem Kooperationspartner ab, da jeder Kooperationspartner Reklamationen senden / zurückerhalten und Reklamationen erhalten / zurücksenden kann.
Übertragung der Reklamation an KoP B
Bei jedem Exportzyklus des KO-Servers (Standard = 15 Minuten) werden Reklamationen für KoP’s exportiert. Exportiert werden alle Reklamationen, bei denen ein Kooperationspartner definiert ist und seit dem letzten KO-Transfer etwas mutiert wurde.
Folgende Daten werden je nach beschriebenem Kriterium übertragen, es werden immer alle Daten übertragen, auch solche die nicht verändert wurden:
| Daten | Kriterium | Speichern als |
| Reklamations-UPOC | keines | Reklamations-UPOC |
| Priorität | keines | Priorität |
| Status | keines | Status |
| dtWarten | keines | dtWarten |
| dtMutiert | keines | dtMutiert |
| Kurztext | keines | Kurztext |
| Bezirks-UPOC | keines | Bezirkszuweisung falls UPOC in Bezirksverwaltung gefunden wurde |
| Bemerkung | keines | Bemerkung |
| Verweise | keines | Verweise |
| Beanstander | Wenn CheckBox Adresse des Beanstanders übertragen im KO-Setup auf Tab KO RM aktiviert ist. |
Beanstander |
| Empfängeradresse | keines | Empfängeradresse |
| Journale | Wenn Mandant des Journal-UPOC's = eigener Mandant und CheckBox Privater Eintrag nicht aktiviert ist. |
Journale |
| Dateien (inkl. Files) | Wenn Mandant des Journal-UPOC's = eigener Mandant und CheckBox Privater Eintrag nicht aktiviert ist. |
Dateien (inkl. Dateien und inkl. Icons) |
Übertragung der Reklamation zurück an KoP A
Bei jedem Exportzyklus des KO-Servers (Standard = 15 Minuten) werden Reklamationen, die von einem KoP empfangen wurden, an diesen zurückgesendet. Exportiert werden alle Reklamationen, die von einem Kooperationspartner empfangen wurden und seit dem letzten Transfer mutiert wurden.
Es werden folgende Attribute an den KoP A zurück übertragen:
| Attribut | Spezial |
| Reklamations-UPOC | Dient zum Eindeutigen identifizieren einer Reklamation |
| Status | |
| dtWarten | |
| dtMutiert | |
| Dateieinträge | Es werden nur Dateieinträge übermittelt, deren UPOC dem Mandanten des eigenen Mandanten entspricht und deren CheckBox Privater Eintrag nicht aktiviert ist. Es werden ebenfalls die Dateien zu den Dateieinträgen übermittelt. |
| Journaleinträge | Es werden nur Journaleinträge übermittelt, deren UPOC dem Mandanten des eigenen Mandanten entspricht und deren CheckBox Privater Eintrag nicht aktiviert ist. |
Kooperation SK - Übersicht
KO SK heisst Kooperation mit Sicherer Kommunikation. Kooperationsdaten werden mittels FTP/FTPS/SFTP übertragen. Dabei kann es auf beiden Seiten, also beim Sender als auch beim Empfänger zu Fehlern kommen. Diese Fehler können unterschiedlicher Art sein und ebenso zahlreich. Deshalb wurde ein Übergeordnetes Protokoll eingeführt, welches verhindern soll, dass Daten beim Empfänger nicht ankommen.
Begriffserklärung
Zum besseren Verständnis soll hier die Struktur des internen Datenmodells aufgezeigt werden. Diese hier erklärten Begriffe werden immer wieder verwendet und sind eindeutig identifizierbar und somit nicht zu verwechseln.
| Bezeichner | Beschreibung |
| Container | Dabei handelt es sich um die komprimierte Datei, die per Kommunikation (in unserem Fall FTP/FTPS/SFTP) zwischen zwei Kooperationspartnern ausgetauscht wird. |
| Objekt | Hierbei handelt es sich um die einzelnen Dateien, welche in der ZIP-Datei, also im Container, zusammengefasst werden. Die einzelnen Dateien enthalten die unterschiedlichen KO-Moduldaten, z.B. die Daten von KO SBB, oder die Daten von KO BV. |
| Item | Bei den Items handelt es sich um die XML-Strukturen, welche in den Datendateien, also in den Objekten, enthalten sind. |
Wenn wir also von Daten sprechen, die zwischen 2 Kooperationspartnern hin- und hergehen, sprechen wir immer von Containern.
Kooperation SK - Prozess
Mit der Einführung von KO SK werden Container sowohl beim Sender als auch beim Empfänger direkt in der Datenbank abgelegt. Dort werden sie erst nach erfolgreicher Bestätigung oder Verarbeitung wieder gelöscht. Somit können keine Container verlorengehen.
Der Ablauf eines Datentransfers mit KO SK gestaltet sich wie folgt:
| KO SK | ||||
| KoP A | KoP B | |||
| Container erzeugen |
Erzeugt aufgrund der Einstellungen einen Container mit oder ohne Daten. |
|||
| Container senden |
Sendet den Container per FTP/FTPS/SFTP |
→ | Container empfangen |
Container in der Datenbank speichern und Empfang quittieren |
| Container verarbeiten |
||||
| Bestätigung empfangen |
Bestätigten Container in der Datenbank löschen. |
← | Container bestätigen |
Bestätigung für korrekten Empfang und Verarbeitung senden. Danach wird der Container in der Datenbank gelöscht. |
Im Falle eines Fehlers wird der Container erneut geschickt, bis eine Bestätigung erhalten wird. Ist das nach einer bestimmten Zeit nicht der Fall, wird ein Alarm ausgelöst.
Die Container werden eindeutig durch eine fortlaufende Nummerierung identifiziert. Somit ist auch die korrekte Reihenfolge gewährleistet. Fällt die Kommunikation aufgrund der Containernummer aus der Reihe, wird entsprechend Quittiert oder Alarmiert.
Die leeren Container werden ignoriert und ungültige Container werden nicht verarbeitet. Ungültige Container werden nicht quittiert und somit vom Sender erneut an den Kooperationspartner geschickt.
Reset
Es kann Situationen geben, in denen KO SK nicht mehr korrekt arbeiten kann. Dass ist z. B. dann der Fall, wenn bei einem Kooperationspartner ein Datenbankbackup zurückgespielt werden muss und somit die Reihenfolge der Container nicht mehr mit dem KoP übereinstimmt. In diesem Fall muss beim KoP der das Backup zurückgespielt hat, ein Reset ausgelöst werden. Dies geschieht in den Einstellungen von KO mit dem Resetbutton.
Beim Reset werden für alle definierten Kooperationspartner noch zu verarbeitende Container gelöscht, die Nummerierung wird wieder auf den Anfang gestellt und alle zu Kooperierenden Daten werden (je nach Einstellung) 10 Tage in die Vergangenheit wieder an den KoP übertragen. Danach wird eine Resetanweisung an alle Kooperationspartner übertragen, damit diese die gleiche Verarbeitung machen können. Erst nachdem ein KoP den Reset quittiert hat, werden wieder Daten an diesen übermittelt. Sollte ein Reset innerhalb einer definierten Zeitspanne nicht quittiert werden, wird alarmiert.