JIT transactions

VSB1N: Self billing monitor
EMJIT: IDoc-Monitor für JIT-Abrufe
JIT1, JIT2 und JIT3: JIT-Abruf anlegen, ändern, anzeigen
JIT4 und JIT5: JIT-Abruf Eingang: Simulation und Schnelländerung
JIT6 und JIT7: Aktionserfassung (Barcode) und mit Vorgabe
JITF: Fortschrittsmeldung
JITM und JITOM: JIT-Monitoring (In- und Outbound)
JITK: Versandfällige Mengenabrufe
JITR: Reorganisation Grunddaten
JITE und JITOE: Status-Korrektur (In- und Outbound)
JITEMRA: Notfallerzeugung gebündelter Mengenabruf
JITH: Abgleich JIT-Abrufe mit LAB/FAB
JITA: Komponentenliste
JITO: Check zur Lieferzusammenführung
JITL: Pfegedialog JIT-Material
JITB: Nachbearbeiten Rückmeldevorrat
JITG und JITOG: JIT-Cockpit (In- und Outbound)
JITJ: Impulsmonitor
JITLOG und JITLOGDEL: Aktionsprotokolle anzeigen und löschen
JITOAL: JIT-Outbound Alerting
JITQ: Aktionsnetz anzeigen
JITY und JITOA: Archivierung von JIT-Abrufe (In- und Outbound)
JITO1 und JITO3: JIT-Abruf anlegen, ändern, anzeigen (Outbound)
JITO6: Barcodeerfassung (Outbound)

VSB1N Self-Billing Monitor

Delivery procedure: JIT deliveries with invoice for day's collective delivery note. The delivery confirmation process (DELCON) from the Automotive JIT processing is used. Credit memos related to those delivery confirmations are processed by the SD Selfbilling (SBWAP).

B: Prerequisites

A ratio of 1 IDoc to 1 delivery note is intended for the IDoc GSVERF01 and SD inbound processing for self-billing.

The system reads the individual IDocs received from the EDI subsystem. The first IDoc creates a transmission.

What is the transmission?

When the transmission is ended or the processing step is started, the next inbound IDoc automatically causes a new transmission for the EDI partner to be created. This and any subsequent IDocs remain in the verification step until the transmission is again ended, or the processing step is started for the transmission.

Here, the IDoc transmission is ended by the automatic start of processing. The automatic start is triggered when the delay time has run out. Is it assumed that all IDocs for a transmission have been received by the end of the delay time.

SAP recommends to only use the option with time delay if the option with the target number is technically not possible.

What is Dynamic selection used for?

What if I am looking for a certain self-billing document? Here we can set the selection criteria and find it faster.

What is the current transfer?

The latest transmission you checked in the monitor.

Where can I see the errors?

Why is the transmission deactivated?

It is completely wrong, and we do not want to process it all. And someone pressed the button to deactivate the record:

Anyway, we can process the deactivated transmission (!) = > No impact on accounting.

If we need to process it, we can take it back by pressing the button 'Activate':

At which account are posted differences?

Processing indicator

Set the processing indicator in the list of transmissions, for those transmissions that ended without errors.

When you have set the processing indicator, the system no longer displays the transmission automatically in the status screen, nor is it included in the amounts shown. It still can be selected and displayed if you restrict the criteria dynamically.

How are the differences processed?

Where can I find information containing in the Self-billing document?

Automatic Posting in Case of Differences

The net value of the delivery note item must be transferred to the IDoc segment/field E1EDP26-BETRG with qualifier 003 . The value-added tax amount is adopted from E1EDP04-MWSBT and stored internally. The Self-Billing Monitor displays the gross amount (value inc. tax), which is dynamically calculated from the net item value and the value-added tax amount.

T: What are the main tables?

VSBTRM Transmission: Self-Billing Procedure w. Autom. Postings
VSBHDR IDoc Self-Billing Procedure w. Automatic Postings
VSBITM IDoc-Item Self-Billing Procedure w. Automatic Postings
VSBOII Self-Billing: Index of Generated Open Items
VSBPBD Self-Billing: Processed Billing Documents
VSBPST Processing Status: Self-Billing Procedure w. Autom. Postings
...

