+43 1 3178243-0

1

2

3

4

7

5

6

8

9

11

10

= Prozessschritte

emasos iq ERP r2 –

Detail beschreibung

 

 

 

UMFASSENDE

ORGANISATIONSSTRUKTUREN

 

• Mandant = Konzern
– Konzernland / Konzernwährung – die Anmeldung eines Users erfolgt im Konzern – er hat damit – je nach Berechtigung – technisch auf alle darunter liegenden Organisationseinheiten Zugriff, ohne sich an- und abmelden zu müssen.

Ein Konzern  umfasst mehrere Firmen.  Ein Konzern kann einem anderen untergeordnet sein (Konzernstruktur) – innerhalb dieser muss es aber einen TOP-KONZERN geben (Diese Zusammenfassung dient aber nur der Kumulierung von Reporting-Daten und der etwaigen Umrechnungen von Konzernwährungen in die der übergeordneten Konzerne)

Jeder Konzern hat eine Konzernwährung. Per Parameter kann definiert werden, in die Währung welches Konzerns währungsrelevante Beträge von Bewegungsdaten der Firmenmandanten umgerechnet werden sollen.

 

• Firmenmandant
– Firmenwährung / Kontenplan –einem Konzern zugeordnet = bilanzierende Einheit / rechtliche Organisation

Jeder Firmenmandant kann einen getrennte FIBU-Kontenplan haben – umgekehrt können n Firmenmandanten den gleichen FIBU-Kontenplan haben. Jeder Firmenmandant hat eine „Hauswährung“, in der die FIBU geführt ist. Alle währungsrelevanten Beträge werden in den Bewegungsdaten  – egal in welcher Währung sie entstehen - in die Hauswährung umgerechnet.

 

• Standortmandant – einem Firmenmandanten zugeordneter Standort – Adresse – Dispositionsgrenze – Organisationseinheit logistische Umlagerungen zwischen Lagerorten nur per Lieferung

 

 Lager


 
– einem Standort zugeordnet innerhalb eines Standortes kann es mehrere – physisch getrennte Läger geben Mehrere Läger eines Standortes können zu einem Dispobereich zusammengefasst werden mögliche „Sonderläger“ (getrennte Disposition):

o Qualitätsprüfungslager

o Retourenlager

o externes Lager für Konsibestände Kunde

o externes Lager für Einzelbestände Vorhaben

 

• Lagerplatzorganisation


– mehrere Läger unterschiedlicher Firmenmandanten können auf die gleiche Lagerplatzorganisation zugreifen Definiert eine physische Einheit von Lagerplätzen

 

• Lagerplätze Physischer Ort, an dem Ware lagert Default Lagerplätze – pro Lager zu definieren:

o WE-Zone

o WA-Zone

o Hauptlagerplatz (wenn Hauptlager nicht in mehrere Lagerplätze unterteilt ist)

o (Produktionsversorgungslagerplatz –nur bei Produktion sinnvoll)

 

Pro Lager müssen WE/WA-Zone , – falls Hauptlager nicht in Lagerplätze unterteilt ist – Hauptlagerplatz und – falls Produktion aktiv – Produktionsversorgungslagerplatz als Defaultlagerplätze definiert sein. Dabei können sie aber die gleiche Ausprägung haben – also im Extremfall: wenn keinerlei Lagerplatzunterteilung erwünscht ist, alle auf den gleichen Lagerplatz hinweisen.

 

• Mandantengruppe


fasst einem oder mehrere Firmenmandanten eines Konzerns  zu einer Gruppe zusammen. Innerhalb derer:

o Stammdatennummern und Stammdatenidentifikation (Kunde / Lieferant / Material,..) eindeutig sein müssen

o teilweise eine gemeinsame „Parametrisierung“ (Customizing) erfolgt

o alle Geschäftsfallobjekte (Bewegungsdaten) haben die Mandantengruppe als obersten Key – sind somit über diesen gemeinsam auswertbar)

 

• Dispobereich


(relevant für Materialdisposition) Die Materialdisposition wird getrennt pro Dispobereich durchgeführt. Pro Standort können mehrere Lager zu einem Dispobereich zusammengefasst werden – umgekehrt könnte theoretisch auch jedes Lager getrennt disponiert werden.

„Einzelbestände“ - siehe Punkt „Bestandskategorisierung“ – werden immer getrennt disponiert

Eine weitere Unterteilungsmöglichkeit ist die getrennte Disposition nach „Sonderbestandsarten“
 – siehe „Bestandskategorisierung“.

 

 

MULTIFUNKTIONALE MATERIALBESTANDSKATEGORIEN

Die „Musskoordinaten“ für die Bestandsführung sind:

 

o Mandantengruppe

o Firmenmandant

o Standortmandant

o Lager

o Lagerorganisation

o Lagerplatz (gemeinsam mit Lagerorganisation) kann durch Parametrisierung pro Lager als für den Anwender quasi irrelevant definiert werden.

 

ACHTUNG: Ausnahme Sonderbestandsart „TRANS“ – Transitbestand zwischen zwei Standorten endet bei (empfangenden) Standort

 

CHARGEN- / SERIALNUMMER:

 

 Alle Bestandsarten können – parametrisiert über den Materialstamm – neben den „Muss-Koordinaten“ auch Chargen- und / oder Serialnummern enthalten. Beide können mengen- und wertmäßig getrennt geführt werden. Allerdings können nur entweder Chargen- oder Serialnummern wertmäßig geführt werden.

In den Fällen der getrennten Chargenführung muss jede Materialbewegung mit einer Chargennummer versehen werden. Im Falle der Serialnummer kann definiert werden, ob diese bei Wareneingang (vom Lieferanten oder Fertigung) oder erst bei Lieferung erzeugt werden soll. Im ersten Fall muss ebenfalls jede Lagerbewegung mit Serialnummer geführt werden, im zweiteren erst ab Geschäftsfälle nach WA-Abgang – also z.B. im Falle einer Rücknahme in den Retourenbestand. Ab dann kann sie – auch getrennt bewertet (Gebrauchtware) – serialnummernbezogen geführt werden.

 

EINZELBESTÄNDE:

 

pro Vorhaben (siehe oben) bzw. pro Kundenauftragsposition können Materialien als Einzelbestände / Vorhaben / Kundenauftragsposition - getrennt vom anonymen“ Bestand geführt werden. Definiert werden sie durch Einzelbestands-Kennzeichen „V“ (Vorhaben)/ „C“ (Kundenauftrag) und der Spezifikation „Vorhabennummer“ / „Kundenauftragsnummer / -position“ . Diese Einzelbestandskontierung spielt eine Rolle bei:

 

o Bedarfs- / Umlagerungsanforderungen

o Bestellungen

o Disposition

o Kundenauftragsposition

o allen Lagerbuchungen

o Lieferbeleg

o FIBU-Belegen (getrennte Bestandskonten für Einzelbestände möglich)

 

Dort gespeicherte Positionen werden getrennt disponiert (Bedarf kommt in der Regel aus dem Kundenauftrag) und getrennt bewertet (gewichtetes Durchschnittspreisverfahren). Somit können auch kleine Varianten , die aber andere Einstandspreise als die klassischen Materialien dieser Nummer haben, mit der gleichen Materialnummer über diesen Einzelbestand geführt werden.

Einzelbestände müssen physisch als solche gekennzeichnet werden. Unterhalb der Einzelbestände dürfen Sonderbestände , (nur unbewertete) Chargen / Serialnummern geführt werden. Bei der Abfassung der Einzelbestände in den Verbrauch werden die Kosten - defaultmäßig – auf die Einzelvorhabenspezifikationen gebucht.

Vom anonymen Bestand kann in Einzelbestände und von diesen in den anonymen Bestand gebucht werden, ebenso können Umbuchungen zwischen den Einzelbeständen vorgenommen werden. In all diesen Fällen wird nicht nur die mengenmäßige, sondern auch die korrekte wert- und fibu-mäßige Buchung durchgeführt.

 

SONDERBESTANDSARTEN:

 

Sonderbestandsarten verringern den verfügbaren Bestand der übergeordneten Bestandskategorien (anonym / Einzelbestände). Sie werden aber nicht getrennt bewertet , sondern unterliegen der Bewertung der übergeordneten Bestandskategorie.

