SBI Self-Billing Gutschriftsverfahren

ERS-procedure (Evaluated Receipt Settlement)

3.13 ERS- und SD-Gutschriftsverfahren
Eine Bezahlung der gelieferten JIT-Abrufe kann über die klassische Fakturierung im SD oder auch über das SD-Gutschriftsverfahren abgewickelt werden.
Das nachfolgende Bild beschreibt die Grundlagen und den Prozessablauf des ERS- und SD-Gutschriftsverfahrens.
Die hier aufgezeigtes Bild zeigt einen exemplarischen Prozess zur Verdeutlichung des Zusammenspiels des ERS-Verfahrens beim Kunden und dem SD-Gutschriftsverfahren beim Zulieferer. Im Schaubild ist der Prozess der Lieferquittierung eingezeichnet, da dieser in der Praxis in Verbindung mit dem Gutschriftsverfahren vorkommen kann.


Zusammenspiel des ERS- und SD-Gutschrifstverfahrens

Dieser ist allerdings nicht zwingend Voraussetzung, um einen Gutschriftsprozess zu implementieren. Wenn dieser relevant ist. kann der Lieferquittierungsprozess bzw. die Abwicklung mit Tagessammellieferscheinen über die Transaktion ODLC angestoßen werden.

Das Zusammenspiel von ERS-Verfahren beim OEM und dem SD-Gutschriftsverfahren beim Zulieferer kann wie folgt beschrieben abgebildet sein.

  1. Voraussetzung für das Durchführen des SD-Gutschriftsverfahrens beim Zulieferer ist die erzeugte Gutschrift aus dem ERS-Verfahren beim Kunden. Diese kann nur erzeugt werden, wenn die bestellten Teile zum Kunden geliefert wurden.
  2. Auf Basis einer Bestellung oder eines Einkaufslieferplans wird die Anlieferung der Teile angelegt, um den Wareneingang zu buchen. Der erzeugte Materialbeleg ist die Voraussetzung, um beim OEM die Gutschriftanzeige zu erzeugen. Zudem muss eine Partnervereinbarung zum Lieferanten mit der Partnerrolle LF, mit dem Nachrichtentyp GSVERF oder SBWAP und dem aktuellen Basistypen GSVERF03 unter der Angabe der Applikation MR. der Nachrichtenart ERS6 und dem Vorgangscode MRRL vorhanden sein. Weitere Voraussetzungen sind, dass in der Bestellposition zum Einkaufslieferplan die warenbezogene Rechnungsprüfung und die automatische Wareneingangsrechnung (=ERS-Verfahren) erlaubt sind.
  3. Als nächster Schritt erfolgt die Erzeugung der Gutschriftsanzeige mit der Transaktion MRRL auf Grundlage des Wareneingangsbelegs aus der Anlieferung. Die Gutschrift beinhaltet, die Menge und den Wert, der vom Kunden an den Zulieferer zur Bezahlung ansteht. Über die Transaktion MRRL wird ein Rechnungsbeleg erzeugt, der über die Transaktion MIRO detailliert betrachtet werden kann.
  4. Die Ausgabe der Gutschriftsanzeige per IDOC mit dem Nachrichtentyp SBWAP und Basistyp GSVERF03 an den Zulieferer erfolgt über die Transaktion MR90. Das IDOC beinhaltet alle wichtigen Information aus dem unter Schritt 3 erzeugten Rechnungsbeleg.
  5. Der Zulieferer empfängt wiederum ein IDOC mit der Gutschriftsanzeige und kann diese nur verarbeiten, wenn die Partnervereinbarung zum Kunden mit dem Nachrichtentyp SBWAP und dem Vorgangscode SBWAP angelegt ist. Alle empfangenen Nachrichten landen im Eingangsmonitor für das SD-Gutschriftsverfahren, der mit der Transaktion VSB1N aufgerufen werden kann. Über das Menü ist der Absprung auf diverse Einstellungen möglich, um Parameter und notwendige Voraussetzungen zur Verarbeitung des IDOCs zu pflegen. Bei der Verarbeitung des IDOCs wird geprüft, ob eine Wert und/oder Mengenabweichung zur beim Zulieferer erstellten Faktura existiert. Falls ja. erzeugt das System Ausgleichsbuchungen in Form von Gutschrifts- bzw. Lastschriftsanforderungen, die im gleichen Zug fakturiert werden, um die existierenden Differenzen auszugleichen. Die Verbuchungsschritte können mit der Transaktion VSBSMS auch im Vordergrund ausgeführt werden, damit einsehbar ist, welche Schritte und Funktionen bei der Verarbeitung des IDOCs prozessiert werden.

    Die einlaufende Gutschriftsanzeige beim Zulieferer muss die ursprünglich erstellte Faktura im System finden, um feststellen zu können, ob Ausgleichsbuchungen durchgeführt werden müssen. Die Findung muss kundenspezifisch eingestellt werden und kann beispielsweise über die eigene Lieferungsnummer, die externe Lieferscheinnummer oder über die Produktionsnummer stattfinden (weitere Parameter sind möglich).

