Kontrakte

• Standort Vertrag (Feld POHFCY)

Code des Standorts des Auftragsursprungs (Angebotsanfrage, Einkaufsanfrage, Bestellung, Fremdbearbeitungsauftrag, etc.).
Dieses Feld ist ein Pflichtfeld. Es wird standardmäßig mit dem Einkaufsstandort Ihrer Profilfunktion initialisiert.
Sie können diesen Code ändern, indem Sie einen Code aus der Liste der zulässigen Standorte auswählen.

• Vertragsnr. (Feld POHNUM)

Die Auftragsnummer ist für jeden Auftrag eindeutig. Sie kann so identifiziert werden.

Wird für Kontrakte ein manueller Nummernkreis verwendet, muss auch eine Bestellnummer erfasst werden. Bei Verwendung eines automatischen Nummernkreises wird nach der Anlage eine Nummer zugewiesen.

Bei Duplizierung von Bestellungen mit einem vom Tagesdatum abweichenden Bestelldatum wird der Benutzer dazu aufgefordert, die Preise und Nachlässe gemäß dem neuen Bestelldatum neu zu kalkulieren.

• Nachtragsnr. (Feld REVNUM)

Bei der Nachtragsnummer handelt es sich um die letzte zum offenen Auftrag gespeicherte Nachtragsnummer. Ist der Parameter PURREV Nachtragsverwaltung aktiviert, wird der Benutzer bei Änderungen an unterzeichneten und gedruckten Bestellungen gefragt, ob durch die vorgenommene Änderung ein Nachtrag generiert werden soll.
In diesem Fall werden die alten, geänderten Bestellungsdaten historisiert und die Nachtragsnummer inkrementiert.

• Lieferant (Feld BPSNUM)

Der Lieferantencode muss zwei Bedingungen erfüllen: er muss aktiv sein und darf nicht vom Typ Interessent sein. Funktionalitäten in Verbindung mit diesem Feld:

• direkte Erfassung eines Lieferantencodes, dessen Existenz in der Datei Lieferanten geprüft wird.
• Klicken Sie auf Schnellauswahl Lieferanten über das Symbol Aktionen, um folgendes ausführen zu können:
• Auswahl eines Lieferanten aus der Datei
• Anlage eines Lieferanten in der Datei, sofern entsprechende Benutzerrechte vorhanden sind
• Anzeige der Bemerkungen zum Lieferanten

Handelt es sich beim erfassten Lieferanten um einen Lieferanten vom Typ 'Sonstiger', öffnet sich ein Fenster, in dem die Lieferantenadresse erfasst werden kann. Handelt es sich beim erfassten Lieferanten um einen Lieferanten vom Typ 'Standard', können Sie nach Eingabe des Lieferantencodes die Adresse über das Symbol Aktionen anzeigen und ggf. ändern.

Nach Erfassung des Lieferanten wird möglicherweise eine Meldung ausgegeben, wenn ein Rechtsstreit anhängig ist. Abhängig vom Code des Rechtsstreits im Lieferantendatensatz kann es sich bei dieser Meldung um eine sperrende Meldung oder um einen einfachen Hinweis handeln. 

Wird der Auftrag dupliziert, ist die Änderung des Lieferanten nicht zulässig.

Standortübergreifende Dispositionskontrakte: Zur Verwaltung der Disposition an den Standorten können standortübergreifende Kontrakte angelegt werden:
Referenzieren Sie die Standorte als Personenkonto Kunde und / oder Personenkonto Lieferant. Anfragestandorte werden dabei als Kunden, Dispositionsstandorte als Lieferanten referenziert.

Wird bei Anlage eines Einkaufskontraktes ein standortübergreifender Lieferant erfasst, wird der Kontrakt als standortübergreifend behandelt. Dies bedeutet, dass bei Anlage des Einkaufskontraktes automatisch auch ein zugehöriger Verkaufskontrakt angelegt wird. Dieser Verkaufskontrakt ist zum Einkaufskontrakt identisch. Der zu diesem Verkaufskontrakt gehörige Kunde ist der Kunde des Anfragestandortes, an dem der Einkaufskontrakt geschlossen wurde.

Der Masterkontrakt ist der Einkaufskontrakt. Zu jedem zum Einkaufskontrakt erfassten Lieferabruf wird zum Verkaufskontrakt automatisch eine Lieferanfrage angelegt. Sämtliche Änderungen an einem Lieferabruf werden automatisch in die Lieferanfrage des Verkaufskontraktes übernommen (Mengenänderungen, Abschluss des Lieferabrufs, Löschen des Lieferabrufs). Auf Ebene der Lieferanfrage des Verkaufskontraktes können keine Änderungen vorgenommen werden, da sämtliche Daten über den Einkaufskontrakt verwaltet werden.

Es kann den Fall geben, dass der Lieferabruf im Einkauf durch die Lieferanfrage im Verkauf geändert wird. Bei Teillieferungen von Lieferanfragen wird die Lieferanfrage im Verkaufskontrakt in zwei Lieferanfragen aufgesplittet. Die erste Lieferanfrage betrifft dabei den gelieferten Teil, die zweite den Rest. Auch der Lieferabruf im Einkauf wird in zwei Lieferabrufe aufgespalten, die den Lieferanfragen im Verkauf entsprechen.

Besonderheiten bei unternehmensübergreifenden Aufträgen: Bei standort- oder unternehmensübergreifenden Kontrakten muss der Lieferant als standortübergreifend deklariert sein, und beim Standort des Lieferanten muss es sich um einen Verkaufsstandort handeln (durch diesen Verkaufsstandort ist auch der Verkaufsstandort im zugehörigen Verkaufskontrakt definiert). Am Einkaufsstandort, der am Ursprung des Kontrakts stand, muss ein standortübergreifender Kunde bekannt sein, der als Kunde im zugehörigen Verkaufsauftrag fungiert.

Handelt es sich beim Lieferanten um einen standortübergreifenden Lieferanten, wird der Indikator Standortübergreifend des Kontrakts automatisch aktiviert. Gehört der Standort des Lieferanten nicht zu demselben Unternehmen wie der Einkaufsstandort des Auftrags, wird auch der Indikator Unternehmensübergreifend aktiviert.

In diesem Zusammenhang wird eine Meldung ausgegeben, wenn der dem Einkaufsstandort zugeordnete Kunde gesperrt ist. Der generierte Verkaufsauftrag ist in diesem Fall ebenfalls gesperrt. Standortübergreifende Aufträge hingegen bleiben hiervon unberührt, da laufende interne Flüsse nicht verwaltet werden.

• Feld XBPRNAM

• Intercompany (Feld BETCPY)

Diese nicht änderbaren Angaben werden automatisch belegt und geben an, ob es sich um einen standort- oder unternehmensübergreifenden Kontrakt handelt. Standortübergreifenden Lieferanten (mit zu demselben Unternehmen gehörigem Standort) kann keine Rechnung gestellt werden. Bei unternehmensübergreifenden Lieferanten (deren Standort zu einem anderen Unternehmen gehört) kann eine Rechnung gespeichert werden.

• Intersite (Feld BETFCY)

Diese Information gibt an, ob der offene Auftrag vom Typ standortübergreifend ist. Betrifft der Auftrag einen standortübergreifenden Lieferanten (mit zu demselben Unternehmen gehörigem Standort), kann keine Rechnung gestellt werden.

• Interne Referenz (Feld ORDREF)

Dieses Feld ermöglicht die Angabe derVertragsreferenz beim Lieferanten (nicht in der Tabelle geprüft) oderdie Angabe einer freien internen Referenz

• Datum Vertrag (Feld ORDDAT)

Das Kontraktdatum wird mit dem Tagesdatum initialisiert. Es kann geändert werden.

• Verkaufsstandort (Feld SALFCY)

Verkaufsstandort des standortübergreifenden Lieferanten.

• Rechnungssteller (Feld BPSINV)

Dieses Feld ermöglicht die Angabe des Codes des Rechnungsstellers, der standardmäßig mit dem in der Kopfzeile erfassten Lieferantencode initialisiert wird.
Dieser Lieferant kann auch ein anderer Lieferant als der in der Lieferantentabelle ausgewählte sein.

• Feld BPAINV

Dieses Feld ermöglicht die Angabe eines Rechnungsadresscodes des rechnungstellenden Lieferanten.
Standardmäßig der in der Datei des Auftragslieferanten für den rechnungstellenden Lieferanten definierte Adresscode. Es kann auch ein anderer Adresscode des rechnungstellenden Lieferanten gewählt werden.

• Zahlungsempfänger (Feld BPRPAY)

Dieses Feld ermöglicht die Angabe des Codes des bezahlten Lieferanten; standardmäßig mit dem in der Kopfzeile erfassten Lieferantencode initialisiert. Dieser Lieferant kann auch ein anderer Lieferant als der in der Lieferantentabelle ausgewählte sein.

• Feld BPAPAY

Dieses Feld ermöglicht die Angabe eines Zahlungsadresscodes des bezahlten Lieferanten. Standardmäßig der in der Datei des Auftragslieferanten für den bezahlten Lieferanten definierte Adresscode. Es kann auch ein anderer Adresscode des bezahlten Lieferanten gewählt werden.

• Projekt (Feld PJTH)