Sonderbestandsarten können, müssen aber nicht eigene Disposbereichen zugeordnet sein. Wenn ja, können am Materialstamm Dispoparameter (Meldebestand,…) pro Sonderbestandsart gepflegt werden. Im Dispositionsergebnis werden die Verfügbarkeitssituationen der Sonderbestände getrennt unterhalb der anderen Bestände angeführt. Nur wenn sie einem Dispobereich zugeordnet sind, können bei Unterdeckung maschinelle Bedarfsanforderungen direkt für den Sonderbestand erzeugt werden. Es kann eingestellt werden, dass Sonderbestände im Dispovorschlag nicht in Form einer externen Bedarfsanforderungen, sondern als Umlagerungsbedarf von einer anderen Bestandsart (meist anonym, aber auch Lieferantenkonsi kann sinnvoll sein) nachbeschafft werden.

Sonderbestandsarten können in Eigentum des Anwenders oder einer dessen Kunden (Kundenbeistellung) / Lieferanten (Lieferantenkonsilager) sein.

Es kann parametrisiert werden, welche Sonderbestandsarten physisch getrennt gekennzeichnet werden und welche nicht.

Sonderbestandsarten in Eigenbestand können auch Kriterium für die Findung von Materialbestandskonten in der FIBU sein.

 

Prinzipiell kann der Anwender Sonderbestände selbst definieren und parametrisieren. Folgende sind vom System vorgegeben und nur bedingt parametrisierbar:

 

• KKONS: Kundenkonsibestand – gehört Anwender – kann im Hauptlager oder im externen Kundenkonsilager liegen- Spezifikation Kundennummer – muss nicht explizit gekennzeichnet werden

• LKONS: Lieferantenkonsibestand – gehört Lieferant – explizit physisch gekennzeichnet – Spezifikation Lieferantennummer

• TRANS: Transferbestand – gehört Anwender – ist dem Standort zugeordnet , wo er eingelagert wird – Spezifikation: empfangender Standortmandant

• KUNRES: für einen Kunden reservierter allgemeiner Bestand – gehört dem Anwender – meist nicht explizit physisch gekennzeichnet – Spezifikation: Kundennummer

• GARANT: Garantiebestand beim Lieferant – gehört dem Anwender – Spezifikation: Lieferantennummer

• KUNBEI: Kundenbeistellbestand – gehört dem Kunden – nicht bewertet – muss physisch gekennzeichnet werden – Spezifikation: Kundennummer

• LOHNB: Lohnbeistellbestand – gehört dem Anwender – liegt beim Lieferanten – Spezifikation: Lieferantennummer

 

UMWIDMUNGEN SONDERBESTAND (keine Lagerbewegung, nur Änderung der Sonderbestandsart / Einzelbestands-Kennzeichen)

 

Durch „Umwidmung“ kann eine Sonderbestandsart in eine andere oder in einen anonymen Bestand „umgewandelt“ werden und umgekehrt – ähnliches ist auch für den Einzelbestand möglich (siehe oben).

Dabei gelten folgende Regeln: Von Eigenbestand in Fremdbestand nicht möglich. Von Fremdbestand Kunde in Eigenbestand nicht möglich

Wenn von Fremdbestand Lieferant in Eigenbestand (klassisch: Verwendung Lieferantenkonsibestände)

 

Bewertung Zielbestand mit einem Angebotspreis aus Angebot Material / Lieferant (laut Bezugsquellenfindung – siehe später) – wenn dies nicht maschinell möglich: manuelle Bewertungseingabe oder Fehlermeldung

Wenn von oder zu Bestandskoordinate eine physische Kennung verlangen, muss diese Umwidmung – obwohl keine Lagerbewegung – dafür ein „Kommissionierbeleg“ (Lagerplatzbuchungsbelege – siehe später) erzeugt werden, der den Lagerverantwortlichen anweist, entweder gezielt vom gekennzeichneten Bestand zu „umzuwidmen “ und / oder den Zielbestand speziell zu kennzeichnen.

 

Emasos IQ r2 – PROZESSFLUSS

"ORDER to CASH" (Lagerabverkauf)

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

1. Wesentliche vorzubereitende Daten für Prozessabwicklung

• Stammdaten

  •  Kunde
  • Lieferant
  • Material

• Pflegen Dispodaten

• Preise / Rabatte (kundenseitig)

• Lieferantenangebote / Lieferantenkontrakte

• Kundenangebote / Kundenkontrakte

• Währungskurse

• Abteilungen / Mitarbeiter (Einkauf / Verkauf / Disposition / Lager)

• Defaultparameter im Userstamm (Vorschlagswerte / Filter-Parameter)

 

2. Prozess-Einzelschritte

 

Der Prozess Order to Cash beinhaltet folgende Funktionen:

 

◉ = manueller Vorgang ohne Trigger

= Useraktion auf Basis „EMASOS-Prozesstrigger“  am Bildschirm

◉ = voll maschinell

(in Klammer gesetzte Aktionen sind optional)

• Kundenauftrag / Abruf zum Kundenkontrakt

  • Bedarfsgenerierung
  • Erstellen Bedarfsanforderung für Direktbestellung
  •  Erstellen Bedarfsanforderung für Streckenbestellung
  • (Erstellen Transportauftrag zum Kundenauftrag)

Maschinelle Disposition

  •   Generierung Bedarfsanforderungen
  •   Dispoergebnisse des letzten Dispolaufs

Umwandeln Bedarfsanforderungen in Bestellung

  •  (manuelle Bestellanlage)
  •  (Transportauftrag zur Bestellung)

•  Wareneingang zur Bestellung

  •   (Einräumen von WE-Zone in Hauptlager)

Erstellen Lieferbeleg aus Triggersätzen

  •    elektronische Kommissionierliste (Lagerplatzbuchungsbeleg)
  •   Kommissionieren in WA-Zone
  •   Quittieren (etwaiges Ändern) Lieferbeleg
  • (Erstellen Transportauftrag zum Lieferbeleg)

Drucken Lieferschein

  • Bedarfssatz wird WA-relevant

Buchen Warenausgang – periodisch aufgerufener Hintergrundjob

könnte auch manuell angestoßen werden

Erstellen Faktura aus Triggersätzen

Eingabe und Zuordnung Zahlung

 

 

 

INTELLIGENTE ZUSATZFUNKTIONEN FÜR DIE BESCHAFFUNG

1. BEDARFSANFORDERUNG (BANF) / UMLAGERUNGSANFORDERUNG (UBANF)

 

1.2 BANF

 

Eine Bedarfsanforderung / Umlagerungsanforderung definiert einen Bedarf entweder zur Erhöhung des Bestands in definierten „Lagerkoordinaten) (Lager-BANF) oder für den kostenrechnungswirksamen Materialverbrauch / Dienstleistungseinsatz für Kostenstelle / Vorhaben / Kundenauftragsnummer / -position (Verbrauchs-BANF).

 

LAGER-BANF:

Kann nur maschinell von Disposition für lagerhaltige Materialien erzeugt werden. Sie muss enthalten:

 

• Materialnummer (lagerhaltiges Material)

• Menge

• Bezugstermin

• Lagerkoordinaten

 

 Muss

• Firmenmandant

• Standortmandant

• Lager

 

Kann

• Einzelbestands-KZ und Spezifikation

• Sonderbestandsart und Spezifikation

 

VERBRAUCHS-BANF

 

Kann nur manuell erstellt werden. Sie kann für alle Materialkategorien (lagerhaltig/nicht lagerhaltig / Dienstleistungen) erstellt werden. Sie muss folgende Daten enthalten:

• Materialnummer oder beschreibenden Text

• Menge

• Termin

•  Firmenmandant

•  (Default)-Standort aus Userstamm

• (Default)-Lager

•  Kostenrechnungskontierung (eine davon ist Muss)

o Kostenstelle

o Vorhabennummer

o Kundenauftragsnummer / -position