© Praxishandbuch JIT/JIS mit SAP

Evaluated Receipt Settlement (ERS) – автоматическая оплата поступившего материала
SBI – Self-Billing Invoice(s)
TSL – der Tagessammellieferschein (Daily Delivery Note)

IDocs:
SBWAP – Logische Nachricht
GSVERF01, GSVERF02, GSVERF03 – Basistypen

SBINV – SBINV is specially only for Italy. In other countries more advanced SBWAP should be used.

Basistyp SMOD User Exit Beschreibung
GSVERF MRMN0001 EXIT_SAPLMRMN_001 Outbound IDoc for ERS/consignment settlement
GSVERF VED50001 EXIT_SAPLVED5_001 User Exit for Condition Value Tolerances in the Self- Billing Procedure
GSVERF VED50001 EXIT_SAPLVED5_005 Customer-Specific Changes in Workflow Parameters
GSVERF VED50001 EXIT_SAPLVED5_006 Copying Data to Screens for Incoming EDI Docs
Basistyp SMOD User Exit Beschreibung
SBINV VED50001 EXIT_SAPLVED5_002 User Exit for messages in the Self-Billing Procedure SBINV
SBINV VED50001 EXIT_SAPLVED5_003 User Exit for Tolerances in the Self- Billing Procedure SBINV
SBINV VED50001 EXIT_SAPLVED5_004 Customer-Function for changing invoice data SBINV
SBINV VED50001 EXIT_SAPLVED5_005 Customer-Specific Changes in Workflow Parameters
SBINV VED50001 EXIT_SAPLVED5_006 Copying Data to Screens for Incoming EDI Docs
Basistyp SMOD User Exit Beschreibung
INVOIC FEDI0001 EXIT_SAPLIEDI_001 FI-EDI: Invoice receipt – Determine G/L account per invoice line
INVOIC FEDI0001 EXIT_SAPLIEDI_002 FI-EDI: Invoice receipt – Determine add. acct assignm. per line item
INVOIC FEDI0001 EXIT_SAPLIEDI_003 FI-EDI: Invoice receipt – Fill the screen field ‚Allocation‘
INVOIC FEDI0001 EXIT_SAPLIEDI_004 FI-EDI: Invoice receipt – Determine the segment text
INVOIC FEDI0001 EXIT_SAPLIEDI_005 FI-EDI: Invoice receipt – Determine the name of the BDC session
INVOIC FEDI0001 EXIT_SAPLIEDI_011 MM-EDI: Invoice receipt – Determine purchase order item
INVOIC FEDI0001 EXIT_SAPLIEDI_101 FI-EDI: Invoice receipt INVOIC01 – additional assignment
INVOIC FEDI0001 EXIT_SAPLIEDI_102 FI-EDI: Invoice receipt INVOIC01 – add data
INVOIC FEDI0001 EXIT_SAPLIEDI_111 MM-EDI: Invoice receipt INVOIC01 – additional assignment
INVOIC FEDI0001 EXIT_SAPLIEDI_112 MM-EDI: Invoice receipt INVOIC01 – add data
INVOIC MRMH0002 EXIT_SAPLMRMH_011 Logistics Invoice Verification: inboud EDI message, company code
INVOIC MRMH0002 EXIT_SAPLMRMH_012 Logistics Invoice Verification: inboud EDI message, control flags
INVOIC MRMH0002 EXIT_SAPLMRMH_013 Logistics Invoice Verification: inboud EDI message, assignment
INVOIC MRMH0002 EXIT_SAPLMRMH_014 Logistics Invoice Verification: inboud EDI message, segments
INVOIC MRMH0002 EXIT_SAPLMRMH_015 Logistics Invoice Verification: inbound EDI message, before posting
INVOIC LVEDF001 EXIT_SAPLVEDF_001 User_Exit controll data IDoc_Output_Invoic
INVOIC LVEDF001 EXIT_SAPLVEDF_002 User_Exit customer enhancement of segments outbound invoice
INVOIC LVEDF001 EXIT_SAPLVEDF_003 User_Exit to avoid reading package data
INVOIC LVEDF001 EXIT_SAPLVEDF_004 EDI Invoice: customer enhancement for reading additional data