In diesem Feld können Sie einen Projektcode angeben.
Die Verwaltung dieses Codes ist abhängig vom Wert des Parameters CTLOPPCOD - Prüf. Vorgangscode (EK/VK) (Kapitel TC, Gruppe MIS).

• Hat er den Wert Nein, kann es sich um einen frei gewählten Code handeln.
• Hat er den Wert Ja, wird systematisch eine Existenzprüfung des erfassten Projektcodes ausgeführt.
  Sie können das Symbol Auswahl verwenden, um die Liste der verfügbaren Projektcodes anzuzeigen.

Die Verwaltungsmodalitäten dieses Felds sind abhängig vom Parameter PJTSNGDOC - Ein Projekt pro Dokument (Kapitel TC, Gruppe MIS).

• Hat der Parameter den Wert Ja, ist die Verwaltung von Mehrfachprojekten nicht zulässig.
  Der Projektcode stimmt immer mit dem in der Dokumentkopfzeile und den Zeilen überein.
  Der Projektcode, den Sie in der Kopfzeile erfassen, wird systematisch in die Zeilen des Dokuments übertragen und kann nicht geändert werden.
  Bei der Transformation eines Dokuments wird er mit dem Projektcode der Zeilen des ersten ausgewählten Dokuments ausgefüllt und kann nicht geändert werden.
  Die zusätzlichen Zeilen müssen immer den gleichen Projektcode haben.
  Wenn Sie keinen Projektcode angeben und wenn die Bedingungen erfüllt sind, damit sich das Bedarfsberücksichtigungsfenster automatisch öffnet, zeigt dieses alle Bedarfe entsprechend den angegebenen Kriterien an. Diese Bedarfe können verschiedene Projektcodes betreffen. Wenn Sie auf Alle einschließen klicken, wird der Projektcode der ersten Zeile verwendet, um den Projektcode des Auftrags auszufüllen: es sind daher nur die Zeilen ausgewählt, die den gleichen Projektcode wie die erste Zeile enthalten.
  Wenn Sie den Projektcode der Dokumentkopfzeile ändern, wird der Projektcode automatisch auf alle Zeilen übertragen.
  
• Hat der Parameter den Wert Nein, ist die Verwaltung von Mehrfachprojekten zulässig.
  Der Projektcode, den Sie in der Kopfzeile des Dokuments erfassen, wird bei direkter Anlage verwendet, um den Projektcode der Zeilen des Dokuments zu initialisieren.
  Sie können den Projektcode in den Zeilen nur ändern, wenn die folgenden Bedingungen erfüllt werden:
  - die Erfassung dieses Felds wird von der verwendeten Erfassungstransaktion erlaubt
  - die Artikelzeile ist nicht Teil einer Lieferanfrage
  
  Wenn Sie den Projektcode der Dokumentkopfzeile ändern, öffnet sich eine Dialogbox und schlägt ggf. vor, den Code entsprechend den folgenden Optionen auf die Dokumentzeilen zu übertragen:
• Ja: der Projektcode wird auf alle Zeilen übertragen, außer auf die, die bereits Teil einer Lieferanfrage waren.
• Nein: der Projektcode wird nicht auf die Zeilen übertragen.
• Ja bei gleichem Wert: der Projektcode wird nur auf die Zeilen übertragen, die den alten Projektcode hatten, außer auf die, die bereits Teil einer Lieferanfrage waren.

Wird eine Dimension für die Nachverfolgung des Projektmanagement verwendet, führen jegliche Änderungen am Projektcode in der Dokumentkopfzeile zur Neubelegung des Sektorcodes zu dieser Dimension in der Dokumentkopfzeile sowie in den Rechnungselementen über die Parametrisierung der Standardsektoren. Wird der Projektcode in die Zeilen übernommen, wird auch der Sektorcode der betroffenen Zeilen neu belegt.

Besonderheiten bei unternehmensübergreifenden Aufträgen: der Projektcode wird automatisch auf die generierte Verkaufsauftragszeile übertragen, wenn es sich um einen standortübergreifenden Kontrakt handelt. Wenn es sich hingegen um einen unternehmensübergreifenden Kontrakt handelt, wird er nicht übertragen.

• Gültig von (Feld STRDAT)

Der Gültigkeitsbeginn des Kontraktes wird mit dem Tagesdatum initialisiert und kann geändert werden. Mit dem Gültigkeitsbeginn des Kontraktes wird der Gültigkeitsbeginn der Artikelpositionen initialisiert. Dieses Datum ist ebenfalls änderbar, muss aber an oder nach dem Gültigkeitsbeginn des Kontraktes liegen.

• Gültig bis (Feld ENDDAT)

Das Gültigkeitsende des Kontrakts wird mit dem Beginndatum + 1 Jahr initialisiert und kann geändert werden. Es kann geändert werden, solange es nach dem Beginndatum liegt.
Mit dem Gültigkeitsende des Kontrakts wird das Gültigkeitsende der Artikelpositionen initialisiert.

Besonderheiten bei unternehmensübergreifenden Aufträgen: Das Gültigkeitsdatum des zugehörigen Verkaufskontrakts entspricht dem Gültigkeitsende des Einkaufskontrakts. Bei Änderung des Gültigkeitsendes des Einkaufskontrakts wird das Gültigkeitsdatum des Verkaufskontrakts auch dann entsprechend aktualisiert, wenn die Änderung nach der Anlage des Verkaufskontrakts erfolgte.

• Zahlungsbedingung (Feld PTE)

Vorbelegung mit dem in der Bestellungskopfzeile erfassten Lieferanten. Über die Zahlungsbedingungen sind die Zahlweise des Lieferanten sowie die Staffelung der Zahlungen festgelegt.
Diese Information kann geändert werden, ist aber erforderlich. Über diese Tabelle können Berechnungsregeln simuliert werden, die später bei der Erfassung zur Anwendung kommen.
Nur Zahlungsbedingungen, die der Rechtsordnung und der Unternehmensgruppe des Dokumentenstandorts entsprechen, können angegeben werden.
Die mit dem Parameter Multi-Rechtsordnung verknüpften allgemeinen Prinzipien sind hier detailliert beschrieben.

• Skonto (Feld DEP)

Mit diesem Code können Skonto- und Verzugszinssätze festgelegt werden, die je nach Zahlungsverzug bzw. Vorauszahlungszeitraum in Tagen zur Anwendung kommen.
Der Skontocode wird mit den Skontocode des fakturierenden Lieferanten belegt. Er kann weiterhin geändert werden.
Es kann nur ein Skontocode angegeben werden, der zur Rechtsordnung und der Gruppe des Unternehmens des Belegstandorts passt.
Die mit dem Parameter Multi-Rechtsordnung verknüpften allgemeinen Prinzipien sind hier detailliert beschrieben.

Besonderheiten bei unternehmensübergreifenden Aufträgen: bei einer unternehmensübergreifenden Rechnung, die aus einer Verkaufsrechnung generiert wird, wird das Skonto mit dem aus der Verkaufsrechnung belegt.

• Währung (Feld CUR)

Dieses Feld gibt den Code der Währung an, in der die Preise und Beträge der Bestellung oder des Wareneingangs ausgedrückt sind.

Diese erforderliche Information wird über die Adresse des Lieferanten initialisiert, an den die Bestellung gerichtet ist. Solange noch keine Bestellung angelegt ist, kann diese Währung noch geändert werden. Wurden bereits Auftragspositionen erfasst oder handelt es sich um eine Auftragsduplizierung, muss der Benutzer entscheiden, ob die Preise und Nachlässe erneut zu kalkulieren sind. Sollen diese nicht neu kalkuliert werden, werden Preise und Nachlässe lediglich auf Basis des über Wechselkurstyp und Bestelldatum ermittelten Wechselkurses in die neue Währung umgerechnet.

In diesem Feld kann direkt ein Währungscode erfasst werden. Es wird dann geprüft, ob dieser in der entsprechenden Tabelle vorhanden ist. Alternativ dazu stehen im Kontextmenü folgende Möglichkeiten zur Verfügung:

• Auswahl einer Währung aus der Tabelle
• Anlage (sofern die entsprechenden Benutzerrechte vorhanden sind) eines Währungscodes in der Tabelle
• Zugriff auf die Adressauskunft des Lieferanten und Auswahl einer anderen Lieferantenadresse, falls erforderlich. Die Auftragsbestätigung wird an die ausgewählte Adresse verschickt.

Besonderheiten bei unternehmensübergreifenden Aufträgen: Bei unternehmens- oder standortübergreifenden Bestellungen wird die generierte Verkaufsauftragswährung mit der Währung des dem Einkaufsstandort zugeordneten Kunden initialisiert.

• Kurstyp (Feld CHGTYP)

Standardmäßig wird der zum im Auftragskopf erfassten Lieferanten gehörige Wechselkurstyp vorgeschlagen. Solange noch keine Bestellung angelegt ist, kann dieser Wechselkurstyp noch geändert werden.
Der Kurstyp kann folgende Werte annehmen: Tageskurs, Monatskurs, Durchschnittskurs.

Mit einem Wechselkurstyp und dem Bestelldatum kann der Wechselkurs in der Kurstabelle ermittelt werden. Der Wechselkurs ist erforderlich, um die anwendbaren Preise und Nachlässe in die neue Währung umrechnen zu können.