o Ticketnummer (maschinell unterstützte Umwandlung in ein „echtes“

     Kostenrechnungsobjekt

o Konto ( Kostenart) – wenn nicht eingegeben, wird eine Defaultkostenart laut

     Warengruppe bzw. Firmenmandant maschinell eingesetzt

•  Waren- / Leistungsempfänger (Soll)

•  Wunschlieferant (Kann)

 

BANFEN aus KUNDENAUFTRAGSPOSITION

 

Aus der Kundenauftragsposition können zwei „BANF-Kategorien“ initiiert werden (manuell oder durch Parametrisierung):

• DIREKT-BANF Die Kundenauftragsposition soll –unabhängig von der Bestands- und Verfügbarkeitssituation – direkt für diese bestellt werden. Dafür wird eine entsprechende BANF maschinell erzeugt. Es wird eine Verbrauchs-BANF“ mit KORE-Kontierung auf Kundenauftragsnummer / -position erstellt.

•  STRECKEN-BANF Diese ist ebenfalls KORE-mäßig auf die Kundenauftragsposition kontiert, übernimmt aber als Lieferadresse den Warenempfänger dieser Kundenauftragsposition. Zur Faktura bleibt diese Position gesperrt, solange nicht entweder die Lieferung mit einer WE-Meldung zur Bestellung bestätigt oder die Erfassung der Eingangsrechnung zur Bestellung erledigt wurde. Im Firmenmandant kann definiert werden, ob auch ein Lieferschein gedruckt werden soll.

•  Strecken-BANF manuell: Eine Strecken-BANF kann natürlich auch manuell abseits der Kundenauftragsanlage angelegt werden. Sie bekommt einen eigenen „Beschaffungstyp“ („S“), der bewirkt, dass eine KORE-Kontierung auf Kundenauftragsnummer / -position maschinell verlangt wird und dass maschinell der Warenempfänger der Kundenauftragsposition als Rolle Lieferadresse in der BANF- und später Bestellposition übernommen wird.

 

Beide BANFen können per Button in der Kundenauftragsposition manuell ohne weitere manuelle Tätigkeiten angelegt werden.

 

1.3 BEZUGSQUELLENFINDUNG für LIEFERANT und PREIS

 

Pro mit Materialnummer angelegten BANF wird eine maschinelle Bezugsquellenfindung wie folgt durchgeführt:

• Suchen, ob für diese Materialnummer 1-n eine gültige Angebots-/Kontraktpositionen existieren. Wenn ja: Selektion der Position mit der höchsten Priorität. Bei mehreren Positionen der gleichen Priorität wird die mit dem niedrigsten Nettopreis ausgewählt. Wenn nein, können die Daten der letzten Bestellung (Lieferant / Preis) für diesen Artikel übernommen werden, so weit diese Bestellung nicht länger als n Tage (parametrisierbar) zurück liegt.

• der Lieferant laut selektierter Position wird in die BANF als „präferierter Lieferant“ übernommen

• als Parameter für den etwaigen Freigabeworkflow wird auch der Preis und Wert in statistische Felder der BANF übernommen.

 

Bei Bestellanlage ist der Lieferant und die Währung vordefiniert. Pro Position wird daher nach Angeboten / Kontrakten / letzte Bestellungen mit gleichen Lieferant / Währung gesucht.

 

1.4 MASCHINELLE BESTELLERSTELLUNG

 

Sowohl am Lieferanten wie am Materialstamm kann ein KZ gesetzt werden, dass die BANF für dieses Material, das über die Bezugsquellenfindung Lieferant und Preis zugeordnet bekam , mittels eines eigenen Jobs „Umsetzen BANFen in Bestellung“ maschinell in Bestellungen umgewandelt werden. Diese umgesetzten Bestellungen werden am Bildschirm protokolliert , können dort durch Doppelklick nochmals aufgerufen und u.U. auch geändert werden. Auf Firmen- / Standortmandantenebene kann definiert werden , dass aus Kundenauftragspositionen generierte BANFEN immer dieses „automatische Bestellerstellungs-KZ“ bekommen

 

1.5 FREIGABEVERFAHREN BANF

 

EMASOS kann kundenindividuelle mehrstufige Freigabeverfahren mit dem Standard-Workflow-Tool einrichten. Klassische Parameter sind dabei:

• maschinell / manuell angelegt

• Kostenrechnungskontierung

• geschätzter Betrag

•  Warengruppe

 

1.6 BEARBEITEN BANF

 

Die zuständigen Logistiker- / Einkaufsreferenten bearbeiten die am Bildschirm angebotenen offenen BANF mit folgenden Möglichkeiten – sie haben dabei die Möglichkeit, sich Materialbestände / Lieferantenangebote / -kontrakte und die Bestellhistorie anzusehen

 

•  Änderungen:

 

o Menge

o Termin

o präferierter Lieferant

o Materialnummer (vor allem wenn keine eingegeben wurde)

o Kontierung

 

• Umwandeln in Bestellung Selektierte BANFEN (gruppiert pro präferierter Lieferant) können in eine Bestellung umgewandelt werden. Dabei werden etwaig vorhandene Angebots- / Kontraktpreise und Konditionen maschinell in die Bestellung übernommen – sie sind dort änderbar. Wird die BANF-Position und die sich daraus entwickelte Bestellposition von einem Angebot mit der Kategorie „Lieferantenkontrakt“ abgeleitet, wird die relevante Lieferkontraktposition in die Bestellposition übernommen. Daraus kann ein Kontrakterfüllungsreport entwickelt werden

• Verbrauchs-BANF: Wenn der Logistiker / Einkäufer bestimmt , dass eine Verbrauchs-BANF nicht eingekauft, sondern direkt vom Lager bezogen werden soll, kann er diese in einen Bedarfssatz umwandeln. Dieser verringert einerseits die Verfügbarkeit am Lager (gemäß Lagerkoordinaten) und initiiert die interne Auslieferung zum definierten Termin.

 

1.7 UBANF

 

Die UBANF kann maschinell aus der Dispo oder manuell erzeugt werden. Ein Standort / Lager fordert für ein Material zu einem bestimmten Termin eine definierte Menge von einem anderen Standort / Lager an. Dies kann nicht nur für den anonymen Bestand , sondern auch für Einzel-, Sonderbestandsarten gelten.

 

Diese UBANF ist nicht für den Einkauf und eine nachfolgende Bestellung geeignet / vorgesehen, sondern ist der Träger für Bedarfssätze (siehe später) - „echter“ Bedarf für den sendenden und „geplanter Zugang“ für den empfangenden Standort / Lager.

 

Maschinelle „Umwidmung“ Lagerkoordinaten“ Werden vom empfangenden Standort / Lager Sonder- / Einzelbestände angefordert, wird geprüft, ob diese im sendenden Standort / Lager verfügbar sind. Wenn nicht , wird vor der Erstellung des Lagerplatzbuchungsbelegs eine Umwidmung vom anonymen Bestand in den angeforderten Sonder- / Einzelbestand vorgenommen. Wird dabei auf einen Einzelbestand umgewidmet , erfolgt auch eine entsprechende Bewertung. Erfolgt dabei ein Wechsel des Bestandskontos (laut maschineller Kontofindung) , wird ein entsprechendes GFD abgesetzt.

Sendender Standort = empfangender Standort: (klassischer Fall: Servicetechniker fordert Umlagerung für sein Autolager)

 

Mit Absetzen der UBANF wird ein „Lagerplatzbuchungsbeleg“ (Kommissionieranforderung – siehe späteren Punkt) abgesetzt, der – im Falle der Verfügbarkeit - zu einer physischen Umbuchung vom sendenden Lager in die WE-Zone (Lagerplatz) des empfangenden Lagers führ. Die entsprechende Bestandsbuchung wird mit „Quittieren“ des Lagerplatzbuchungsbelegs im Hintergrund durchgeführt. Die beiden Bedarfssätze werden inaktiv gesetzt.

 

ACHTUNG: Ist das empfangende Lager in den Lagerparametern als eines mit „Lieferbelegzwang“ definiert, wird statt der sofortigen Umbuchung der Prozess wie bei wechselndem Standort angesteuert.

 

Beispiel: Umlagerung von Hauptlager auf Lager externe Kundenkonsibestände / Montage- /Baustellenbestellungen – das empfangende Lager ist zwar dem gleichen Standort zugeordnet , die Ware dorthin muss aber extern transportiert werden. Dazu brauch man einen Lieferschein, der wiederum nur aus einem Lieferbeleg erstellt werden kann. Sendender Standort ungleich empfangender Standort: (klassischer Fall: Standort A fordert vom Hauptstandort B Material an)

 

Der im Rahmen der UBANF erzeugte „echte“ Bedarfssatz initiiert einen Lieferbeleg, dieser wiederum einen Lagerplatzbuchungsbeleg zur Kommissionierung. Danach kann der Lieferschein erzeugt werden , was wiederum zur (maschinellen) Umbuchung sendender Standort / WA-Zone in den Sonderbestand Transitbestand des empfangenden Standort führt.

Mit Einlangen der Ware im empfangenden Standort werden die (vorher kontrollierten) Positionen unter Angabe der Lieferbelegnummer (, die am Lieferschein angeführt ist) am Bildschirm aufgelistet und vom Transitbestand in die WE-Zone des angegebenen Lagers umgebucht. Diese Umbuchung erfolgt auf den Einzel- / Sonderbestand, der in der UBANF als empfangend angegeben wurde.

 

 

 

SPEZIELLE FUNKTIONEN KUNDENAUFTRAGSABWICKLUNG

 

1. ROLLEN-KONZEPT:

 

Jeder Kundenauftrag (Kopf / Position) kann mehrere und unterschiedliche Rollen annehmen. Es gibt Standradrollen, die vordefiniert sind – jeder Anwender kann aber zusätzliche Rollen definieren. Rollen, die im Kopf geführt werden, können auf die Positionen vererbt werden, sind dort aber manuell änderbar.

 

MUSS-ROLLEN für den Kundenauftrag sind:

 

o Auftraggeber – wird auf AB angeführt – wird auch in Umsatz- und Ergebnisstatistiken geführt

o Warenempfänger – wird auf Lieferschein angedruckt

o Rechnungsanschrift – Adresse auf Rechnung

o FIBU-Nummer – Kundennummer für FIBU-Beleg (Faktura)

 

Diese Rollen können auch im Kundenstamm hinterlegt werden, was deren Vorschlag im Kundenauftragskopf bewirkt.

 

KANN-Rollen – im Prinzip können beliebig viele andere Rollend definiert werden. Im Auslieferungs-System werden noch folgende Rollen für den Kundenauftrag angeboten:

  • Logistiker – organisiert den Transport
  • Spediteur – führt den Transport durch
  • Provisionär – bekommt etwaige Provision für diesen Kundenauftrag

 

2. SONDERFUNKTIONEN KUNDENAUFTRAG

 

• Verpackungsmenge: Jedem Material können ein oder mehrere Verpackungsvorschriften zugeordnet werden: In dieser wird definiert, wieviel Mengen der ME Materialstamm in einer Verpackung Platz haben + die Mengeneinheit dieser Verpackung. Ist die Verpackung als „Produktverpackung“ definiert , muss die Verpackungsmenge immer ganzzahlig sein – die Auftragsmenge in der ME des Artikels muss darauf abgestimmt werden. Andernfalls ist es eine „Überverpackung“ (z.B. Palette oder Sammelkarton), in der mehrere unterschiedliche Materialien zusammen verpackt werden können

 

• Erweiterte Datumslogik In vielen Fällen genügt die Angabe eines „Wunschlieferdatums“ pro Position. Das wird dann als dieses Datum interpretiert, zu dem die Ware zum Kunden geliefert werden soll. Aus zwei Gründen kann dies nicht genügen:

 

o Kunde soll in Auftragsbestätigung das voraussichtliche Ankunftsdatum der Ware bei ihm (und nicht das Abgangsdatum vom Lager) bekommen)

 