—————————-
*sapcarsrocknroll.blogspot.com/2016/03/self-billing-and-evaluated-receipt.html

VDA 4938 – новый стандарт для электронных счетов-фактур

Немецкая ассоциация автомобильной промышленности (Verband der deutschen Automobilindustrie, VDA) уже много лет успешно выпускает стандарты для процессов в автомобильной промышленности и смежных отраслях.
Стандарты, относящиеся к электронному выставлению счетов-фактур VDA 4906 (1993г.) и VDA 4908 (1996г.) на сегодня устарели.
На сегодняшний день рекомендуется пользоваться новым стандартом для электронных счетов-фактур – VDA 4938.
Стандарт VDA 4938 состоит из четырех различных частей, которые перечислены ниже.
С отдельными документами можно ознакомиться по следующим ссылкам.

  1. 4938 T1 – Основы (каркас) для обмена электронными платежными документами с использованием EDIFACT без цифровой подписи
  2. 4938 T2 – V 2.2 Руководство по использованию формата INVOIC
  3. 4938 T3 – использование электронного биллинга с малыми и средними предприятиями в автомобильной промышленности (включая Приложение)
  4. 4938 T4 – Счет за фрахт (перевозку)

В первом документе представлена структура процессов выставления электронных счетов-фактур. В документ включены образцы типовых соглашений и чеклисты для использующих Стандарт.
Второй документ содержит Руководство по внедрению сообщений EDIFACT (EDIFACT-Message-Implementation-Guideline, сокращённо MIG) на основе стандартного формата EDIFACT INVOIC D07A.
Третий документ содержит спецификацию счета-фактуры для автомобильной индустрии (проект, профинансированный Европейским Союзом). Также здесь содержится спецификация XML для электронных счетов-фактур.
Четвёртый документ содержит спецификации счетов-фактур фрахта (грузовых перевозок) на основе стандартного формата EDIFACT INVOIC D13A.

Sequential parts delivery (SPD)

Bei der Bereitstellung nach dem SPD-Verfahren sorgt der Zulieferer nicht nur dafür, dass die benötigten Module rechtzeitig in der notwendigen Menge angeliefert werden, sondern auch, dass die Reihenfolge (engl. sequence) der benötigten Module stimmt. SPD wird vor allem in der Automobilindustrie eingesetzt. Die Vorlaufzeit beträgt je nach Produktionssystem mehrere Tage bis einige Minuten. Zur Steuerung von SPD werden Sequence-Inlining-Systeme eingesetzt. Die mögliche Entfernung zwischen Lieferant und Kunden ist dabei abhängig von der geforderten Vorlaufzeit.