Wurden bereits Auftragspositionen erfasst oder handelt es sich um eine Auftragsduplizierung, wird eine Meldung angezeigt, die vorschlägt die Preise und Nachlässe erneut zu kalkulieren. Sollen diese nicht neu kalkuliert werden, werden Preise und Nachlässe lediglich auf Basis des über Wechselkurstyp und Bestelldatum ermittelten Wechselkurses in die neue Währung umgerechnet.

Entspricht der Wechselkurs der Unternehmenswährung, ist kein Zugriff auf den Kurstyp möglich, da dieser in diesem Kontext keine Rolle spielt.

• Einkäufer (Feld BUY)

Hat der Parameter BUYFLT - Einkaufsfilter (Kapitel ACH, Gruppe AUZ) den Wert Ja, wird der Code des Einkäufers mit dem Code des Benutzers initialisiert und muss in jedem Fall angegeben werden.

Je nach verwendeter Erfassungstransaktion kann dieses Feld ausgeblendet sein. In diesem Fall wird der Benutzercode als Standardwert übernommen.

Von diesem Feld aus kann über das Symbol Aktionen auf das Adressdetail des Lieferanten zugegriffen werden und dort, falls erforderlich, eine andere Adresse ausgewählt werden. Die Auftragsbestätigung wird an die ausgewählte Adresse verschickt.

• Standort Wareneingang (Feld RCPFCY)

Diese Information kann nicht geändert werden. Sie ist nur vorhanden, wenn der Kaufvertrag vom Typ standortübergreifend oder unternehmensübergreifend ist. Dem Feld ist der Standard-Wareneingangsstandort zu entnehmen, der für die Artikelpositionen vorgeschlagen wird. Der Wareneingangsstandort wird in diesem Kontext mit dem Wareneingangsstandort initialisiert, der zur Standardlieferadresse desjenigen Kunden erfasst wurde, der dem Einkaufsstandort des Einkaufskontraktes zugeordnet ist. Ist zur Standardlieferadresse des durch den Einkaufsstandort definierten Kunden kein Wareneingangsstandort angegeben, wird für die Initialisierung auf die erste Lieferadresse zurückgegriffen, bei der es sich um einen Wareneingangsstandort handelt (alphabetische Reihenfolge).

Ist zu keiner der Lieferadressen des durch den Einkaufsstandort definierten Kunden ein Wareneingangsstandort definiert, wird eine sperrende Fehlermeldung angezeigt: "Zwischen Standorten: Lieferadresse des Kunden-Personenkontos xxxx nicht gefunden!". Analog dazu wird auch eine sperrende Fehlermeldung angezeigt, wenn der ermittelte Standort nicht zum selben Unternehmen gehört wie der Einkaufsstandort (inkohärente Daten in der Datenbank).

Beim Speichern des Kontraktes wird der in der Kopfzeile angezeigte Wareneingangsstandort auf den Wareneingangsstandort gesetzt, der zur ersten Position des Einkaufskontraktes gewählt wurde.

• Rechnungsstandort (Feld INVFCY)

Standort, an den die Rechnungen für diesen Kontrakt gerichtet sind, und der standardmäßig mit dem Code des dem Kontraktstandort zugewiesenen Buchhaltungsstandorts initialisiert wird.
 Dieser Rechnungsstandort muss immer ein Buchhaltungsstandort sein, der zum gleichen juristischen Unternehmen gehört, wie der Kontraktstandort.

Besonderheiten bei unternehmensübergreifenden Aufträgen: Bei unternehmens- oder standortübergreifenden Kontrakten wird der Rechnungsstandort mit dem Standort des fakturierten Kunden initialisiert, der in den Kundendaten des Einkaufsstandortes definiert ist. Der Rechnungsstandort kann geändert werden, sofern der neue Standort einem Kunden zugeordnet ist. Bei Generierung des Verkaufskontraktes werden der Rechnungsempfänger und der Regulierer mit dem Kunden des erfassten Rechnungsstandortes initialisiert. Bei Änderungen wird auch der Verkaufskontrakt aktualisiert.

• Versandstandort (Feld STOFCY)

Code des Lagerstandorts, von dem aus der Kunde in der Regel beliefert wird. Der Versandstandort wird anhand der Standorttabelle geprüft und muss dem Lagerstandort entsprechen.

Zugriff nur bei Intersite-/Intercompany-Auftrag. Es handelt sich um den Versandstandort der Ware beim Verkaufsunternehmen des Intersite-/Intercompany-Lieferanten. Mit diesem Versandstandort werden in der Folge die Versandstandorte der einzelnen Bestellzeilen initialisiert. In diesem Kontext handelt es sich um ein Pflichtfeld.

Der Versandstandort wird wie folgt nach Priorität initialisiert:

• Suche nach dem Versandstandort, der zur Lieferadresse des zuvor berechneten Wareneingangsstandortes gehört. Dieser Versandstandort muss zum Unternehmen des Lieferanten gehören,
• vom Lieferanten initialisierter Standort - sofern es sich dabei um einen Lagerstandort handelt.

Konnte mit dieser Suche kein Standort ermittelt werden, müssen Sie den Standort manuell erfassen. In diesem Fall wird eine Prüfung vorgenommen, mit der gewährleistet werden soll, dass der Standort zu demselben Unternehmen gehört, wie der Standort des Lieferanten, und dass es sich bei diesem Standort um einen Lagerstandort handelt. Über das Menü Aktionen können alle wählbaren Standorte angezeigt werden.

Besonderheiten im Zusammenhang mit automatisch generierten Bestellungen:: Wenn mit der Ausführung aller oben beschriebenen Punkte immer noch kein Versandstandort ermittelt werden konnte, wird für die Initialisierung der erste Lagerstandort aus der alphabetischen Liste der Lagerstandorte des Lieferanten ausgewählt.

Bei der Generierung des entsprechenden Verkaufsauftrags wird der Versandstandort in der Kopfzeile des Verkaufsauftrags mit dem so ermittelten Standort belegt.

• Lieferart (Feld MDL)

Standardmäßige Vorbelegung dieses erforderlichen Felds mit dem in der Kontraktkopfzeile erfassten Lieferanten. Beschreibt, wie die Waren transportiert werden. Diese Information wird insbesondere für die Intrastat-Erklärung verwendet.
Die über die Lieferart festgelegte Transportart wird auf die Auftragsbestätigung übernommen.

In diesem Feld kann direkt eine Lieferart erfasst werden. Es wird dann geprüft, ob diese in der entsprechenden Tabelle vorhanden ist. Alternativ dazu stehen über das Symbol Aktionen folgende Möglichkeiten zur Verfügung:

• Auswahl einer Lieferart aus der Tabelle
• Anlage (sofern die entsprechenden Benutzerrechte vorhanden sind) einer Lieferart in der Tabelle

Besonderheiten bei unternehmensübergreifenden Aufträgen: Im Rahmen von unternehmens- oder standortübergreifenden Bestellungen wird die Lieferart des generierten Verkaufsauftrags mit der zur Bestellung erfassten Lieferart vorbelegt, sofern sie nicht vom belieferten Kunden selbst erfasst wurde. Wobei der belieferte Kunde im Verkaufsauftrag durch die Lieferadresse festgelegt ist, die als Wareneingangsstandort in der Bestellung angegeben ist.

• Frachtführer (Feld BPTNUM)

Für die Lieferung der Waren verantwortliche Spedition. Vorbelegung mit der in der Kontraktkopfzeile erfassten Spedition. Es öffnet sich ein Auswahlfenster, in dem Sie eine andere Spedition auswählen können. Verfügen Sie über die hierfür erforderlichen Rechte, können Sie den Spediteur auch aus der Spediteurstabelle auswählen.

• Steuerart (Feld VACBPR)

Erforderliche Eingabe, Vorbelegung mit dem in der Bestellungskopfzeile erfassten Steuersystem des Lieferanten. Über dieses Feld ist das für die Bestellung anwendbare Steuersystem festgelegt; darüber hinaus lassen sich aus diesem Steuersystem die auf die einzelnen Artikelpositionen anzuwendenden Steuercodes ableiten.  Funktionalitäten in Verbindung mit diesem Feld:

• Auswahl eines Steuersystems aus der Tabelle
• Anlage (sofern die entsprechenden Benutzerrechte vorhanden sind) eines Steuersystems in der Tabelle.

Besonderheiten bei unternehmensübergreifenden Aufträgen: Bei unternehmens- oder standortübergreifenden Kontrakten wird das generierte Steuersystem mit dem Steuersystem des dem Einkaufsstandort zugeordneten Kunden initialisiert.

Nur ein Steuersystem, das der Rechtsordnung und der Unternehmensgruppe des Standorts entspricht, kann angegeben werden.
Die mit dem Parameter Multi-Rechtsordnung verknüpften allgemeinen Prinzipien sind hier detailliert beschrieben.

• Dimension (Feld DIE)

Diese Tabelle ermöglicht die Angabe oder Anzeige der Kostenrechnungsbelastungen in Abhängigkeit des Parameters der Erfassungstransaktion der offenen Aufträge.

• Bezeichnung (Feld NAMDIE)

Dieses Feld übernimmt die Bezeichnung der Dimension.

• Sektor (Feld CCE)

Die Sektoren werden gemäß dem Parameter der Standardsektoren initialisiert (Sektorcode - POH). Die Sektorcodes können manuell geändert werden, sofern dies in der Transaktion erlaubt ist.