o es wird eine Termintreue_Auswertung erwünscht, aus der hervorgeht:

• welches Lieferdatum hat sich der Kunde ursprünglich gewünscht

• welches Lieferdatum wurde Kunde bestätigt

• welches Lieferdatum ist laut letztem Wissensstand aktuell

 

Diese Dati abgehend können mit dem Ist WA-Datum verglichen werden.

Daher ist diese Funktion in Emasos IQ wie folgt designt:

 

Es gibt im Kundenauftrag pro Kategorie (Wunsch, bestätigt, aktuell) jeweils zwei Lieferdati

 

abgehendes Datum: wann verlässt Ware das Lager des Auftraggebers oder des Lieferanten (Abdeckung Bedarf durch Streckenbestellung) (WLDAB) = relevantes Datum für Disposition (Bedarfssatz aus Kundenauftragsposition) , Lieferrelevanz und Lieferdatum für Streckenbestellung. Bei letzterer wird ausgehend vom Lieferdatum eingehend am Kundenauftrag die Liefertage Lieferant – Kunde abgezogen – daraus ergibt sich das Lieferdatum der Streckenbestellung. Daher braucht

man auch am Lieferantenstamm den Eintrag durchschnittliche Liefertage von Lieferant zum Kunden

 

• eingehendes Datum: wann langt Ware beim Warenempfänger ein (WLDEIN) Dieses Datum wird Kunden in AB bestätigt. Beide Datümer gibt es am Kopf und in den Positionen. Eine Eingabe im Kopf überschreibt immer die Positionsdaten. Wird ein Datum (egal ob in Kopf oder Position eingegeben, wird das andere errechnet. Werden beide manuell gepflegt, gibt es keine Berechnung .

Für die Berechnung des Datums gibt es zwei gleichartige Datenfelder „Default Differenztage zwischen ausgehendem und eingehendem Lieferdatum“ im

• Firmenmandant

• Kundenstammsatz – Daten Firmenmandant - Verkauf

•  Lieferantenstamm – Daten Firmenmandant - Einkauf

 

Bei der maschinellen Bestimmung wird zuerst der Eintrag des Kundenstamms und – falls dieser leer ist – der des Firmenmandanten genommen.

 

Positionen weder bestands- / noch lieferrelevant

In der Regel handelt es sich dabei um Dienstleistungen , die entweder nach Erbringung dieser (z.B. Festpreis für Reparatur) oder in Zusammenhang mit einer Warenlieferung (z.B. Transportkostenverrechnung , wenn entsprechende Waren geliefert wurden) fakturiert werden sollten . Im ersteren Fall kann man ein „wahrscheinliches Fakturendatum“ pflegen (= Zeitpunkt, von dem man glaubt, dass Leistung erbracht wurde) , im zweiten Fall die Kundenauftragsposition definieren, mit der diese Dienstleistung mitfakturiert werden soll.

In beiden Fällen werden sogenannte „Faktureninitialsätze“ (siehe nächstes Kapitel) mit obigen Informationen (wahrscheinlicher Fakturierungstermin / dazugehörige Kundenauftragsposition) weggeschrieben. Sie sind aber zur Fakturierung gesperrt. Zum „wahrscheinlichen Fakturendatum“ wird die Fakturierung mittels Bildschirmauswertung „angemahnt“ – de zuständige Verkaufsreferent entscheidet, ob fakturiert oder der „wahrscheinliche“ Termin nach hinten verschoben wird. Anlässlich der Fakturierung von lieferrelevanten und / oder bestandsgeführten Positionen wird maschinell überprüft, ob es zu dieser Kundenauftragsposition zugeordnete Faktureninitialsätze gibt. Wenn ja, werden diese mitfakturiert.

 

KONSTELLATION MASCHINELLE BESTIMMUNG SONDERBESCHAFFUNGSART

Bestände von Sonderbestandsarten, die bewusst bestimmten Kunden zugeordnet sind (so im Standard vor alle die Sonderbestandsarten KUNRES und KKONS ) , werden nur durch Bedärfe und anschließenden Lieferungen durch Kundenaufträge an diese Kunden verwendet und aufgelöst. Diese sind in einer eigenen Tabelle definiert.

Daher wird bei Anlage einer bestandsrelevanten Kundenauftragsposition geprüft, ob für diese Sonderbestandsarten Bestände vorhanden sind, die dem Auftraggeber des Kundenauftrags gewidmet sind. Wenn ja, wird die Sonderbestandsart und Spezifikation in der Kundenauftragspositron maschinell auf diesen Sonderbestand „kontiert“ .

 

3. VERKNÜPFUNG mit DISPOSITION:

ERSTELLEN BEDARFSSÄTZE aus KUNDENAUFTRAGSPOSITIONEN

 

Für jede lieferrelevante Position wird ein Bedarfssatz mit dem Dispotyp „D“ erstellt (siehe auch Kapitel Disposition). Dieser hat neben der Funktion, den verfügbaren Bestand zu verringern und damit eine etwaig notwendige Nachbeschaffung auszulösen auch die Funktion des Initiieren einer „Lieferbelegposition“. Ist die Kundenauftragsposition liefer- und bestandsrelevant, hat der Bedarfssatz die Funktionen „liefer- UND disporelevant“. Ist  diese nur lieferrelevant, ist auch der Bedarfssatz nur lieferrelevant. Die wichtigsten Informationen dieses Bedarfssatzes sind:

• Lagerkoordinaten, für die Bedarf reserviert wurde und von denen für die Lieferung kommissioniert und ein WA gebucht werden soll.

•  Angaben an wen / wohin geliefert / umgelagert werden soll (Warenempfänger)

• Artikelnummer

• Menge

•  disporelevantes Lieferdatum (= aktuelles Lieferdatum abgehend)

 

4. MIET- / WARTUNGSVERTRÄGE

 

Als (aufgebohrten) Spezialfall zum Kundenauftrag gibt es Miet- / Wartungsverträge. Pro Position können ein bis n Einzelgeräte (Serialnummernobjekte) zugeordnet und für diese periodisch wiederkehrende Fakturenbeträge für Miete / Wartung (mit eingrenzbarer Laufzeit) vereinbart werden. Intern werden für jeden geplanten Fakturentermin Faktureninitialsätze erzeugt, die zu den jeweiligen Terminen in Fakturen umgewandelt werden. Die Miet- und Wartungspositionen sind KORE-relevante Objekte, sodass die Kosten die für die Miete / Wartung anfallen (interne , externe Leistungen, Materialverbräuche , FIBU-Buchungen (z.B. Energie) , auf diese gebucht und mit den erzielten Erlösen kumuliert über die Laufzeit verglichen werden können.

 

5. LIEFERBELEG

 

Alle Materialpositionen, die einen Lieferschein / Begleitpapier,.. brauchen, müssen als Positionen in einem Lieferbeleg aufscheinen. dieser muss daher in folgenden Fällen angelegt werden :

 

• Lieferung an externe Kunden auf Basis Kundenauftrag

•  Lieferung an einem anderen Standort auf Basis UBANF

•  Lieferung an ein anderes Lager des gleichen Standorts, bei dem ein Transport mit Begleitpapieren erfolgen muss (z.B. Beschickung eines Kundenkonsilagers beim Kunden) auf Basis UBANF

•  Lagerverbrauch für KORE-Objekt (Kostenstelle / Vorhabennummer / Kundenauftragsnummer / -position basierend auf BANF (, die von Logistiker in einen Bedarfssatz (vulgo Reservierung) umgewandelt wurde

•  auf Basis einer Streckenbestellung soll ein Lieferschein (mit den Chargen, die der Lieferant gemeldet hat) an den Kunden erzeugt werden – Basis = Streckenbestellung

 

Lieferbelege werden ausschließlich durch Bedarfssätze initiiert. Daher wird in all den obigen Fällen maschinell entsprechende Bedarfssätze erzeugt.

 

Nicht zur Lieferung gesperrten Bedarfssätze werden nach ihren Adressaten (z.B. Warenempfänger) und Lieferbedingungen sortiert und pro Adressat/ Lieferbedingung ein entsprechender Lieferbeleg erzeugt – zugleich wird eine statische Bestandsprüfung durchgeführt und das Ergebnis in die Lieferbelegposition übernommen.

In den Lieferbelegpositionen werden im wesentlichen die Daten aus den Bedarfssätzen – ergänzt um notwendige Daten aus den Kundenauftragspositionen übernommen.

Mit der Anlage werden für bestandsgeführte Lieferbelegpositionen „Lagerplatzbuchungssätze“ (siehe dort) als Anker für die Kommissionierung der Waren aus dem Hauptlager in die WA-Zone erzeugt. Der Anwender kann sich die erzeugten Lieferbelege am Bildschirm anschauen und gegebenenfalls noch ändern.

Mit einer eigenen Funktion können auch die fälligen , aber zur Lieferung gesperrten Bedarfssätze mit relevanten Informationen aus den dazugehörigen Kundenauftragspositionen angezeigt und – bei entsprechender Berechtigung die Liefersperre im Kundenauftrag und damit auch auf den Bedarfssätzen aufgehoben werden.

 

6. KOMMISSIONIERVORSCHLAG

 

Der Lagerplatzbuchungsbeleg erhält die Information , welche Materialien pro Lieferbelegposition in welcher Menge gemäß der Lagerkoordinaten des Lieferbelegs in die WA-Zone kommissioniert werden sollen. Je nach Lagerorganisation und Parametrisierung werden maschinelle Vorschläge erstellt, von welchen Lagerplätzen welche Chargen (wenn Material chargengeführt) und / oder Serialnummern (wenn Material ist serialnummerngeführt) kommissioniert und in die WA-Zone gebracht werden sollen. Folgende Strategien sind derzeit implementiert:

 

CHARGEN und SERIALNUMMERN

FIFI (first in first out)

 

CHARGEN

LIFO (last in first out)

FEFO nach Verfalldatum

 

Zusätzlich gibt es die parametrisierbare Funktion „leeren Lagerplatz“ . Diese bewirkt, dass , wenn aufgrund obiger Methoden eine Entnahme einer bestimmten Menge / Serialnummer von einem bestimmten Lagerplatz vorgeschlagen wird, geprüft wird, ob noch zusätzliche Mengen des Materials auf diesem Lagerplatz liegen. Wenn ja, werden diese (bis zur Höhe der angeforderten Liefermenge) ebenfalls vorgeschlagen.

KEINE LAGERPLATZORGANISATION Hat der Anwender keine „chaotische“ Lagerplatzorganisation, ist sein Default-WA-Lagerplatz gleich dem Default-Hauptlagerplatz. In diesem Fall erstellt das System eine Vorschlagszeile pro Lieferbelegposition . Wenn im Materialstamm – Lager ein „“fester Lagerplatz“ gepflegt ist, wird diese Info in den Lagerplatzbuchungsbeleg übernommen , um den Kommissionierer diesbezüglich zu unterstützen.

In allen Fällen kann der Anwender offene Lagerplatzbuchungsbelege selektieren, ausdrucken, auf seinem mobilen Gerät sich anzeigen lassen oder an ein externes Lagerplatzsteuerungssystem downloaden. Diese Informationen sind somit die Basis für den physischen Kommissioniervorgang.

 

ÄNDERUNGEN LAGERPLATZBUCHUNGSBELEG

Entnimmt der Kommissionierer andere Mengen aus anderen Lagerplätzen und anderen Chargen / Serialnummern , muss er die entsprechenden Änderungen im Lagerplatzbuchungsbeleg eintragen (mit Barcodeunterstützung).

QUITTIEREN LAGERPLATZBUCHUNGSBELEG

Nach Erledigung der physischen Entnahme, Kommissionierung in die WA-Zone und etwaigen Änderungen im Lagerplatzbuchungsbeleg werden diese „quittiert“, was die mengenmäßige Umbuchung dieser von/auf Lagerplatz im System bewirkt.

Die kommissionierten Mengen werden auch in der Lieferbelegposition eingetragen.

 

7. RÜCKSTANDSFUNKTIONEN RÜCKSTANDSBILDUNG

 

Ist die kommissionierte Menge kleiner als die angeforderte Liefermenge (laut Kundenauftragsposition) hängt die weitere Vorgehensweise vom Rückstandskennzeichen auf der Lieferbelegposition ab. Ist dieses „J“ (aus Kundenstamm oder manuellem Eintrag in Kundenauftragsposition bzw. Lieferbelegposition) , wird wie folgt ein Rückstand gebildet:

•  der die Lieferbelegposition auslösende Bedarfssatz wird nicht inaktiv gesetzt, sondern bleibt mit der Differenzmenge „Liefermenge minus kommissionierte Menge“ und einem gesetzten Rückstandkennzeichen aktiv.

 

Ist das Rückstandskennzeichen in der Lieferbelegposition ungleich „J“ wird diese trotz Differenz Liefermenge zu kommissionierter Menge auf „endkommissioniert“ gesetzt.

 

RÜCKSTANDSAUFLÖSUNG

Bei jedem Wareneingang wird geprüft, ob es für dieses Material aktive Bedarfssätze mit Rückstandskennzeichen „J“ gibt. Wenn ja, wird de zuständige Verkaufsreferent von diesem WE per eMail verständigt. Dieser entscheidet, ob die Materialposition direkt von der WE-Zone in die WA-Zone umgelagert wird und erzeugt auf Basis des Rückstands-Bedarfssatzes einen Lieferbeleg.

Periodische Auswertung: Jeder Verkaufsreferent prüft in periodischen Abständen , ob für „seine“ Bedarfssätze mit Rückstandskennzeichen genügend Bestand vorhanden ist. Wenn ja, erzeugt er für diese entsprechende Lieferbelege.

 

8. GUTSCHRIFTEN

 

Mit Referenz auf eine Rechnung können Mengen- und Preisgutschriften erstellt werden. Auf Basis der Originalrechnung werden die „gutzsuschreibenden Positionen selektiert und in den neuen Gutschriftsbeleg kopiert.

Mengengutschrift: Es werden keine Mengen , nur die Preise und Konditionen kopiert –die Mengeneingabe erfolgt manuell, darf aber nicht größer als ursprüngliche Mengenänderung sein.

Werden die Materialien zurückgeliefert, erfolgt zunächst die Eingangsbuchung auf das Default-Lager „Retourenbestand“. Dort werden sie entweder vernichtet oder auf ein „echtes“ Lager umbgebucht.

Preisgutschrift: Es werden die Mengen, aber keine Preise / Konditionen mitübernommen. Diese müssen manuell eingegeben werden. Pro Position darf aber der Nettowert nicht größer als der der ursprünglichen Rechnungsposition sein.

Aus diesen „Gutschriftsanforderungen“ werden mit dem Sichern entsprechende Faktureninitialsätze erzeugt , die wie oben beschrieben zu Fakturenbelegen und GFD umgewandelt werden. Vorher kann noch ein Genehmigungsworkflow eingebaut werden.

 

9. ZAHLUNGSKONTROLLBELEGE

 

Manche mittelständische Unternehmen (oft mit ausgelagerter Finanzbuchhaltung) wollen die termingerechte Zahlungseingänge in ihrem Vertriebssystem erfassen und kontrollieren.

Pro Faktura wird auf Kundenebene ein Zahlungskontrollsatz mit dem Typ „Rechnung“ maschinell erstellt. Das Vorzeichen seines Betrags ist positiv (wie in der FIBU gleich Soll). Im Fall einer Gutschrift ist das Vorzeichen negativ.

Der Anwender erfasst eingehende Zahlungen des Kunden ebenfalls als Zahlungskontrollsatz mit dem Typ „Zahlung“ – Betrag = negativ. Mit dieser Erfassung können die offenen Rechnungen / Zahlungen angezeigt werden. Durch Markieren dieser werden sie der jeweiligen Zahlung zugeordnet. Ist der Saldo 0 erfolgt ein Ausgleich der Zahlung und der selektierten Positionen (Status + eindeutige „Ausgleichszahl“ für alle am Ausgleich beteiligten Positionen.

Mit besonderer Berechtigung kann man auch „Zwangsausgleiche“ ohne Saldo 0 zur „Bereinigung“ der Zahlungskontrollbelege erzwingen.

Eine Auflistung der offenen überfälligen Positionen ist vorgesehen, eine klassische FIBU-Mahnung nicht.

 

 

 

PROFESSIONELLES VORHABEN- und AUFGABENMANAGEMENT

 

Das Vorhaben hat in Emasos IQ multifunktionale Anwendungsmöglichkeiten:

 

• Kostensammler

 Das Vorhaben ist dabei ein Kontierungsobjekt der Kostenrechnung , um Kosten für bestimmte Ereignisse / Objekte getrennt zu planen und zu verfolgen. Die Ist-kosten können an Kostenstellen / Kundenauftragspositionen abgerechnet werden. Weiteres ist jedes Vorhaben einem Profit-Center zuzuordnen – die Vorhaben-Ist-kosten werden dort mitlaufend fortgeschrieben. Beispiele: Marketingaktion, Messeauftrag / Investitionen (Kosten werden durch Umbuchung in den Anlagenbestand übernommen) / kleinere Projektvorhaben, Fahrzeuge,…

• Bestandsführendes Kundenvorhaben

 speziell für Projekt- und Anlagenfertiger – aber auch für Montageaufträge,… können Materialbestände vorhabenspezifisch – getrennt vom „normalen“ anonymen Bestand – als „Vorhabeneinzelbestand“ (siehe Bestandskategorien) geführt werden. Dazu muss bei allen Bestandsbuchungen (angefangen von de BANF / Bestellung / Kundenauftrag) das Kennzeichen Einzelbestandskennzeichen auf „V“ und die Vorhabennummer als Spezifikation angegeben werden. Mit der Abbuchung vom Projektbestand wird dieser einerseits verringert und anderseits die Kosten (Verbrauch) auf das Vorhaben kontiert gebucht werden.

• Reparatur-/ Instandhaltung- / Produktionsauftrag

 Das Vorhaben ist der Anker für die Planung und Isterfassung von „Durchführungsvorhaben“ wie Produktions-, Instandhaltungs-, Reparaturauftrag. Darunter können „Materiallisten“ (vulgo Stücklisten), Leistungspläne (vulgo Arbeitspläne) mit Vorgängen (Planung der verschiedenen Phasen mit Vorgabezeiten und Terminierung), Ressourcenzuordnungen zu diesen (Kapazitätsplanung) bis hin zur Einzelressourcenzuordnung (Personal- Maschinen-, Werkzeugeinsatzplanung) hängen. All dies sind Basisinstrumente der Kostenplanung für dieses Vorhaben. Aufgrund derer werden auch Arbeitspapiere für die Durchführenden Werker erstellt (auch auf mobile Devices) , die wiederum die Grundlage für die Rückmeldungen und damit Materialverbrauchs- und Leistungsbuchungen sind.

Projektfunktionen

Das Vorhaben kann aber auch – ausgehend von einem Header - in beliebige Ebenen mit beliebiger Breite in „Vorhabenelemente“ strukturiert werden. Jedes Element kann mit Plan- / Prognose-/Istterminen (jeweils Anfang und Ende bzw. einer von diesen + Dauer) bestückt werden. Zusätzlich können pro Vorhaben drei Referate mit jeweils einen Referenten als für verschiedene Kategorien „Verantwortliche“ definiert werden (z.B. kfm., technischer und Durchführungsverantwortlicher) bestimmt werden. Jedes Vorhabenelement kann vorkalkuliert werden. Ebenso kann jedes Vorhaben als Objekt der Kostenrechnung ein Kontierungsobjekt für Istkosten sein. Bestimmte Parameter im Vorhabenstammsatz erlauben auch eine Bestandsführung auf Vorhabenelemente-Ebene. Die Kostendaten werden im Reporting von unten nach oben in der Hierarchie verdichtet.

 

MASCHINELL UNTERSTÜTZTE AUFGABEN- und TERMINSTEUERUNG

 Für jedes Vorhaben können n Aufgaben / Aufgabenpakete mit bestimmen Auftragsverantwortlichen angelegt werden – der Start-/Endtermin kann in Relativtagen zu und damit abhängig von Vorhabenterminen oder in % zur Vorhabendauer indirekt definiert werden.

Neben der rein manuellen Anlage der Vorhabenaufgaben können vorhabenneutrale Aufgaben / Aufgabenpakete definiert werden. Auf diese kann man sich bei manueller Anlage beziehen, sodass diese in das Vorhaben übernommen werden. Weiteres können Standardvorhaben / Vorhabenpakete maschinell in Vorhaben übernommen werden:

o anlässlich der Vorhabenanlage aufgrund der Angabe einer Standardaufgabe / Aufgabenpaket als Parameter in der Vorhabenart / -unterart.

o In der Aufgabe selbst kann definiert werden, welche Aufgaben (1-3) nach Fertigmeldung dieser aktiviert werden sollen (Standardaufgabeketten)

o Im Anwenderstatus (beliebig definierbar) kann festgelegt werden, welche Standardaufgabe übernommen werden soll, wenn der Anwenderstatus gesetzt wird

o Umgekehrt kann in der Aufgabe definiert werden, welcher Anwender- / Systemstatus nach deren Fertigmeldung gesetzt werden soll

 

Die Aufgaben erscheinen für den Auftragseigner wie EMASOS-Aufgaben auf der rechten Bildschirmseite – sortiert nach Start-Termin. Auf Wunsch wird der Start-Termin auch im EMASOS-Kalender eingetragen. Außerdem gibt es eine mobile Funktion zur Fertigmeldung der Aufgabe.

Pro (Standard)Aufgabe kann in „der Mahnstufen“ definiert werden, nach wie viel Terminüberzugstage (Planendtermin) welches Referat / Referent von diesem Terminüberzug verständigt werden soll (Medium derzeit nur e-Mail).

Ebenso können die maximal drei Verantwortlichen eines Vorhabens verständigt werden, wenn Plan-Endtermine überschritten werden.

 

TICKETINGSYSTEM für EXTERNES und INTERNES SERVICE

 

Das Ticket ist ein Objekt speziell für Service- / Wartungs- und Reparaturgeschäftsfälle.

 

 Es entsteht aus einer entsprechenden Meldung eines Kunden / internen Mitarbeiter, der von der Service- / Wartungs- / Instandhaltungs- / IT- / Facility-Abteilung,.. eine entsprechende Leistung anfordert – oft auch in Verknüpfung mit einem Wartungsvertrag bzw. einem Einzelobjekt (Maschine / Gerät,..) (innerhalb des Unternehmens oder ein Kundengerät. Im Ticket wird diese Anforderung beschrieben, Prioritäten, Termine und Verantwortliche festgelegt. Der Ausführende meldet auf das Ticket alle mit der Abwicklung verbundene Aktivitäten zurück. (wie z.B. Zeiten inkl. Reisezeiten, verbrauchte Materialien, ausgetauschte, kaputte Teile,…). In Emasos IQ gibt es eine spezielle Ticketverwaltung, Abwicklungssteuerung, -kontrolle, Workflowbenachrichtigungen und Reporting für Tickets. Von der Ticketmeldung bis zur Erledigungserfassung sind alle Ticketfunktionen auch auf mobilen Endgeräten und im WEB abwickelbar.

Integration Ticket mit Emasos IQ-LOGISTIK: Alle aus den Tickettransaktionen ableitbare logistische Geschäftsfälle wie z.B.:

 

• BANF / UBANF

• Materialverbrauch aus Technikerlager

• Stundenerfassungen

 

werden im Hintergrund sofort durchgeführt. Die Ticketnummer kann auch auf allen logistischen Belegen (Bestellung / Kundenauftrag / Lieferungen / Fakturierungen,..) statistisch als zusätzliches Info-Element mitgeführt werden.

Ticket und Kostenrechnung: Das Ticket selbst ist kein direktes Objekt der Kostenrechnung. Umgekehrt werden viele kostenrechnungsrelevante Geschäftsfälle im Ticketsystem erfasst. Daher ist es notwendig, pro Ticket eine kostenrechnungsrelevante Kontierung (siehe Punkt Schnittstelle Rechnungswesen) zu hinterlegen, die für diese Geschäftsfälle verwendet werden kann.

Diese Kostenrechnungskontierung kann:

• maschinell vergeben werden, wenn sich Ticket auf eine Wartungsvertrags- oder Kundenauftragsposition bezieht manuell bei Ticketanlage (Dispatcher) gepflegt werden

• wenn obige Fälle nicht zutreffen:  Kostenrechnungsrelevante Buchungen werden auf eine pro Firmen- / Standortmandant zu definierende Zwischen-Kostenstelle gebucht, von wo sie durch das Controlling auf die betriebswirtschaftlich relevanten Kontierungen umgebucht werden müssen.

 

DURCHGÄNGIGES KLASSIFIZIERUNGSSYSTEM

Für alle EMASOS-Objekte kann eine Klassifizierung mithilfe von Klassen / Klassenhierarchien und Merkmalen für jedes Objekt ohne Zusatzprogrammierung / -customizing aufgebaut werden. Merkmalsausprägungen können über Links zu Tabellenfeldern maschinell gefüllt werden. Die Suchreihenfolge wird bei den Klassen benutzerindividuell definiert. Beispiele für den Klassen- und Merkmalseinsatz:

 

• Materialstamm

• Vorhaben

• Sachkontenfindung

• Profit-Center-Findung

• Mehrwertsteuerkennzeichenfindung

• Konfiguration

• Defaultparameter für User (Firma, Standort, Referat-Referent,…) – werden in Applikationen maschinell vorgeschlagen

 

Die oben angeführten „Findungsmethoden“ über Klassifizierung bedeutet, dass der fachkundige, aber EDV-ferne Fachbereichsmitarbeiter die entsprechenden Einstellung zur Findung obiger Objekte selbst vornehmen kann.

 

FIBU-SCHNITTSTELLE für LOGISTIK-GESCHÄFTSFÄLLE &

MITLAUFENDE KOSTENRECHNUNGSFUNKTIONEN

1. GESCHÄFTSFALLDOKUMENT als SCHNITTSTELLENPLATTFORM

 

EMASOS IQ-R2 Logistik beinhaltet keine klassischen Rechnungswesensfunktionen aus, sehr wohl aber einen softwareneutralen Schnittstellenmodul.

 Jeder Geschäftsfall, der im EMASOS-System eine Rechnungswesensaktion erfordert , wird in Form eines (sehr detaillierten) FIBU oder KORE-Belegs (EMASOS-Geschäftsfalldokument (GFD)) dokumentiert und der externen Rechnungssoftware zum Einlesen „angeboten“. Dieser hat folgende Struktur:

• Belegkopf Mit den klassischen Rechnungswesenskopfdaten, wie z.B.:

o Mandantengruppe

o Firmenmandant

o Belegart

o Belegnummer intern / extern

o Belegkopftext

o Währungsschlüssel

o Fixkurs für etwaige Umrechnungen

o Verweis zum EMASOS-Ursprungsbeleg

o u.ä.m.

• Belegpositionen

o Sachkontozeilen

o Materialzeilen – enthält als Sachkonto das Bestandskonto

o Kreditorenzeilen

o Debitorenzeilen

 

mit den klassischen wichtigsten Daten (unvollständiger Auszug)

• Soll-/Haben-Kennzeichen

• Sachkonto – über maschinelle Sachkontofindung (siehe später)

• Kreditorenkonto

• Debitorenkonto

• Materialnummer

• Fremdwährung

• Betrag in Währung des Firmenmandanten

• Betrag in Währung des Konzern

• Betrag in Währung der Mandantengruppe

• Menge

• Mehrwertsteuerkennzeichen gemäß maschineller Findungslogik

• Mehrwertsteuerbetrag (in der Sachkontenzeile)

• Kostenrechnungskontierungen (siehe später)

• Profit-Center – maschinell ermittelt

• Einzelbestandskennzeichen und –spezifikation

• Sonderbestandsart und –spezifikation

• Zahlungsbedingungen

 

 

• Sortierbegriff für Sortierung und Ausgleichsbegriff

o Nachweis der „bewegten Chargen und Serialnummernobjekte

• falls bewertet: mit ihren Bewertungsansätzen

• Leistungstarif – Leistungsverrechnung KORE

• Partnerobjekt KORE im Fall der internen LV

• Personalnummer bei interner LV

 

Bei der Erstellung  werden alle formalen Prüfungen (Sachkonten / Kostenrechnungskontierungen vorhanden und bebuchbar,..) und vor allem eine Cent-genaue Soll-/Habengleichheit-Verprobung durchgeführt. Das GFD ist somit abholbereit für die (beliebige) Rechnungswesenssoftware.

 

Wählt der Anwender als Rechnungswesenssoftware das Produkt der EMASOS-Partnerfirma NOVICON, werden diese Schnittstellen mitgeliefert.

 

Da in den GFD alle fakturenrelevanten Belege mit ihren Detaildaten abgespeichert sind, kann daraus eine einfache Deckungsbeitragsrechnung (DB I – Umsatz und Kosten des Umsatz) nach allen Kriterien, die aus dem Fakturenbeleg / GFD und dem Kunden- / Artikelstamm maschinell ermittelbar sind, maschinell abgeleitet , im EMASOS-Management-Cockpit reported und an den Rechnungswesensmodul als user-definierte EXCEL-Schnittstelle weiter gegeben werden.

 

2. RECHNUNGSWESENOBJEKTE

 

Emasos IQ verwendet – parametrisierbar – folgende Rechnunsgwesenobjekte:

• Sachkonto – und auf Wunsch parametrisierbare Sachkontenfindung

• Mehrwertsteuerkennzeichen inklusive Mehrwertsteuerkennzeichen, -%-.satz und -Betragsfindung

• Profit-Center – inklusive maschineller Profit-Centerfindung

• Kostenstelle

• Leistungstarif auf Kostenstellen

 

Diese Objekte muss der Anwender in der Logistik aus seinem Rechnungswesensmodul maschinell anlegen. Entscheidet er sich für den Einsatz der EMASOS-Partnerfirma NOVICON werden diese Objekte direkt aus dem Rechnungswesensmodul gelesen.

 

3. OBJEKTE der KOSTENRECHNUNG

 

Folgende Objekte der Kostenrechnung kennt das EMASOS-R/2-System:

• Kostenstelle

• Vorhabenelement

• Kundenauftragsnummer / -position

• Ticketnummer – indirekt Dieses wird für Service- / Wartungs- und Reparaturgeschäftsfälle verwendet

 

Diese Kontierungen können nur in G+V-relevanten Buchungszeilen in folgenden Objekten / Buchungen verwendet werden:

• Bedarfsanforderungen

• Bestellungen

• Bedarfssätze – Bedarf (siehe später) – übernommen von übergeordneten Ursprungsbelegen

• Eingangsrechnungen

• Lagerabgangsbuchungen

• Ausgangsrechnungen – basierend auf den Kontierungsvorgaben der Kundenauftragspositionen

•  Interne Leistungsverrechnungen innerhalb der Kostenrechnung

• außerhalb EMASOS-Logistik: FIBU – sonstige Buchungen

 

EMASOS-Logistik prüft diese Kontierungen formal und reicht sie an das etwaige angeschlossene Rechnungswesen über die GFD weiter.

 

4. INTERNE LEISTUNGSVERRECHNUNG in der KOSTENRECHNUNG ABGLEICH KONTIERTE STUNDEN – ANWESENHEITSSTUNDEN

Die interne Leistungsverrechnung spielt sich außerhalb der externen FIBU innerhalb der Kostenrechnung ab.

Im Prinzip erbringt ein Leistungsträger einer Kostenstelle eine mengenmäßig erfasste Leistung an ein gültiges Kostenrechnungsobjekt. Da der interne Leistungsträger etwas „kostet“ , ist man innerhalb der Kostenrechnung bestrebt, diese Kosten an das „verursachende“ Kostenobjekt weiter zu verrechnen (und der leistenden Kostenstelle gutzuschreiben). Diese Leistungsverrechnungen finden oft im Rahmen logistischer Prozesse (Produktion, Instandhaltung, Service, Vorhabenabwicklung,..) statt, sodass EMASOS-Logistik die Erfassung dieser internen Leistungen und deren Verrechnungsbeleg an die empfangende Kostenrechnungseinheit in ihr Funktionsspektrum aufgenommen hat.

Außerdem wollen viele Unternehmen eine Abstimmung zwischen gemeldeten, kontierten Leistungsmeldungen pro Mitarbeiter und deren Summe der Anwesenheitszeiten , die aus der

Zeitwirtschaft gewonnen werden. Da EMASOS ein einfaches Zeitwirtschaftsmodul anbietet, ist diese Abstimmung im Falle eines entsprechenden Einsatzes diese Moduls ein „Abfallprodukt“ im Reporting.

 

PRÄMISSEN und DURCHFÜHRUNG der INTERNEN LEISTUNGSVERRECHNUNGEN PLANTARIF pro KOSTENSTELLE / LEISTUNGSKATEGORIE

 

Jede Kostenstelle, die Leistungen im Sinne der ILV in der Kostenrechnung abgibt und verrechnen will, muss seine Leistungsträger (z.B. Mitarbeiter / Maschinen / Werkzeuge) bestimmten Kostenstellen zuweisen , eventuell in Leistungskostenkategorien (z.B. Facharbeiter / Hilfsarbeiter) einteilen und pro Leistungskategorie die Plankosten pro Leistungseinheit (z.B. Stunde) für eine budgetierte Periode definieren. Das Ergebnis muss im EMASOS-System auf Kostenstelle / Leistungskategorie und von/bis Periode abgespeichert werden.

 

Jeder „leistende“ Mitarbeiter ist verpflichtet, seine Anwesenheit in Form von internen Leistungsverrechnungen auf andere Kostenobjekte oder (im Fall von Regie) auch auf die eigene Kostenstelle zu erfassen.

Im Prinzip erfordert die ILV der KORE sind das folgende Daten:

• Datum der Leistungserbringung

• Leistende Kostenstelle

• Leistungskategorie (Facharbeiterstunde, Helferstunde, Maschinenstunde, gefahrene Kilometer,..)

• Menge

• empfangendes Leistungsobjekt (Kostenstelle / Vorhabenelement / Kundenauftragsnummer / -position)

• Text (Kann)

• Personalnummer / Maschinennummer / Werkzeugnummer (Kann)

 

Der Wert der Buchung ergibt sich aus Menge x Planpreis der Leistungskategorie auf dieser Kostenstelle.

 

In der Kostenrechnung ist jede Leistungskategorie einer internen (sekundären) Kostenart zugeordnet – auch diese muss dem EMASOS-System (ohne maschinelle Kontenfindung) bekannt sein.

Somit kann jede dieser ILV-Erfassungen als zwei Zeilen im GFD dargestellt werden:

• die „Sollzeile (+) „ für die Leistung und Kosten empfangende Einheit

• die „Habenzeile (-) “ für die leistende Kostenstelle

 

In jeder Zeile sind Menge / Kostenart / Text / Personalnummer gleich.

Dieses rein kostenrechnerisches GFD wird von der KORE abgeholt und dort in der „offiziellen“ Kostenrechnung verbucht.

 

Aber auch ohne KORE lassen sich aus den ILV-GFD interessante Auswertungen – speziell für die Abstimmung Leistungsstunden / Anwesenheit , aber auch Reports wie wie viele Stunden pro Leistungskategorie leistet meine Kostenstelle an andere Kostenobjekte und umgekehrt: Wie viel Leistung bezieht ein Kostenobjekt von bestimmten Kostenstellen / Leistungskategorien / Personen-Maschinen-Werkzeug und was kostet dieser Leistungsbezug.

 

Die Leistungserfassung selbst wird oft direkt von Arbeitspapieren oder außerhalb des Unternehmens (Montage / Baustelle / Kundenreparaturen,..) durchgeführt. EMASOS bietet dafür anwenderfreundlichste, kundenindividuell einstellbare mobile Erfassungsoberflächen.

 

 

 

MAKE

IT - DESIGN EMASOS IQ

 

LEARN MORE

BE

MOBILE

 

 

 

LEARN MORE

CLOUD vs.

 ON PREMISE

 

 

 

LEARN MORE

Emasos IQ die auf einer modernen 3-Schichtarchitektur integrierte Lösungen, wie: CRM, ERP, DMS und Reports on Premise oder in einer Private Cloud zur Verfügung stellt.

Es ist eine außergewöhnliche Softwarelösung die dadurch besticht auch komplexeste betriebswirtschaftliche Prozesse einfach für den Anwender und flexibel für das Unternehmen bereitzustellen.

modern working.

WE       ERP