Als Beispiel für eine SPD-Anlieferung kann die Endmontage von Automobilen betrachtet werden. Durch das Aufsetzen der lackierten Karosserien auf das Endmontageband ist die Reihenfolge der Fahrzeuge festgelegt, die auch als „Perlenkette“ bezeichnet wird. Werden zum Beispiel die Außenspiegel per SPD-Anlieferung bereitgestellt, sind diese bereits in der Reihenfolge der Fahrzeuge auf dem Montageband sortiert. Der Mitarbeiter in der Montage braucht die Spiegel nur der Reihe nach aus dem Transportbehälter zu greifen und hat automatisch den Außenspiegel in der entsprechenden Farbe des Fahrzeugs in der Hand. Anwendung findet diese Belieferungsform meist bei Teilen, die je nach Konfiguration des zu bauenden Fahrzeugs (Produktkonfiguration) stark variieren können – wie Stoßfänger, Fahrzeugsitze, Innenverkleidungen, Türen, Cockpit usw. –, da das Lagern aller Varianten zu hohe Kosten verursachen und zu viel Fläche beanspruchen würde.

Durch die Sortierung der angelieferten Module wird ein zusätzlicher Kommunikationsaufwand notwendig. SPD-Anlieferungen benötigen, wie auch die JIT-Anlieferungen, den direkten Kontakt zwischen Abnehmer und Zulieferer, der generell mittels eines elektronischen Datenaustauschsystems über die Datenprotokolle EDIFACT, Odette oder VDA (für JIS im Speziellen VDA 4916) sowieso schon besteht. Daher ist regelmäßig nur eine Anpassung der Firmensoftware erforderlich.

Концепция жемчужного ожерелья (логистика)

Какое отношение автомобильное производство имеет к жемчужному ожерелью? Казалось бы, надуманный вопрос. На первый взгляд, между ними нет ничего общего. Тем не менее, вы можете оказаться на автомобильной конференции, где говорят о жемчужных ожерельях.
В этой концепции точная последовательность производства заказов определяется за несколько дней до производства. Большое количество моделей автомобилей в автомобильной индустрии приводит к огромному количеству деталей, которые усложняют отдельные процессы. Необходима твердая последовательность производственных заказов – это одна из целей жемчужного ожерелья. Термин „Frozen zone“ (зона заказов как бы „заморожена“) описывает период, начинающийся после определения жемчужной цепи – последовательность больше не может быть изменена. Принцип определяет порядок заказов клиентов при планировании заказов на весь производственный цикл. Они обязательны при планировании заказа и определяют производственные последовательности изделий в процессе производства. При этом определяется порядок обработки и сроки производства в пределах жемчужного ожерелья.
Предпосылкой этой концепции является производство в соответствии с методом built-to-order, то есть производство изделий с четким сопоставлением заказа клиента. Это фиксированное сопоставление заказов по всему производственному процессу и оно контрастирует с концепциями последовательности заказов с последующим сопоставлением заказов.

На следующем рисунке показана реализация концепции жемчужной цепи в управлении производством.

На автомобильное производство обычно не влияют кратковременные изменения. Таким образом модель жемчужных ожерельев обеспечивает поставщиков надежностью планирования на несколько недель.
Фиксированная последовательность также повышает точность расписания и скорость обработки. Складские запасы могут быть оптимизированы, несмотря на очень различное производство.
Управление производством по принципу жемчужной цепи представляет из себя концепцию последовательности заказов со строгим контролем, установленной до начала производства.

Для различных производственных секций также могут быть установлены различные последовательности, которые объединены буферами (модифицированная концепция жемчужного ожерелья).