Wird eine Dimension für die Nachverfolgung des Projektmanagement verwendet, führen jegliche Änderungen am Projektcode zur Neubelegung des Sektorcodes zu dieser Dimension über die Parametrisierung der Standardsektoren. Wird der Projektcode in die Zeilen übernommen, wird auch der Sektorcode der betroffenen Zeilen neu belegt.

• Unterzeichnet (Feld APPFLG)

Übersicht über die Kontraktsituation aus Sicht der Signaturregelung.
Folgende Werte sind möglich: Keine, Teilweise, Vollständig, Keine Verwaltung, Ja Automatisch.

Ist die Signaturregelung für das Unternehmen nicht aktiviert (Parameter APPPOC - Unterschriftenregel. Kontrakte im Kapitel ACH, Gruppe APP), wird der Wert systematisch auf Keine Verwaltung gesetzt.

Ist die Signaturregelung für das Unternehmen aktiviert, richtet sich der Wert nach der Signaturregelung und den bereits erteilten Unterschriften:

• Nein
  : Es wurde noch keine Unterschrift erteilt, oder die bereits erteilten Unterschriften wurden von einem Unterzeichneten storniert.
• Teilweise:
  Ein Teil der in der Signaturregelung vorgesehenen Unterschriften wurden bereits erteilt.
• Vollständig:
  Alle in der Signaturregelung vorgesehenen Unterschriften wurden bereits erteilt. In diesem Fall kann der Kontrakt bearbeitet werden, und es kann ein Wareneingang durchgeführt werden.
•  Ja Automatisch
  : Die Signaturregelung ist optional (Parameter APPPOC), und für diesen Kontrakt wurde kein Signaturkreis festgelegt. Der Kontrakt wird als unterzeichnet angesehen. Folglich kann er bearbeitet werden, und es kann ein Wareneingang durchgeführt werden.

Bei standort- oder unternehmensübergreifenden Einkaufskontrakten, deren Parameter entsprechend gesetzt sind, wird bei folgenden Werten der entsprechende Verkaufskontrakt aktualisiert: Keine Verwaltung, Vollständig oder Ja Automatisch.

• Gedruckt (Feld PRNFLG)

Diese Information ermöglicht die Angabe, ob der offene Auftrag bereits bearbeitet wurde. Dieser kann nur bearbeitet worden sein, wenn er vollständig unterzeichnet ist, oder wenn es keine Unterschriftenverwaltung gibt, oder wenn die Unterschrift automatisch ist.

• Beglichen (Feld CLEFLG)

Diese Information wird nicht in den Kontrakten verwendet.

• Erhalten (Feld RCPFLG)

Übersicht über die Situation der offenen Aufträge aus Sicht des Wareneingangs. Folgende Werte sind möglich: 'Nein', 'Teilweise'.

• Fakturiert (Feld INVFLG)

Übersicht über die Situation der offenen Aufträge aus Sicht des Wareneingangs. Folgende Werte sind möglich: 'Nein', 'Teilweise'.

• Artikel (Feld ITMREF)

Es muss ein Artikel erfasst werden, wobei entweder im Artikelfeld die interne Artikelreferenz oder im nächsten Feld die Lieferantenreferenz erfasst werden kann. In beiden Fällen wird die Existenz dieser Artikelreferenz in der Datei Artikel geprüft.

Der erfasste Artikel muss:

• in eine Kategorie eingekaufter Artikel eingegeben werden
• in der entsprechenden Artikeldatei als Aktiv deklariert sein
• vom Einkäufer verwaltet werden, wenn der Parameter BUYFLT - Einkaufsfilter (Kapitel ACH, Gruppe AUZ) den Wert ‚Ja‘ hat.
• Ein im Artikel oder Artikel-Standort nicht angegebener Käufercode bedeutet, dass dieser für alle potentiellen Käufer gültig ist.

Weiterhin ist es nicht möglich, zu demselben Artikel und demselben Standort mehrere Artikelzeilen anzulegen. In diesem Fall wird eine sperrende Fehlermeldung ausgegeben: „Zeile Auftrag Artikel - Standort existiert bereits. Hinzufügen nicht möglich."

Besonderheiten bei unternehmensübergreifenden Aufträgen:

Zu einem standort- oder unternehmensübergreifenden offenen Auftrag können Sie nur Artikel vom Typ Erhalten / Lieferbar erfassen.

Im Feld Artikel stehen mehrere Möglichkeiten zur Verfügung. So kann z.B. eine Artikelreferenz direkt erfasst oder über das Symbol Aktionen eine der folgenden Funktionen ausgeführt werden:

• Auswahl eines Artikels aus der Datei
• Auswahl eines Artikels aus der Artikelliste des Lieferanten
• Auswahl eines Artikels aus der Artikelliste Lieferant-Standort. In diesem Auswahlfenster steht der Cursor standardmäßig auf dem ersten beim Lieferant referenzierten Artikel für den Wareneingangsstandort. Sie können einen anderen Artikel auswählen, der bei einem beliebigen anderen Wareneingangsstandort referenziert ist, der zum gleichen juristischen Unternehmen gehört.
• Anlage eines Artikels in der Datei, sofern entsprechende Benutzerrechte vorhanden sind

Bei der Anlage des Artikels wird das Feld Bezeichnung initialisiert. Die so gesetzte Bezeichnung kann geändert werden.

Nach Erfassung des Artikels können verschiedene Meldungen angezeigt werden:

• Der Artikel ist beim Lieferanten nicht referenziert.
• Dabei kann es sich um eine sperrende Fehlermeldung oder um einen Hinweis handeln - je nachdem, was in den Allgemeinen Parametern ITMBPS - Lieferantenreferenzierung (Kapitel ACH, Gruppe REF) festgelegt wurde.
• Der Artikel-Standort ist beim Lieferanten nicht referenziert.
• Dabei kann es sich um eine sperrende Fehlermeldung oder um einen Hinweis handeln - je nachdem, was in den Allgemeinen Parametern ITMBPSFCY - Referenzierung Lieferant-Standort (Kapitel ACH, Gruppe REF) festgelegt wurde. Ist diese Meldung eine sperrende Meldung, können Sie trotzdem mit der Erfassung fortfahren, jedoch nur wenn das Feld Standort Wareneingang als erfassbar auf Ebene der Erfassungstransaktion definiert ist. In diesem Fall wird das Feld, das den Wareneingangsstandort enthält, geleert. Sie müssen daher einen Standort angeben, an dem der Artikel-Lieferant referenziert ist, oder für den der Parameter ITMBPSFCY - Referenzierung Lieferant-Standort nicht sperrend ist.
  Die mit dem Parameter ITMBPSFCY - Referenzierung Lieferant-Standort verbundene Prüfung gilt nicht für standortübergreifende Aufträge.
• Der Artikelauftrag ist für diesen Lieferanten oder für diesen Lieferanten an diesem Wareneingangsstandort gesperrt. Abhängig vom Sperrcode im Datensatz Artikel oder im Datensatz Artikel - Standorte kann es sich bei dieser Meldung um eine sperrende Meldung oder um einen einfachen Hinweis handeln.
• Der Artikel kann nicht direkt bestellt werden, zuvor muss eine Einkaufsanfrage gestellt werden.
  Diese Meldung ist eine sperrende Meldung.
• Wenn der Filter pro Einkäufer aktiviert ist und der Artikel nicht von dem in der Kontraktkopfzeile angegebenen Einkäufer verwaltet wird.
  Diese Meldung ist eine sperrende Meldung.

• Lieferantenartikel (Feld ITMREFBPS)

Die Erfassung einer Artikelreferenz beim Lieferanten ist nur dann erforderlich, wenn im vorhergehenden Feld keine interne Referenz erfasst wurde.
Die Referenz kann direkt erfasst oder aus der Artikelliste des Lieferanten ausgewählt werden.

• Bezeichnung (Feld ITMDES)

Hauptbezeichnung des Artikels aus der Artikeldatei, die während der Erfassung geändert werden kann.
Im Fall einer Ausschreibung muss die Bezeichnungdirekt erfasst werden, wenn der Artikel nicht in derArtikeltabelle vorhanden ist.

• Feld ITMDES1

Bezeichnung, die in die Sprache des Lieferanten übersetzt wurde. Sie wird mit allen eventuellen Änderungen in den Wareneingang oder auf die Lieferantenrechnung übernommen. Entspringt die Bestellung einer Materialanforderung oder einer Ausschreibung, so wird die übersetzte Bezeichnung von der ursprünglichen Position vererbt.
Diese Bezeichnung wird auf dem Auftrag gedruckt. Über dieses Feld kann über eine Verzweigung auf das Artikeldatenblatt zugegriffen werden.

• Artikeltyp (Feld ITMKND)

Dieses Feld gibt an, von welchem Typ der Artikel ist: Standardoder Dienstleistung.

Ein Artikel vom Typ Standard ist ein ‚physischer‘ Artikel, ob bestandsverwaltet oder nicht. Ein Artikel vom Typ Dienstleistung ist ein nicht bestandsverwalteter Artikel, dessen Kategorie vom Typ Dienstleistung ist.

Ob das Feld vorhanden ist, hängt von der verwendeten Maskentransaktion ab.

• Hauptversion (Feld ECCVALMAJ)

