Zeitzonenverwaltung in der Kundenauftragsabwicklung

Ergebnis

Jedes Datum wird in einer Zeitzone ausgedrückt, die aus Sicht eines Benutzers und/oder aus Sicht eines geographischen Standorts relevant ist.

Zweck

Wenn ein Unternehmen in vielen Ländern der Welt Niederlassungen hat, müssen verschiedene Zeitzonen verwaltet werden. Die Zeitzonenverwaltung ermöglicht einem Benutzer an einem entfernten Standort, Kundenaufträge vor Ort anzuzeigen und zu interpretieren.

Vorgehensweise

Daten, die bei der Auftragserfassung angezeigt und vorgeschlagen werden können, oder Daten, die automatisch über APIs oder Autojob erstellt werden können, werden in eine relevante Zeitzone konvertiert.

Folgende Datentypen verwenden die Zeitzonenkonvertierung:

Auftragsdatum
Kundenauftragsdatum
Lieferdatum – lokal (Planungsdatum, Abfahrtsdatum, angefordertes Datum und bestätigtes Datum)
Lieferdatum – bei der Bestimmungsadresse (angefordertes Datum, bestätigtes Datum)
Freigabedatum (Lieferungsauftrag)
Rechnungsdatum (Kundenauftragsrechnung)
Retourendatum (Kundenauftragsretouren)
Erfassungsdatum und Änderungsdatum (keine Zeitzonenkonvertierung)

Auftragsdatum

Das Auftragsdatum wird gemäß der Zeitzone des Standorts für den Auftrag initialisiert. Die Zeitzone für den Ladeort am Hauptlagerort des Standorts wird verwendet, um den Vorschlag bereitzustellen. Beispiel: Wenn ein Handelsvertreter an einem Lagerplatz tätig ist, der Teil des Standorts ist, reflektiert das Auftragsdatum die aktuelle Zeit des Lagerplatzes.

Kundenauftragsdatum

Wenn ein Datum nicht erfasst oder vom Kunden übermittelt wird, wird das Datum auf die gleiche Art und Weise wie das Auftragsdatum initialisiert. Das heißt, dass Sie das Kundendatum aufbewahren müssen, damit die Bestellhistorie des Kunden verfolgt werden kann.

Lieferdatum – lokal

Die Daten, die sich auf die Lieferung von Waren oder Leistungen beziehen, werden angezeigt und gemäß der Zeitzone des Ladeplatzes am Lieferlagerort gespeichert. Zu den Daten, die durch diese Logik abgedeckt sind, zählen Planungsdatum, Abfahrtsdatum, das gewünschte Datum und das bestätigte Datum. Das bedeutet, dass Sie die tatsächlichen Zeitpunkte des Stattfindens von erwartete Aktivitäten in der Zeitzone ausdrücken müssen.

Lieferdatum – bei der Bestimmungsadresse

Die in der Zeitzone des Kunden ausgedrückten Daten werden angezeigt und gemäß der Zeitzone des Entladeplatzes am Lieferort oder des Kunden gespeichert. Zu den Daten, die durch diese Logik abgedeckt sind, zählen das gewünschte Datum und das bestätigte Datum. Das bedeutet, dass die tatsächlichen Zeitpunkte des Stattfindens von erwartete Aktivitäten in der Zeitzone ausgedrückt werden müssen.

Freigabedatum (Lieferungsauftrag)

Das Freigabedatum wird vorgeschlagen und gemäß der Zeitzone des Entladeplatzes am Lieferort oder der Lieferadresse des Kunden angezeigt. Das bedeutet, dass Sie die tatsächlichen Zeitpunkte des Stattfindens von erwartete Aktivitäten in der Zeitzone ausdrücken müssen.

Rechnungsdatum und Buchungsdatum

Das Rechnungsdatum und das Buchungsdatum werden gemäß der Zeitzone der Division, die den Auftrag erteilt hat, initialisiert und vorgeschlagen. Das bedeutet, dass jede Division ihre lokale Zeitzone verwenden kann, wenn am Ende einer Periode Buchungsabschlüsse durchgeführt werden müssen. Alle Finanztransaktionen müssen sich daher auf die Divisions-/Finanzzeitzone beziehen.

Retourendatum

Die Daten, die sich auf Retouren von gelieferten Waren oder Leistungen beziehen, werden angezeigt und gemäß der Zeitzone des Ladeplatzes am Zugangslagerort gespeichert. Das bedeutet, dass Sie die tatsächlichen Zeitpunkte des Stattfindens von erwartete Aktivitäten in der Zeitzone ausdrücken müssen.

Erfassungsdatum und Änderungsdatum

Das Erfassungsdatum und das Änderungsdatum sind Zeitstempel und werden gemäß der Zeitzone des Systems gespeichert. Das bedeutet, dass Sie die Historie und den Verlauf der Datenbankaktualisierungen unabhängig von der Herkunft der Erfassung oder Änderung verfolgen können.

Szenarios

Fakturierung in Japan, wenn sich der M3 Server in Europa befindet

Server und Firmensitz in Großbritannien (GMT/UCT)
Verkaufsdivision in Tokio, Japan mit lokaler Fakturierung und Debitorenbuchhaltung
Datum und Uhrzeit in Großbritannien: 30. März 2003, 23:30 Uhr
Datum und Zeit in Tokio, Japan: 1. April 2003, 7: 30 Uhr

Ein japanischer Benutzer gibt eine Rechnung frei. Das vorgeschlagenen Rechnungs- und Buchungsdatum ist der 1. April 2003, das lokale Datum der japanischen Verkaufsdivision. Wenn die Rechnungsstellung abgeschlossen ist, werden folgende Daten verwendet:

Rechnungsdatum (in der Debitorenbuchhaltung und auf dem Rechnungsdokument): 1. April 2003
Buchungsdatum: 1. April 2003
Verkaufsstatistikdatum: 1. April 2003

Fakturierung in den USA, wenn sich der M3 Server in Europa befindet

Server und Firmensitz in Großbritannien (GMT/UCT)
Verkaufsdivision in Los Angeles, USA mit lokaler Fakturierung und Debitorenbuchhaltung
Datum und Zeit in Großbritannien: 1. April 2003, 12:30 Uhr
Datum und Zeit in Los Angeles, USA: 31. März 2003, 17:30 Uhr

Der US-amerikanische Benutzer gibt eine Rechnung frei. Das vorgeschlagene Rechnung- und Buchungsdatum ist der 31. März 2003, das lokale Datum der US-amerikanischen Verkaufsdivision. Wenn die Rechnungsstellung abgeschlossen ist, werden folgende Daten verwendet:

Rechnungsdatum (in der Debitorenbuchhaltung und auf dem Rechnungsdokument): 31. März 2003
Buchungsdatum: 31. März 2003
Verkaufsstatistikdatum: 31. März 2003