Несмотря на то, что модель жемчужной цепи кажется простой в теории, ее реализация на самом деле довольно сложна. Если заказ приходит слишком рано или задерживается где-то вдоль жемчужной цепи, все доставленные детали будут также перенесены. Поставщик должен учитывать не только количество необходимых деталей, но и порядок их предоставления. Например, используя стратегию just-in-sequence, наружные зеркала для окончательной сборки автомобиля могут быть доставлены и прикреплены в то время, когда кузова автомобиля расположены как готовые жемчужные ожерелья на конечной сборочной линии. Затем зеркала уже сортируются по цвету в транспортном контейнере в соответствии с последовательностью соответствующих им автомобилей на сборочной линии.

Являясь центральной частью планирования, создание последовательности влияет почти на все интерфейсы автомобильной логистики, от доставки, производства и управления складом до отдела продаж. Для того чтобы все части были обеспечены в нужное время и в нужном месте, важно координировать контроль поставок и внутреннюю логистику с графиком производства. Это единственный способ, при которым может работать метод жемчужного ожерелья. Контейнер с монтажными деталями, который был доставлен на сборочную линию слишком поздно или с неправильной последовательностью, может остановить производственный процесс. Поэтому нарушение логистических процедур может существенно повлиять на общую эффективность цепи.

Несмотря на то, что Жемчужное ожерелье является очень простой стратегией для логистики и производства, она намного сложнее, чем кажется на первый взгляд.


(long distance Just-in-Time).

Was ist der Unterschied zwischen JIT und JIS?

JiT ist die Produktionsversorgung zum jeweils richtigen Zeitpunkt (Einbauzeitpunkt/Bedarfszeitpunkt in einer Anlage / in einem Fertigungsprozessschritt) – bedarfssynchrone Produktion.

JiS ist die Produktionsversorgung in der erforderlichen Reihenfolge (Beispiel: Fließbandversorgung) – Reihenfolgesynchronität.

„Just in sequence“ ist ein Sonderfall von „just in time“. Beides bedeutet zunächst „Anlieferung vom externen Lieferanten (oder interner Vorproduktion) kurz vor Bedarf im nächsten Arbeitsschritt (üblicherweise eine Montagetätigkeit).

„Kurz“ kann dabei von wenigen Stunden bis wenige Tage definiert werden, abhängig von den räumlichen Entfernungen.

Bei „just in sequence“ übernimmt der Lieferant die Reihenfolge-Bildung. Dies ist besonders bei sehr vielen unterschiedlichen Varianten (z.B. Türinnen-Verkleidungen eines Autos) nützlich, da dann im Montagewerk keine zusätzlichen Sortierarbeiten mehr durchgeführt werden müssen. Dafür ist jedoch eine zeitnahe und verlässliche Information des Kunden an den Lieferanten notwendig, welche Varianten in genau welcher Reihenfolge benötigt werden. Häufig gibt es dafür auch spezielle Verpackungs- und Transportgestelle, so dass die Identifikation und Entnahme beim Kunden möglichst einfach wird.

„Just in time“ wird dann verwendet, wenn es gar keine oder nur sehr wenige unterschiedliche Varianten gibt und beim Kunden nur ein sehr geringer Lagerbestand (wenige Stunden- oder Tagesvolumen) vorgehalten werden soll.

Beides dient dazu, möglichst effiziente und bestandsarme Kunden-Lieferanten-Beziehungen zu erreichen („lean supply chain“). Zugleich soll der Anteil an nicht-wertschöpfender Tätigkeit bei allen Beteiligten minimiert werden.

DIMP

Technische Voraussetzungen für den Einsatz von SAP JIT

