Buchungskreise - CX_ACCOUNTING_AREA

Um auch für z.B. Fremdlager, unabhängig vom lokalen Lagerbestand, termingerecht disponieren zu können, sind Buchungskreise notwendig.

Es werden alle logistischen und dispositiven Bewegungen und Mengen nach Buchungskreisen getrennt in Untermonitoren mitgeführt.

Eine Betrachtung der gesamten Prozesse ist also so pro Buchungskreis möglich.

Ein Buchungskreis kann an jedes Geschäftsobjekt gehängt werden wie zum Beispiel an ein Lager oder eine Kostenstelle. Bei der Buchung eines Belegs wird ermittelt, ob ein Buchungskreis zur Buchung herangezogen werden muss. Ist dies der Fall, so wird zusätzlich zur globalen Verbuchung auch noch der Buchungskreis separat bebucht.

Der Buchungskreis, der über die Stammdaten angelegt werden kann, muss einem Objekt (Lager) zugeordnet werden, für dass er gelten soll.

In der Regel sind dies Lager, die über einen eigenen Buchungskreis verwaltet werden sollen, vielleicht auch unabhängig vom eigentlichen Lager/-Bestand.
Auf dem Buchungskreis kann angegeben werden, ob die Lagermenge bzw. die Bedarfe im Gesamtkonto des Teils auftauchen sollen, oder nicht (gemeinsame oder getrennte Teiledisposition - Bedarfs-Bestandslisten)

Technische Konzeption:

Es wird eine neue Klasse CX_ACCOUNTING_AREA mit einer weiteren neuen Kontoklasse CX_AREA_ACCOUNT geben, die über den Slot clearingObjects an jedes Geschäftsobjekt gehängt werden kann. Strukturiert wird sie über die Klasse CX_ACCOUNTING_AREA_CHART

CX_STOCK::clearingObjects -> CX_ACCOUNTING_AREA::monitors -> CX_AREA_ACCOUNT

Jeder Beleg in ClassiX wird die Möglichkeit bekommen, direkt für einen Buchungskreis zu gelten (über einen Slot areaAccount). Wird kein Buchungskreis angegeben, so wird der Beleg nur in die globalen Teilemonitore gebucht. Entsteht ein Folgebeleg für einen Beleg mit Buchungskreis, so wird der Buchungskreis direkt mit auf den Folgebeleg mit kopiert. Der gesamte Dispositionsprozess ist somit in einem Buchungskreis enthalten.

Ist der Buchungskreis einem Lager zugeordnet, auf dem das Kennzeichen "keine Disposition" gesetzt ist, so werden die Bewegungsdaten NICHT auf den globalen Monitoren verbucht, sondern AUSSCHLIEßLICH auf den Buchungskreismonitoren.

Der CX_AREA_ACCOUNT besitzt dann für jedes Teil, welches über ihn verbucht wird, zwei CX_LOG_CUBE als subMonitor. Auf dem subMonitor, der mit der anderen Dimension auf den CX_STOCK_ACCOUNT des Teils weist, stehen die Minimal- und Maximalbestände des Teils an diesem Buchungskreis. Hier werden ebenfalls die gebuchten Bestände mitgeführt, was eine separate Bestandsauskunft für den Buchungskreis somit ermöglicht. Eine direkte Verbindung zum Lager muss es allerdings nicht geben, da der Buchungskreis ja auch an einem anderen Objekt hängen kann, als am Lager.

Der zweite CX_LOG_CUBE subMonitor weist mit der anderen Dimension auf den CX_DISPO_ACCOUNT des Teils und bildet somit eine Untermenge der gebuchten Bedarfe und Bedarfsdecker, nur für diesen Buchungskreis.

Das Logistikkonto wird so erweitert, dass es auch mit den CX_LOG_CUBEs arbeiten kann, die zwischen Buchungskreis und Logistikkonto eines Teils entstanden sind. Hier können spezifisch für den Buchungskreis die Min- Max Bestände und sogar die Bereitstellungsarten und Logistikkenzeichen separat geführt werden. Dies ist durch das interne Wrappen der Verbindung über DimensionByCondition("type(this)=CX_STOCK_ACCOUNT") auf dem CX_LOG_CUBE realisiert. Ist beim Speichern eines solchen CX_LOG_CUBEs die Verbindung noch nicht gewrappt, so wird dies beim ersten Speichern nachgeholt.

Ebenfalls ist die Verbindung vom Logcube zum Dispokonto gewrappt.

Für das übersichtliche Verwalten der ganzen Teile am Buchungskreis wird es eine Übersichtsliste geben, die alle bereits einmal gebuchten und somit entstandenen CX_LOG_CUBEs des Buchungskreises enthält. Möchte man schon vor der ersten Buchung einen Teilebuchungskreis einrichten, um zum Beispiel die Min- Maxbestände anzugeben, gibt es hier die Möglichkeit, per Teileauswahl diese zu generieren.

Über diese Liste es auch möglich einzusehen, bei welchem lagergeführten Teil es zu Auffüllungsbedarf kommt. Über der Liste sind Knöpfe angeordnet, die eine Nachbestellung über eine Bestellung oder Bedarfsanforderung oder eine Auffüllung durch einen Lagerauftrag für diesen Buchungskreis ermöglichen.

Auf der B&B Liste wird es in einem weiteren Schritt die Möglichkeit geben, diese nur für einen anzugebenen (OBox) Buchungskreis auszuwerten. Ebenso könnte das Dispokonto per auswählbarem Buchungskreis entsprechend nur die relevanten Daten anzeigen. Denn vom Aufbau her (bis auf den owner Pointer) sind die Dispo- und Lagerkonten mit den darunterliegenden CX_LOG_CUBES gleich.

 Das Kennzeichen, ob auf dem globalen Konten gebucht werden soll, ist nicht am Lager, sondern dies bestimmt der Buchungskreis.

Auf den untersten Knoten der hierarchisch angeordneten Buchungskreise befindet sich ein Kennzeichen, das binär verschlüsselt steuert, wie weit über ihm die Belege ebenfalls registriert werden. 0 = gar nicht. 1 = nur im verlinkten Buchungskreis. 3 = Im verlinkten Buchungskreis und dem übergeordneten Buchungskreis...