T: Inbound processing

Verification ( during SBWAP processing, manually ) / SE37: SD_SBWAP_PRESTEP ( Transferred data is still not processed in the verification step. )

Mandatory fields, delivery determination, materials, transaction currency,
Correct error / WE02?
Automatic or manual
Deactivate: On the screen "List of Deliveries", you can manually deactivate the incorrect records. These deactivated records are then no longer taken into account during the processing step and processing of subsequent records without errors is then possible. It ends in the status "Processing Finished w/o Errors"; however, it does not actually execute processing or create postings.

Actual processing / SE37: SD_SBWAP_MAINSTEP

System compares the quantities and values in the self-billing document with the quantities and values in the current billing document
Tolerance check
Default documents - > Open items

EMJIT: IDoc-Monitor für JIT-Abrufe

Die Transaktion EMJIT, der EDI-Monitor für JIT-Abrufe, zeigt alle eingehenden JIT-Abrufe des Nachrichtentyps SEQJIT an.

JIT1, JIT2 und JIT3: JIT-Abruf anlegen, ändern, anzeigen

JIT4 und JIT5: JIT-Abruf Eingang: Simulation und Schnelländerung

Transaction JIT4 opens the simulation mode of transaction JIT2. This means that transaction JIT2 is called, but it is not possible to save changed data. data is not possible. The simulation is useful if you want to check which data is used for which data is to be used for which part grouping.

With the transaction JIT5, the JIT call-off quick change, the JIT call-off can be changed using selection screen to change the JIT call. On this screen, the user is shown the most important data for the quick change.

JIT6 und JIT7: Aktionserfassung (Barcode) und mit Vorgabe

Progress recording by barcode is possible in JIT inbound via transactions JIT6 and JIT7. In both transactions, the entry is made with an entry object. This corresponds to the information from the scanned barcode. Information on barcode qualifiers and prerequisites for using transactions JIT6 and JIT7.

JITF: Fortschrittsmeldung

This function is generally only relevant for sequenced JIT calls, which you deliver in sequence. For summarized JIT calls the tracking of the processing status of individual call components is usually not necessary.

Trigger backflush
Create delivery
Complete JIT call

JITM und JITOM: JIT-Monitoring (In- und Outbound)

An Excel download of the data from transaction JITM is possible via transaction JITX. In doing so, the data is transferred to Excel as raw data. A clearly readable download is the export function in the JITM. This can be found via the menu finding when the program has been executed. An upload of sequence messages is possible through the JIT transaction JITXML.

JITK: Versandfällige Mengenabrufe

The transaction JITK provides a dispatch monitor that can be used exclusively for JIT call-offs for the JIT inbound. On the basis of the control profile for summarised JIT calls (MAB), which is assigned to the JIT customer, settings can be made for transaction JITK.

The dispatch monitor JITK uses the technical transaction VL10X with the scenario PDON.

JITR: Reorganisation Grunddaten

The transaction JITR is referred to as the reorganisation of basic data and is used whenever existing data from the JIT is to be cleaned up.

JITE und JITOE: Status-Korrektur (In- und Outbound)

JITEMRA: Notfallerzeugung gebündelter Mengenabruf

With the transaction JITEMRA it is possible to use a JIT call-off as a template and then copy it to n different new JIT call-offs.

JITH: Abgleich JIT-Abrufe mit LAB/FAB

Only delivery schedules and/or JIT delivery schedules from the underlying JIT delivery from the underlying JIT delivery schedules are used. However, it is possible to to generate JIT delivery schedules from JIT delivery schedules. This is possible with the transaction JITH.

When the transaction is executed, which is possible both via the background processing and manually, an IDOC of the message type DELINS is created. manually, an IDOC of message type DELINS with basic type DELFOR01 for the ordering party with partner function AG. The creation of the