Bei der Analyse von SAP JIT Programmcode oder bei Recherchen im Web erkennt man, dass die Funktionalität des SAP JIT etwa im Jahre 1998 entwickelt wurde. Seither wurde die Komponente stets optimiert, wenn auch keine grundlegenden neuen Funktionalitäten hinzugefügt wurden. Der Funktionsumfang blieb bisher weitestgehend stabil. Nutzt man ein SAP ECC muss das Automotive Dimp (=Discrete Industries and Mill Products) installiert werden (Softwarekomponente ECC-DIMP). Dabei wird die Anwendungskomponente IS-A für Industry Solution Automotive (Business Function AUTO_CI_1) aktiviert. Im Fall von S4/Hana ist die SAP JIT Funktionalität (Business Function AUTO_CI_1) ab Version 1610 in die Softwarekomponente S4CORE übergewandert und steht nun bei den S/4H Always ON Business Functions. Es fallen keine zusätzlichen Lizenzkosten für SAP JIT an, wenn ausschließlich auf S4/Hana gesetzt wird. Wird SAP JIT unter einem SAP ECC geführt, bleibt die Funktionalität extra lizenzkostenpflichtig.

Der Hauptfokus der Anwendung des SAP JITs liegt in der Praxis wesentlich in der Automobilindustrie und insbesondere in der Zuliefererindustrie. Wenn es die Anforderungen an den Prozess erlauben und der Einsatz sinnvoll ist, hat SAP JIT das Potenzial auch in anderen Industrien eingesetzt zu werden. Nicht nur die technische Voraussetzung für den Einsatz von SAP JIT muss gegeben sein, sondern auch die besondere Beziehung zwischen Kunde und Zulieferer.

Ist die Aktivierung des SAP JIT abgeschlossen, muss zwingend mit JIT-Lieferplänen (SD-Lieferplänc mit der Kennzeichnung „J“ im Customizing zu den Verkaufsbelegarten) gearbeitet werden. Ein Zusammenspiel von SAP JIT ohne JIT-Lieferpläne ist im SAP-Standard nicht möglich. Wenn diese Voraussetzungen eingehalten werden, kann JIT-Inbound mit dem erforderlichen Customizing, Stamm- und Bewegungsdaten verwendet werden. Möchte man als Kunde seine Zulieferer mit Sequenznachrichten versorgen und somit das JIT-Outbound anwenden, ist die Verwendung von JIT-Inbound zwingend notwendig (nicht bei Mengenabrufen).

Um einen technischen Einblick in die SAP JIT Objekte zu bekommen, können die Entwicklungspakete ISAUTO_JIT* für das JIT-Inbound bzw. DI_JITOUT* für das JIT-Outbound weiter analysiert werden.

© Praxishandbuch JIT/JIS mit SAP

JITEMRA Transaktion

JITEMRA: Notfallerzeugung gebündelter Mengenabruf

Mit der Transaktion JITEMRA ist es möglich, einen JIT-Abruf als Vorlage zu verwenden und diesen dann auf n-verschiedene neue JIT-Abrufe zu kopieren. Dies kann in der Praxis dann Sinn machen, wenn eine EDI-Verbindung nicht zur Verfügung steht und JIT-Abrufe nicht im System verarbeitet werden können. Der Anwender erstellt einen Dummy Abruf mit der Menge n, der dann wiederum mit der Transaktion JITEMRA auf verschiedene Abrufe kopiert werden kann. Dabei wird die Menge n auf die Anzahl der angegebenen JIT-Abrufe kopiert. Reicht der SAP-Standard bei der Rangeverarbeitung nicht aus, kann Userexit EXIT_SAPLJIT14_002 aus der Erweiterung JIT14_01 verwendet werden.