Die höhere Versionsnummer ist nur zugänglich, wenn die Rückmeldung der höheren Versionen auf Ebene des Artikelparameters aktiv ist (im Bereich Verwaltung der Funktion Artikel hat das Feld Bestandsversion den Wert 'Höher'). Ist das Vorladen der Versionen auf Ebene des Artikels/Lieferanten oder stattdeseen auf Ebene des Artikels/Dispo aktiviert, wird die letzte aktive höhere Version automatisch vorgeladen. Stattdessen wird die letzte höhere Version mit Status 'Angehalten' vorgeladen. Dies kann geändert werden.

• Nebenversion (Feld ECCVALMIN)

Die niedrigere Versionsnummer ist nur zugänglich, wenn die Rückmeldung der höheren und niedrigeren Versionen auf Ebene des Artikelparameters aktiv ist (im Bereich Verwaltung der Funktion Artikel hat das Feld Bestandsversion den Wert 'Höher und niedriger'). Ist das Vorladen der Versionen auf Ebene des Artikels/Lieferanten oder stattdeseen auf Ebene des Artikels/Dispo aktiviert, wird die letzte niedrigere Version automatisch vorgeladen. Dies kann geändert werden.

• Standort Wareneingang (Feld PRHFCY)

Der Wareneingangsstandort wird in der Regel mit dem Kontraktstandort initialisiert. Wenn allerdings der Kontraktstandort in der Standorttabelle nicht als Lagerstandort deklariert ist und es sich um einen bestandsgeführten Artikel handelt, wird der erste zur juristischen Person des Kontraktstandortes gehörende Lagerstandort vorgeschlagen.

Im Feld Wareneingangsstandort stehen mehrere Möglichkeiten zur Verfügung.
Sie können:

• Direkterfassung eines Standortcodes, sofern dieser zu derselben juristischen Person gehört wie der Kontraktstandort und sofern sich der erfasste Code in der Standorttabelle befindet
• Auswahl eines Standorts aus der Vorschlagsliste, Bestandsabfragen über das Symbol Aktionen
• Anlage des Artikels bzw. Standortes, wenn dieser nicht vorhanden ist

Auswahl einer Wareneingangsadresse. Standardmäßig handelt es sich dabei um die erste in den angezeigten Standortdaten spezifizierte Adresse.
Ist der Artikel-Standort beim Lieferanten nicht referenziert, wird eine Meldung angezeigt. Dabei kann es sich um eine sperrende Fehlermeldung oder um einen Hinweis handeln - je nachdem, was in den Allgemeinen Parametern ITMBPSFCY - Referenzierung Lieferant-Standort (Kapitel ACH, Gruppe REF) festgelegt wurde. Diese Prüfung wird nicht für standortübergreifende Aufträge ausgeführt.

Besonderheiten bei unternehmensübergreifenden Aufträgen: Bei standort- oder unternehmensübergreifenden Einkaufskontrakten wird der Wareneingangsstandort mit dem Wareneingangsstandort initialisiert, der zur Standardlieferadresse desjenigen Kunden erfasst wurde, der dem Einkaufsstandort des Einkaufskontraktes zugeordnet ist. Ist zur Standardlieferadresse des durch den Einkaufsstandort definierten Kunden kein Wareneingangsstandort angegeben, wird für die Initialisierung auf die erste Lieferadresse zurückgegriffen, bei der es sich um einen Wareneingangsstandort handelt (alphabetische Reihenfolge).

Ist zu keiner der Lieferadressen des durch den Einkaufsstandort definierten Kunden ein Wareneingangsstandort definiert, wird eine sperrende Fehlermeldung angezeigt: "Zwischen Standorten: Lieferadresse des Kunden-Personenkontos xxxx nicht gefunden!"Analog dazu wird auch eine sperrende Fehlermeldung angezeigt, wenn der ermittelte Standort nicht zum selben Unternehmen gehört wie der Einkaufsstandort (inkohärente Daten in der Datenbank).

Beim Speichern des Kontraktes wird der in der Kontraktkopfzeile angezeigte Wareneingangsstandort auf den Wareneingangsstandort gesetzt, der zur ersten Zeile des Einkaufskontraktes gewählt wurde.

Bei der Generierung des Verkaufskontraktes wird als Lieferadresse der Artikelzeile die Lieferadresse verwendet, die zur Artikelzeile des Einkaufskontraktes vom Wareneingangsstandort ermittelt wurde.

• Adresse (Feld FCYADD)

Hierbei handelt es sich um den Standardadresscode des gewählten Wareneingangsstandorts. Es handelt sich um die Adresse, die auf der an den Lieferanten gesendeten Auftragsbestätigung eingetragen wird.
Im Feld Adresse Wareneingangsstandort können Sie eine andere Adresse auswählen, sofern mehrere Adressen vorhanden sind.

• Verbrauchsort (Feld USEPLC)

Verwenden Sie dieses Feld, um den Verbrauchsort des Frachtführers anzugeben, oder um einen Adresszusatz zu definieren.

Beispiele: Rampe xx oder Halle yy.

Der Verbrauchsort wird in die Auftragsbestätigung eingetragen.

Unternehmensübergreifende Besonderheiten: Bei Intercompany- oder Intersite-Aufträgen wird der Verbrauchsort in die generierte Verkaufsauftragszeile übernommen.

• Versandstandort (Feld LINSTOFCY)

Code des Lagerstandorts, von dem aus der Kunde in der Regel beliefert wird. Der Versandstandort wird anhand der Standorttabelle geprüft und muss dem Lagerstandort entsprechen.

Zugriff nur bei Intersite-/Intercompany-Auftrag. Es handelt sich um den Versandstandort der Ware beim Verkaufsunternehmen des Intersite-/Intercompany-Lieferanten. Mit diesem Versandstandort werden in der Folge die Versandstandorte der einzelnen Bestellzeilen initialisiert. In diesem Kontext handelt es sich um ein Pflichtfeld.

Der Versandstandort wird wie folgt nach Priorität initialisiert:

• Suche nach dem Versandstandort, der zur Lieferadresse des zuvor berechneten Wareneingangsstandortes gehört. Dieser Versandstandort muss zum Unternehmen des Lieferanten gehören,
• vom Lieferanten initialisierter Standort - sofern es sich dabei um einen Lagerstandort handelt.

Konnte mit dieser Suche kein Standort ermittelt werden, müssen Sie den Standort manuell erfassen. In diesem Fall wird eine Prüfung vorgenommen, mit der gewährleistet werden soll, dass der Standort zu demselben Unternehmen gehört, wie der Standort des Lieferanten, und dass es sich bei diesem Standort um einen Lagerstandort handelt. Über das Menü Aktionen können alle wählbaren Standorte angezeigt werden.

Besonderheiten im Zusammenhang mit automatisch generierten Bestellungen:: Wenn mit der Ausführung aller oben beschriebenen Punkte immer noch kein Versandstandort ermittelt werden konnte, wird für die Initialisierung der erste Lagerstandort aus der alphabetischen Liste der Lagerstandorte des Lieferanten ausgewählt.

Bei der Generierung des entsprechenden Verkaufsauftrags wird der Versandstandort in der Kopfzeile des Verkaufsauftrags mit dem so ermittelten Standort belegt.

• Gültig von (Feld XSTRDAT)

Der Gültigkeitsbeginn des Artikels im Kontrakt wird standardmäßig mit dem in der Kopfzeile erfassten Gültigkeitsbeginn des Kontraktes erfasst.
Das Datum kann geändert werden, muss aber an oder nach dem Kontraktbeginn und vor oder an dem Gültigkeitsende liegen.

• Gültig bis (Feld XENDDAT)

Das Gültigkeitsende des Artikels im Kontrakt wird standardmäßig mit dem in der Kopfzeile erfassten Gültigkeitsende des Kontraktes erfasst.
Das Datum kann geändert werden, muss aber an oder vor dem Kontraktende und nach oder an dem Gültigkeitsbeginn liegen.

• Einkaufseinheit (Feld PUU)

Hierbei handelt es sich um die für das Tupel „Artikel-Lieferant“ definierte Einkaufseinheit; ist kein Datensatz „Artikel-Lieferant“ vorhanden, so handelt es sich um die Einkaufseinheit des Artikels.
Jeder Artikel verfügt über zwei Einkaufseinheiten:

• die im Artikeldatensatz definierte Einkaufseinheit,
• die Einkaufseinheit des Lieferanten.

Diese Einkaufseinheit kann nicht geändert werden. Sie wird standardmäßig bei der Erfassung eines Auftrags, eines Fremdbearbeitungsauftrags oder eines Wareneingangs verwendet. Die Einkaufseinheit des Lieferanten wird standardmäßig vorgeschlagen, wenn der Datensatz Artikel-Lieferant existiert.

Die zugänglichen Einkaufseinheiten hängen vom angegebenen Kategorietyp ab.

Bei der Fakturierung eines Artikels wird die Einkaufseinheit des Artikels verwendet.

• Menge Soll (Feld EXTQTYPUU)

Für die Kontraktlaufzeit vorgesehene Gesamtmenge.
Dieses Feld ist kein Pflichtfeld; die Mengenerfassung wird über die Transaktion gesteuert.
Ist das Feld in der Transaktion als Eingeblendet oder Ausgeblendet deklariert, so wird die Menge automatisch mit 0 initialisiert. Ein Hinweis wird ausgegeben:

• wenn das Feld als Erfasst deklariert und kein Wert erfasst ist
• wenn die erfasste Menge unter der vom Lieferanten geforderten und im Datensatz Artikel-Lieferant angegebenen Mindestmenge liegt

Auf Basis dieses Felds können Sie über das Symbol Aktionen verschiedene Bestandsabfragen ausführen.

Es ist nicht möglich, Lieferabfragen für Mengen zu starten, die über der hier angegebenen Menge liegen.

• Festhorizont (Feld FIMHOR)

Zeitraum in Tagen, während dessen im Rahmen dieses Kontraktes feste Lieferantenanfragen ausgeführt werden können.
Über die Erfassung eines Wertes in diesem Feld kann eine Prüfung der erfassten Lieferanfragen erfolgen (siehe Dokumentation Lieferanfragen).

• Periode (Feld FIMHORUOM)

• Planungshorizont (Feld FRTHOR)

Zeitraum in Tagen, Wochen oder Monaten, in dem geplante Lieferantenanfragen ausgeführt werden können.

• Periode (Feld FRTHORUOM)

Zeiteinheit, in der der Planungshorizont ausgedrückt wird.

• Projekt (Feld PJT)

In diesem Feld können Sie einen Projektcode angeben.
Die Verwaltung dieses Codes ist abhängig vom Wert des Parameters CTLOPPCOD - Prüf. Vorgangscode (EK/VK) (Kapitel TC, Gruppe MIS).

• Hat er den Wert Nein, kann es sich um einen frei gewählten Code handeln.
• Hat er den Wert Ja, wird systematisch eine Existenzprüfung des erfassten Projektcodes ausgeführt.
  Sie können das Symbol Auswahl verwenden, um die Liste der verfügbaren Projektcodes anzuzeigen.

Die Verwaltungsmodalitäten dieses Felds sind abhängig vom Parameter PJTSNGDOC - Ein Projekt pro Dokument (Kapitel TC, Gruppe MIS).

• Hat der Parameter den Wert Ja, ist die Verwaltung von Mehrfachprojekten nicht zulässig.
  Der Projektcode stimmt immer mit dem in der Dokumentkopfzeile und den Zeilen überein.
  Der Projektcode, den Sie in der Kopfzeile erfassen, wird systematisch in die Zeilen des Dokuments übertragen und kann nicht geändert werden.
  Bei der Transformation eines Dokuments wird er mit dem Projektcode der Zeilen des ersten ausgewählten Dokuments ausgefüllt und kann nicht geändert werden.
  Die zusätzlichen Zeilen müssen immer den gleichen Projektcode haben.
  Wenn Sie keinen Projektcode angeben und wenn die Bedingungen erfüllt sind, damit sich das Bedarfsberücksichtigungsfenster automatisch öffnet, zeigt dieses alle Bedarfe entsprechend den angegebenen Kriterien an. Diese Bedarfe können verschiedene Projektcodes betreffen. Wenn Sie auf Alle einschließen klicken, wird der Projektcode der ersten Zeile verwendet, um den Projektcode des Auftrags auszufüllen: es sind daher nur die Zeilen ausgewählt, die den gleichen Projektcode wie die erste Zeile enthalten.
  Wenn Sie den Projektcode der Dokumentkopfzeile ändern, wird der Projektcode automatisch auf alle Zeilen übertragen.
  
• Hat der Parameter den Wert Nein, ist die Verwaltung von Mehrfachprojekten zulässig.
  Der Projektcode, den Sie in der Kopfzeile des Dokuments erfassen, wird bei direkter Anlage verwendet, um den Projektcode der Zeilen des Dokuments zu initialisieren.
  Sie können den Projektcode in den Zeilen nur ändern, wenn die folgenden Bedingungen erfüllt werden:
  - die Erfassung dieses Felds wird von der verwendeten Erfassungstransaktion erlaubt
  - die Artikelzeile ist nicht Teil einer Lieferanfrage
  
  Wenn Sie den Projektcode der Dokumentkopfzeile ändern, öffnet sich eine Dialogbox und schlägt ggf. vor, den Code entsprechend den folgenden Optionen auf die Dokumentzeilen zu übertragen:
• Ja: der Projektcode wird auf alle Zeilen übertragen, außer auf die, die bereits Teil einer Lieferanfrage waren.
• Nein: der Projektcode wird nicht auf die Zeilen übertragen.
• Ja bei gleichem Wert: der Projektcode wird nur auf die Zeilen übertragen, die den alten Projektcode hatten, außer auf die, die bereits Teil einer Lieferanfrage waren.

Wird eine Dimension für die Nachverfolgung des Projektmanagement verwendet, führen jegliche Änderungen am Projektcode in der Dokumentkopfzeile zur Neubelegung des Sektorcodes zu dieser Dimension in der Dokumentkopfzeile sowie in den Rechnungselementen über die Parametrisierung der Standardsektoren. Wird der Projektcode in die Zeilen übernommen, wird auch der Sektorcode der betroffenen Zeilen neu belegt.

Besonderheiten bei unternehmensübergreifenden Aufträgen: der Projektcode wird automatisch auf die generierte Verkaufsauftragszeile übertragen, wenn es sich um einen standortübergreifenden Kontrakt handelt. Wenn es sich hingegen um einen unternehmensübergreifenden Kontrakt handelt, wird er nicht übertragen.

• Preiscode (Feld PLI)

Die auf den Kontrakt anwendbaren Preisbestimmungen können aus vordefinierten oder speziell für den Artikel im Kontrakt festgelegten Preisen stammen.
Sie können diese wie folgt festlegen:

• Entweder durch Erfassung oder durch Auswahl eines speziellen Preiscodes im Feld Preiscode, sofern dieses Feld in der Transaktion als 'Erfasst' deklariert ist
  Standardmäßig handelt es sich um den aktiven Preiscode, der der wichtigste unter den parametrisierten Preisen mit im Lieferantendatensatz definierter Preisstruktur ist.
  Dieser Preiscode ermöglicht die Definition der Preisbestimmungen: die Spalten Preis sowie Rabatte und Spesen werden automatisch mit den Daten aus der Preissuche aktualisiert. Wird kein Preiscode erfasst, werden diese Felder mit dem Wert Null initialisiert.
   
• Oder durch direkte Erfassung in der Tabelle der Preisbedingungen, der Felder Gültig ab, Preis, Rabatte und Spesen, wenn kein Preiscode erfasst ist.

Besonderheiten bei unternehmensübergreifenden Aufträgen: Bei unternehmensübergreifenden Kontrakten wird standardmäßig und in der Reihenfolge der Prioritäten der erste unternehmensübergreifende Preiscode vorgeschlagen. Der Preiscode wird vom Einkaufskontrakt in den entsprechenden Verkaufskontrakt übernommen, sofern es sich um einen auch im Verkauf definierten Preiscode handelt. Die Einkaufspreispositionen hingegen werden nicht übernommen.

• Stückpreis (Feld PRIVLT)

• Ist ein Preiscode angegeben, wird dieses Feld automatisch durch die Preissuche mit dem geltenden Preis ausgefüllt.
  Konnte kein Preis angewendet werden, wird er über den im Bereich Einkauf des Datensatzes Artikel erfassten Basispreis ausgefüllt. Ist dieser Basispreis nicht angegeben, werden die Standardkosten angewendet, wenn der Parameter PURPRICE - Standardpreis Plankosten (Kapitel SCH, Gruppe PRI) den Wert 'Ja' hat.
  
• Ist kein Preiscode angegeben oder ist er gelöscht, nimmt dieses Feld den Wert des Preises der ersten Zeile der Preisbedingungen an. Ist keine Zeile angegeben, hat der Bewertungspreis den Wert 0.

• Bezeichnung (Feld NAMCOA)

• Konto (Feld LINACC)

Diesen Feldern sind die Einkaufskonten zu entnehmen. Welche Konten für die Bearbeitung zur Verfügung stehen, hängt von der Buchungsvorlage des Unternehmens ab, in dem die Bewegung gebucht wird. Sind diese Felder nicht gefüllt, werden die Konten automatisch anhand des dem Artikel zugeordneten Kontos ermittelt (gemäß Parametrierung der Automatik-Buchungen PORD).
Ob das Feld vorhanden ist, hängt von der verwendeten Erfassungstransaktion ab.
Ist dieses Feld nicht angegeben, wird das Konto (bei der Rechnungsfreigabe) automatisch vom Kontencode des Artikels festgelegt, das die Funktion der Parametrisierung des Automatic Journals PIHI hat.

• Einkaufstyp (Feld LINPURTYP)

Ob dieses Feld vorhanden ist, hängt von der Parametrierung der Maskensteuerung ab. Es bestehen folgende Einkaufstypen: Einkauf, Anlagen und Service. Der Einkaufstyp wird gemäß der dem zuvor erfassten Konto zugeordneten steuerlichen Belastung initialisiert. Der Einkaufstyp wird in den Wareneingang oder in die Prüfung der Einkaufsrechnung übernommen.

• Gültig von (Feld POPSTRDAT)

Es handelt sich um den Gültigkeitsbeginn der Preisposition.

Wurde ein Preiscode angegeben, stammt der Gültigkeitsbeginn aus der Preissuche.
Dieses Datum wird in der ersten Zeile standardmäßig mit dem Gültigkeitsdatum des Artikels im Kontrakt initialisiert.
In den folgenden Zeilen erfolgt eine Preissuche mit dem Tarifenddatum +1 der vorherigen Zeile als Referenzdatum. Wird ein Preis gefunden, wird die entsprechende Zeile generiert.