partner profile is a prerequisite for using the functionality of transaction JITHfunctionality. When processing the IDOC, the SAP standard processing for delivery schedule/fine release is carried out with the process code DELI. In practice, transaction JITH is used as a step before MRP is scheduled as a background programm so that MRP can access the current requirement situation.

With this function you can match the requirements from JIT calls that you have already received, with requirements from JIT delivery schedules and forecast delivery schedules. In this way, it is clear from the evaluation, whether the requirements of the call components:

are critical: This means that the quantity called exceeds the quantity from the forecast delivery schedules or JIT delivery schedules. You may have problems with the availability of the components to be assembled.
are balanced: This means that the quantity called corresponds to the quantity from the forecast delivery schedules or JIT delivery schedules.
are not balanced: This means that the quantity called is less than the quantity from the forecast delivery schedules or JIT delivery schedules. It is possible that you have an unnecessarily high component stock.

From the evaluation, you can generate JIT delivery schedules for the call components, for the amount of the JIT requirements. Thus, you can react quickly to critical JIT calls.

JITMA, VBBE VS JITHD, JITIT.

JITA: Komponentenliste

With this evaluation you can also gain an overview of which materials your customer has called, and in which quantities. If you work in the JIT process without an availability check, you can evaluate the requirements of the components over a specific period of time. In this way, you can choose whether you want to evaluate call components only, or also their BOM components.

The transaction JITA: Component List can also be called a range of coverage list in practice and shows the user the range of coverage of the IM warehouse stock for the planned dispatch date of the JIT call-offs.

The entry of the field "Start date detailed display" is relevant for the entry of the programme, from when the IM stock is to be displayed for the JIT calls should be displayed. The selection is based on the JIT calls, but the display is based on the material number. basis of the material number.

JITO: Check zur Lieferzusammenführung

Transaction JITO is one of the transactions from the JIT inbound environment and is responsible for checking whether SD deliveries can be merged.

The check is only available to the user to check whether the master data is correct and whether a delivery combination is possible. master data are correct and whether a delivery combination is possible.

JITL: Pfegedialog JIT-Material

The transaction JITL determines plant-specifically for each call-off component which goods movement is to execute the JIT action BFLU (also for the JIT actions BFDL or BFLP).

JITB: Nachbearbeiten Rückmeldevorrat

The transaction JITB saves all failed goods movements of the JIT action BFLU or of customer-specific JIT actions, if this is implemented accordingly.

All entries are stored in the table JITBACKFTMP and displayed in the transaction JITB.

JIT01_INSERT_JITBACKFTMP

JITG und JITOG: JIT-Cockpit (In- und Outbound)

The transactions JITG for JIT inbound and JITOG for JIT outbound are used to visualize call-off data in order to see at a glance how many call-offs are in production and how many are currently being dispatched. for example, how many call-offs are in production and how many call-offs are currently being dispatched.

Die Transaktion JITS zeigt eine weitere Möglichkeit der grafschen Fortschrittsmeldung. Die Visualisierung der Komponenten kann über die Erweiterung JIT10_01 Userexit EXIT_SAPLJIT10_001 im HTML-Format beeinfusst werden.

JITJ: Impulsmonitor

Transaction JITJ can be used to open the impulse monitor for SAP JIT. This is relevant for the JIT inbound when production-synchronous call-offs are received from the customer. and shows whether the SEQJIT IDOC was processed successfully.

If an IDOC could not be processed, the respective line is displayed in red and the user quickly recognises that the respective IDOC must be processed in order to avoid a gap. to avoid a gap in the process. The transaction JITJ is automatically updated and can therefore be used as a "pulse monitor" in a second screen.

The transaction JITJ or the table JITIMP are filled automatically when the EDI receipt of the SEQJIT-IDOC, if the checkmark "Pulse monitor active" is set for the active" is set for the JIT customer.

JITLOG und JITLOGDEL: Aktionsprotokolle anzeigen und löschen

JITOAL: JIT-Outbound Alerting

Via transaction JITOAL, all alerts created for JIT outbound are displayed for JIT outbound call-offs are displayed for the JIT outbound if the "Activate alerts" checkbox is set in the call-off control.