Für den Auftraggeber TEST mit der Partnerbezeichnung KUNDENWERK wird der JIT-Abruf TEST001 als Vorlage verwendet. Dieser soll auf mehrere JIT-Abrufe kopiert werden. Das Intervall für die zu erstellenden JIT-Abrufe in der Selektion beginnt von TEST002 und endet bei TEST003. Das bedeutet, dass das Programm zwei JIT-Abrufe erstellen soll und dies ist nur möglich, wenn beim Vorlageabruf TEST001 die gleiche Menge bei der Abrufkomponente hinterlegt ist – also 2 Stück. Über den Haken „Simulation“ kann geprüft werden, ob eine Erstellung der JIT-Abrufe möglich ist und ob beispielsweise die Menge verteilt werden kann.
Außerdem ist zu beachten, dass das Programm zu Beginn prüft, ob der Vorlageabruf aus genau einer Abrufkomponente besteht. Ist dies nicht der Fall wird das Programm verlassen. Eine Überprüfung auf den Abruftyp, zum Beispiel ob es sich um einen Mengenabruf handelt, findet nicht statt.
In der Praxis ist der Einsatz der Transaktion JITEMRA für produktionssynchrone Abrufe nicht sinnvoll, da vom Kunden nicht immer der gleiche JIT-Abruf abgerufen wird, der dann n-mal auf weitere JIT-Abrufe kopiert werden kann. Zudem wird häufig mehr als eine Abrufkomponente vom Kunden bestellt, was wiederum das Programm der JITEMRA für PABs unbrauchbar macht. Wird allerdings ein Mengenabrufprozess mit einer Teilegruppe und mit einer Abrufkomponente verwendet, ist es denkbar die Programmlogik in der Praxis.

© Praxishandbuch JIT/JIS mit SAP

What is a JIT call (Just in time call, Feinabruf)?

JIT call-offs (in opposite to forecast delivery schedules) are used for orders (detailed to minutes) to get deliveries from a vendor. With mentioned supplier should exist a document named Contract with deliveries schedule. Usually, the times sent to supplier are firmed and can no longer be changed. In the automotive industry JIT calls are handled by EDI and sent with the EDI message format according to VDA4915.

Translated from Wikipedia.

The JIT concept was described by Henry Ford in his 1923 book, My Life and Work:

We have found in buying materials that it is not worthwhile to buy for other than immediate needs. We buy only enough to fit into the plan of production, taking into consideration the state of transportation at the time. If transportation were perfect and an even flow of materials could be assured, it would not be necessary to carry any stock whatsoever. The carloads of raw materials would arrive on schedule and in the planned order and amounts, and go from the railway cars into production. That would save a great deal of money, for it would give a very rapid turnover and thus decrease the amount of money tied up in materials.

„Kleine, aber feine“

Outbound sequenced JIT calls

Outbound sequenced JIT calls (JIT Outbound to Sub-Supplier) means you receive an inbound sequenced JIT call from your customer (in our case from the automotive conveyor’s SAP SCM).
Specifies that it is a matter of a JIT outbound call to a sub-supplier. The sequenced JIT call therefore refers to an inbound sequenced JIT call.
This JIT call may resemble the following diagram:

Call components from the inbound sequenced JIT call can be directly passed on to a sub-supplier in an outbound sequenced JIT call. The BOM components can also be passed on to your sub-supplier.
You must maintain a JIT control cycle for both types of call components. You also have to set the BOM explosion indicator in the JIT basic data for call components that have to be exploded.
A control cycle consists of a material, a plant and the supply area. The system determines the supply area in three steps.
You must define this control cycle specifically for a material and a plant.
The components in a components group must always have the same JIT call profile.

Daimler

  1. Background task program in SCM creates seqjit-idocs from APO orders and transfers them to ERP (NB: into ERP JITM e.g.).
  2. Background task program in ERP carrying out JITM transaction with the action „Create outb.JC from inb.JC“ (creates outb.seq/sum.JCs from these inb.seqjits).
  3. Now we are applying as usual our actions („Create delivery“ etc) in JITOM to newly imported jito-calls.

EWM wiring

  1. Background task program in SCM creates seqjit-idocs from APO orders and transfers them to ERP (identical as Daimler way).
  2. In opposite to the Daimler process – EWM way missed the part with converting Inb.JIT to Outb.JITO.
  3. Now we are applying as usual our actions („Create delivery in EWM_PRD“ etc) in JITM to newly imported jit-calls.