Ist kein Preiscode angegeben, muss dieses Datum manuell erfasst werden.

• Bruttopreis (Feld GROPRI)

Wurde ein Preiscode angegeben, stammt der Nettoeinheitsbruttopreis aus der Preissuche. Andernfalls wird er mit 0 initialisiert und muss manuell erfasst werden.

Über das Symbol Aktionen haben Sie die folgenden Möglichkeiten:

• Anzeige der Gründe für die Preise sowie für die verschiedenen Felder für Rabatte und Spesen
• Anzeige der Preise
• Erläuterung der Preiskalkulation
  

• Feld DISCRGVAL1

Die verschiedenen angezeigten Nachlass- und Spesenfelder hängen vom Parameter des Preisstrukturcodes aus dem Lieferantendatensatz des entsprechenden Lieferanten ab. 
Wurde ein Preiscode erfasst, stammen die in diesen Feldern enthaltenen Werte aus der Preissuche (siehe Dokumentation Preisparameter). Andernfalls werden diese Felder mit 0 initialisiert.
Der Zugriff auf diese Felder kann von der Parametrisierung der Gründe der Preise sowie vom Grundwert des Parameters UPDPRIPUR - Preisgrund (Kapitel ACH, Gruppe PRI) abhängen.
Die Nachlässe oder Kosten werden in Betrag oder Prozent definiert und werden auf die Bruttopreise kumuliert oder hierarchisch angewendet, um den Nettopreis der Dokumentenposition festzulegen.
Das Symbol Aktionen bietet folgende Möglichkeiten:

• Anzeige der Gründe für die Preise sowie für die verschiedenen Nachlass- und Spesenfelder
• gegebenenfalls Änderung der Gründe für jede einzelne Spalte

• Nettopreis (Feld NETPRI)

• Feld CCE1

Die Sektoren werden gemäß dem Parameter der Standardsektoren initialisiert (Sektorcode - POC).
Wird eine Dimension für die Nachverfolgung des Projektmanagement verwendet, führen jegliche Änderungen am Projektcode in der Dokumentzeile zur Neubelegung des Sektorcodes über die Parametrisierung der Standardsektoren.
Die Sektoren können in Abhängigkeit des Transaktionsparameters geändert werden. Die verschiedenen zu der Bestellposition angegebenen Sektoren werden in den Wareneingang oder in die Prüfung der Einkaufsrechnung übernommen.

• QK (Feld QUAFLG)

Dieser Code ermöglicht die Definition, ob der Artikel bei Bestandseingang geprüft werden soll.
Die angegebene Artikelkategorie bestimmt den ursprünglichen Prüfwert des Artikel-Standort-Datensatzes und des Lieferant-Bestand-Datensatzes. Der Wert des Lieferant-Bestand-Datensatzes entspricht dem Standardwert in den Bestellungen.

• Keine Prüfung. Die Prüfung wird nach den Verwaltungsregeln definiert. Sie kann manuell geändert werden.
• Prüfung nicht änderbar. Die Qualitätskontrolle ist für Bestandseingänge erforderlich. Q ist der einzige gültige Status.
• Prüfung änderbar. Bei Bestandseingängen wird der Qualitätsstatus mit dem Wert Q initialisiert. Der Status kann auf A oder R geändert werden.
  Der Qualitätskontrollcode kann auch auf Ebene der Bestellung definiert werden.
  • Hat die Qualitätskontrolle in der Bestellung den Wert Ja, ist die Qualitätskontrolle erforderlich und der Wareneingang erfolgt mit einem der Unterstatus Q*, die auf Ebene der Artikelverwaltungsregel für Wareneingangsbewegungen definiert sind.
    Ist kein Unterstatus definiert, kann der zum Zeitpunkt des Wareneingangs nicht erfasst werden.
  • Hat die Qualitätskontrolle in der Bestellung den Wert Nein, ist die Qualitätskontrolle nicht erforderlich.
    Beim Wareneingang wird standardmäßig der Status A vorgeschlagen. Dieser Status kann durch einen der in der Verwaltungsregel der Wareneingangsbewegungen des Artikels definierten Status ersetzt werden.
• Prüfung periodisch. Die Prüfung wird automatisiert gemäß der Anzahl Wareneingänge für diesen Lieferanten und diesen Artikel. Der Bestandsstatus kann während des Zugangs noch geändert werden.
  
  

Ist dem Artikel bzw. dem Tupel Artikel-Lieferant der Prüfcode Prüfung nicht änderbar zugeordnet, so kann das entsprechende Feld der Bestellzeile unabhängig von der Parametrisierung der verwendeten Transaktion nicht bearbeitet werden.

Diese Angabe wird in der Folge beim Wareneingang verwendet und mit der für die Artikelkategorie definierten und dem Bewegungstyp Wareneingang Lieferant zugeordneten Verwaltungsregel gekreuzt. Dies dient der Ermittlung des Artikelstatus und ggf. der Generierung einer Analyseanforderung.

• Intrastat-Erhöhung (Feld EECINCRAT)

Dieses Feld unterliegt dem Aktivitätscode DEB - Intrastat.

Dieser Erhöhungskoeffizient wird in der Intrastat-Erklärung verwendet. Er ergibt sich auf Basis der Lieferantenrechnungen aus der Anwendung dieses Koeffizienten auf den steuerlichen Wert der Artikel.
Er wird mit dem Erhöhungskoeffizienten im Datensatz Artikel - Lieferant oder standardmäßig im Datensatz Lieferant angegeben.

• Ursprungsland (Feld ORICRY)

Code des Ursprungslandes der Ware, der mit dem Ländercode initialisiert wird, der dem Auftragslieferanten zugeordnet ist.
Dieses Feld ermöglicht die Angabe des Landes, aus dem die Waren stammen, gemäß den zollrechtlichen Bestimmungen über die Herkunft von Waren.
Für die Intrastat-Erklärung wird das Feld Ländercode EU verwendet, das diesem Code in der Ländertabelle zugewiesen ist.
Für die Lieferantenretouren ist dies das Empfängerland.

• Nr. (Feld INVDTA)

Die Rechnungselemente stammen direkt aus dem vom Kontrakt betroffenen Lieferantendatensatz für die, die als in der Auftragsfußzeile vorhanden deklariert sind (siehe Dokumentation Rechnungselemente). Die Nummer des Rechnungselements identifiziert den zugewiesenen Betrag (Kosten, Porto, Verpackung, Nachlass, etc.).
Sie können die Elemente weder ändern noch löschen, Sie können jedoch der Liste andere Elemente hinzufügen.  Sie können nur die zur ursprünglichen Liste hinzugefügten Elemente löschen.
Um eines der vorgeschlagenen Elemente zu stornieren, genügt es, einen Wert Null zum betreffenden Element zu erfassen. Die Werte der einzelnen Elemente stammen ebenfalls aus dem Lieferantendatensatz, können jedoch geändert werden.
Anschließend werden alle Rechnungselemente in der Rechnungsprüfung berücksichtigt. Die Vertragsbewertung ist von den Rechnungselementen nicht betroffen.

• Bezeichnung (Feld INVDTALIB)

Kurztitel des Rechnungselements.

• Prozent / Betrag (Feld INVDTAAMT)

Angaben in der Rechnungsfußzeile. Die als in der Bestellungsfußzeile präsent deklarierten Angaben stammen direkt aus den Rechnungselementen, die sich im Datensatz des vom Auftrag betroffenen Lieferanten befinden.
Siehe DokumentationRechnungselemente.
Die Werte der verschiedenen vorhandenen Rechnungselemente können geändert werden und neue hinzugefügt werden.
Unternehmensübergreifende Besonderheiten
Bei einem standortübergreifenden oder unternehmensübergreifenden Auftrag müssen sich die Rechnungselemente Verkauf und Einkauf entsprechen, wenn die Rechnungselemente verwendet werden sollen. Es kann auch angegeben werden, ob der im Verkaufsauftrag initialisierte Wert der Rechnungselemente aus den Rechnungselementen des Kundendatensatzes stammt, entsprechend dem Einkaufsstandort des Auftrags für die Rechnungselemente des Einkaufsauftrags, und von den Rechnungselementen des Lieferanten entsprechend dem Verkaufsstandort.
 Siehe Parameter Unternehmensübergreifend.

• Feld AMTCODLIB

Das System gibt an, ob das Rechnungselement ein Prozentsatz oder ein Betrag ist.
Bei einem Betrag wird die Dokumentwährung angezeigt.

• Feld ACC1

Diesen Feldern sind die Einkaufskonten der Rechnungselemente zu entnehmen. Welche Konten für die Bearbeitung zur Verfügung stehen, hängt von der Buchungsvorlage des Unternehmens ab, in dem die Bewegung gebucht wird.
Sind diese Felder nicht gefüllt, werden die Konten automatisch anhand des dem Rechnungselement zugeordneten Kontos ermittelt (gemäß Parametrisierung der Automatik-Buchungen).
 Ob diese Felder vorhanden sind, hängt von der verwendeten Erfassungstransaktion ab.

• Umlage (Feld DSP)