S2L (APO planning results – in other words: requirements – are transferred into ERP purchasing schedule agreements)

  1. Setting up S2L with CIF-conditions.
  2. S2L creates outbound contol-cycle based sum.JITO-calls, depending on APO-demands from SCM via CIF.
  3. According to jit control profile in a control cycle, we’ree applying „Create TO“ (WMS), „Create EWM delivery“ or „Create ERP delivery“ actions.

SCM > ERP > Vendor

  1. Create a purchasing scheduling agreement 550000XXXX.
  2. Sending DELFOR forecasts to supplier from this agreement
  3. Create Control cycle with this MM SA.
  4. Background task program in SCM creates seqjit-idocs from APO orders and transfers them to ERP (NB: creating Z-action is an Interlinked Action – CREA + OCRE)
  5. No we have 2-linked calls (external jitcall number in JITM can be seen as „Key“ in JITOM). Table JITOIT has vendor number from related Control Cycle.
  6. Linked direction call can be viewed JITM-Goto-Outbound or JITOM-Goto-Header
  7. NACE condition PA > MAED depending on outbound JIT-call profile (not Call control) sends release to vendors on JC creating. This function can also be done through Z-action „Send order to vendor“ in JITOM. IDoc field E1PSJCL-GRPIN contains component group number.
  8. Depending on the method of creating JC – using S2L or JIT1 – the IDoc field E1KSJCL-ABTYP will contain „D“ (Summarized JIT Call) or „S“ (Sequenced JIT Call)
  9. Supplier sends a response ASN and create inbound delivery (calling FM JITOUT01_INSERT_PABASN / MABASN_UPDATE_RELATION_MAB_ASN will links the delivery to the component group in PABASN table), using seq. E1EDL24-KANNR as customer call number/key.
  10. Based on the link PABASN=InbDel, GR on inbound delivery will update status of linked JIT-call

Delivery confirmations for JIT Outbound can be seen in tables DLCNOCO and DLCNOHD
For JIT Inbound – DELCONCO, DELCONHD, DELCONJITCO and DELCONJITIT

S2L – save planning mode on jitcall

S2L allows 4 modes of planning, defined and used during jit calls creation. These four modes are described as a type s2l_planning_mode (type c):

  • initial – s2l_no_planning
  • 1 – s2l_plan_by_wish_qty – use replenishment quantity entered at segment level
  • 2 – s2l_plan_suggest_keep_firmed – automatically create plan but keep firmed quantities
  • 3 – s2l_plan_suggest_all – automatically create plan.

Selecting „Change mode with Replenishment Proposals“ will set planning mode to „3“ (s2l_plan_suggest_all):

The task is to mark the created jitcalls depends on the used planning mode („auto/manual“), so it means to save the mode value into the JITOIT table (JITOCO struture appendix) additional z-field.

S2L has few enhancements:

  • S2P_PLNG_SEG_EXTEN (transaction S_KA5_12001164)
  • S2P_PLNG_ITEM_EXTEN (transaction S_KA5_12001165)
  • S2P_GROUP_PLNG_ITEMS (transaction S_KA5_12001166)
  • S2P_PLN_CALC_FACTORY (transaction S_KA5_12001167)
  • S2P_PROPOSAL_CREATOR (transaction S_KA5_12001168)
  • S2P_PSEG_CTR_FACTORY (transaction S_KA5_12001169)

So, after adding the appends YYS2LMODE into JITOCO and PKHD we implementing classic BAdI Interface IF_EX_S2L_PLN_CALC_FACTORY:

Because of ccy_ctrl->pkhd_ref is declared as RO (read only) attribute and can be changed only within the class – I’ve enhanced class interface CL_PKHD_DB_PK with metod

which called above.

The field pkhd-yys2lmode will be move corresponding into JITOCO (JITOIT).