Der in diesem Feld angegebene Kostenrechnungsaufteilungsschlüssel ermöglicht das Laden der zugewiesenen Kostenrechnungsdimensionen. Er besteht aus 1 bis 10 alphanumerischen Zeichen.
Die Kostenrechnungsaufteilungsschlüssel ermöglichen die automatische Umlegung des Betrags einer Buchungsposition auf mehrere Kostenrechnungspositionen. Diese Umlage erfolgt gemäß den Gewichtungskoeffizienten.
Kann direkt in der Position des Rechnungselements geändert werden.

• Feld PFICCE1

Es handelt sich um die Sektoren des Rechnungselements.

Die Sektoren werden gemäß dem Parameter der Standardsektoren (Sektorcode POCV) aus der Verwaltung der Rechnungselemente initialisiert. Die Sektorcodes können manuell geändert werden, sofern dies in der Transaktion erlaubt ist. Um die Sektorcodes der verschiedenen Sektoren zu ändern, klicken Sie auf das Symbol Aktionen.

Wird eine Dimension für die Nachverfolgung des Projektmanagement verwendet, führen jegliche Änderungen am Projektcode in der Dokumentkopfzeile zur Neubelegung des Sektorcodes dieser Dimension, wenn nicht ein Verteilungsschlüssel angegeben ist.

• Mindestmenge (Feld WORDMINAMT)

Mindestnettobetrag, unter dem die Lieferantenaufträge Teil einer Prüfung sein können (blockierend, Meldung oder keine Prüfung).

Die Prüfebene in Bezug auf diesen Betrag ist dem Parameter POHMINAMT - Prüfung Mindestbestellbetrag (Kapitel ACH, Gruppe AUZ) zu entnehmen.

• Summe Soll (Feld TOTVLT)

Hierbei handelt es sich um die Nettokontraktsumme, ausgedrückt in Ordnerwährung. Der Nettogesamtbetrag wird hierfür zunächst gemäß Datum und Wechselkurstyp des Kontraktes in Ordnerwährung konvertiert.

• Datum Empfangsbestätigung (Feld OCNDAT)

Nachdem Sie den Auftrag vom Lieferanten erhalten haben, erfassen Sie das auf der Wareneingangsbestätigung angegebene Wareneingangsdatum.
Nach der Erfassung werden Kontraktpositionen, die noch nicht über ein Empfangsbestätigungsdatum verfügen, automatisch mit diesem Datum aktualisiert.

Besonderheiten bei unternehmensübergreifenden Aufträgen: Bei unternehmens- oder standortübergreifenden Kontrakten können Nummer und Datum der Empfangsbestätigung nicht bearbeitet werden. Sie werden mit dem Datum und der Nummer des Verkaufsauftrags initialisiert, sofern selbiger bereits generiert wurde. Wenn Sie über die erforderlichen Berechtigungen verfügen, können Sie über das Symbol Aktionen im Feld AB-Nr. auf den generierten Verkaufskontrakt zugreifen.

• Empfangsbestätigungsnr. (Feld OCNNUM)

Nachdem Sie den Auftrag vom Lieferanten erhalten haben, erfassen Sie die vom Lieferanten auf der Wareneingangsbestätigung angegebene Wareneingangsnummer.
Nach der Erfassung werden Kontraktpositionen, die noch nicht über eine Empfangsbestätigungsnummer verfügen, automatisch mit dieser Nummer aktualisiert.

Besonderheiten bei unternehmensübergreifenden Aufträgen: Bei unternehmens- oder standortübergreifenden Kontrakten können Nummer und Datum der Empfangsbestätigung nicht bearbeitet werden. Sie werden mit dem Datum und der Nummer des Verkaufsauftrags initialisiert, sofern selbiger bereits generiert wurde. Wenn Sie über die erforderlichen Berechtigungen verfügen, können Sie über das Symbol Aktionen im Feld AB-Nr. auf den generierten Verkaufskontrakt zugreifen.

• Empfangsbestätigungen (Feld OCNREM)

Geben Sie gegebenenfalls zwei Kommentarzeilen für die Empfangsbestätigung an.

• Incoterm (Feld EECICT)

Die von der Internationalen Handelskammer standardisierten Incoterms sollen die im internationalen Handel am häufigsten verwendeten Handelsbedingungen vereinheitlichen, indem die jeweiligen Verpflichtungen des Verkäufers und des Käufers bei der Einrichtung eines Verkaufsvertrags mit einem eindeutigen Begriff definiert werden, der international gleich interpretiert werden kann.

Die Incoterms werden in der Tabelle Incoterms geprüft und werden vor allem für die Intrastat-Meldung verwendet. Sie können auch für die Preisfestlegung verwendet werden.

• Ort Incoterm (Feld ICTCTY)

Bestimmten Incoterm-Typen zugeordnete Stadt. Beispiele: FOB Le Havre. Ein Auswahlfenster ermöglicht die Auswahl einer im System gespeicherten Stadt. Es kann jedoch auch eine nicht gespeicherte Stadt erfasst werden.

• Transit (Feld FFWNUM)

Der Spediteur ermöglicht die Identifikation eines vom Absender oder Empfänger bevollmächtigten Personenkontos, um die Transportkontinuität sicherzustellen, wenn die Ware mehrere aufeinander folgende Transporte durchlaufen muss. Der Spediteur wird in der Frachtführertabelle geprüft.

Der Spediteur und seine Adresse werden in der Intrastat-Meldung verwendet, um die Warenflüsse zwischen der Absenderadresse und der Empfängeradresse und zwischen der Spediteuradresse und der Empfängeradresse zu erklären.

Dies kann insbesondere der Fall sein, wenn die Waren zum Export gesendet wurden, die Zollformalitäten jedoch über einen Spediteur in einem anderen EU-Mitgliedsstaat erfolgt sind. Ein Intrastat-Lager muss für den Transfer der Ware in diesem anderen EU-Mitgliedsstaat durchgeführt werden.

• Übergangsadresse (Feld FFWADD)

Hierbei handelt es sich um den Adresscode des Spediteurs. Er wird mit der Standardadresse des dem Spediteur entsprechenden Personenkontos initialisiert. Diese Adresse ermöglicht die Definition, ob ein Instrastat-Lager für diesen Fluss erforderlich ist.

• EU-Ust.-IdNr. (Feld EECNUM)

Umsatzsteueridentifikationsnummer des Personenkontos. 

Die europäische Umsatzsteueridentifikationsnummer muss auf allen Rechnungen angegeben sein, die in die EU gehen oder aus der EU kommen. Sie beginnt mit dem aus zwei Buchstaben bestehenden Ländercode des jeweiligen Landes, gefolgt von einer vom Land abhängigen Zahlenfolge.

In Frankreich setzt sich die Nummer wie folgt zusammen: FR gefolgt von 2 Zeichen für das Finanzamt des Unternehmenssitzes, gefolgt von der SIREN-Nummer des Unternehmens.

Diese Information muss auf jeden Fall angegeben werden, wenn der SIREN-Code als erforderlich für das Unternehmensland parametrisiert wurde.

• INTRASTAT-Beförderungsort (Feld EECLOC)

Der Transportort ist eine für die Intrastat-Meldung erforderliche Information. Er wird mit dem Incoterm-Code kombiniert, um die Lieferbedingungen zu bestimmen, die die Bedingungen des Verkaufsvertrags übernehmen, die die jeweiligen Verpflichtungen des Verkäufers und des Käufers angeben.

Diese Information wird nicht für die französische Meldung verwendet.

• INTRASTAT-Beförd.art (Feld EECTRN)

Transportmittel, mit dem die Ware bei Versand das Land verlassen soll bzw. mit dem es bei Wareneingang in das Land gebracht werden soll. Wird in der Intrastat-Erklärung verwendet.

• Transaktionsart (Feld EECNAT)

Wirtschaftliche Information für den abgeschlossenen Vorgang. Die Transaktionsart wird für die Intrastat-Erklärung verwendet.
Diese Information wird in den physischen Flüssen initialisiert, wo sie geändert werden kann. Für bestimmte Finanzflüsse (Rechnungen und Gutschriften im Verkauf) erhält man auch Zugriff auf diese Information.
Die Initialisierung der Transaktionskostenart wird über den Parameter ausgeführt, der auf Ebene der entsprechenden Tabelle Bewegungssysteme und -arten ausgeführt wird. Über diese Tabelle kann jedem Flusstyp ein EU-System und eine EU-Transaktionskostenart zugewiesen werden Der Parameter kann je nach Rechtsordnung, Land und Unternehmensgruppe bestimmt werden.

• Statistikregel (Feld EECSCH)

Mit einer EU-Steuerart oder Statistik kann die Art eines aus steuerlicher oder statistischer Sicht innergemeinschaftlichen Vorgangs gekennzeichnet werden. Die EU-Steuerart wird für die Intrastat-Erklärung verwendet.
Diese Information wird in den physischen Flüssen initialisiert, wo sie geändert werden kann. Für bestimmte Finanzflüsse (Rechnungen und Gutschriften im Verkauf) erhält man auch Zugriff auf diese Information.
Die Initialisierung der Transaktionskostenart wird über den Parameter ausgeführt, der auf Ebene der entsprechenden Tabelle Bewegungssysteme und -arten ausgeführt wird. Über diese Tabelle kann jedem Flusstyp ein EU-System und eine EU-Transaktionskostenart zugewiesen werden Der Parameter kann je nach Rechtsordnung, Land und Unternehmensgruppe bestimmt werden.