Delivery schedule/JIT delivery schedule integration

SEQJIT

If only forecast delivery schedules are sent from the customer scheduling agreement (no JIT delivery schedules) JIT delivery schedules can be generated from the JIT calls.
Using this method, you are given the option of (manually) comparing the planning (FDS) with the JIT calls.

JIT inbound actions (SeqJC, SumJC)

The action is a part of call control. It has a logistical or technical effect on a components group. This may be the printing of a components list or the creation of a delivery, for example. You can define the internal processing status of the components group for which an action is permitted and the internal processing status the components group is to receive once the action has been carried out. Actions can be triggered by:

  • An incoming JIT call by EDI and an external status change.
  • A user dialog in the system, such as a progress confirmation.

Integration

  • You define the possible actions in Customizing for JIT Inbound. You can use the standard actions provided or define your own actions. If the actions you have defined yourself:
    1. Simply cause a change in the internal processing status, you can enter them in Customizing in the table.
    2. Trigger a function as well as changing the internal processing status, you can use a customer exit.
  • You define the possible actions in Customizing for JIT Outbound. Internal actions can only be triggered when you receive a call by EDI or with internal system activities and not in a user dialog.
  • You can also interlink actions in Customizing. The system then carries out two or more actions together.

Features

The system provides the following actions as standard
(the code of actions kept in the functional modules):

Action Function Description
Actions for Creating and Changing
CREA Create JIT call The system creates the call in the system and arranges it in the call structure. This action is usually triggered by a forecast signal from the OEM.
MODI Change JIT call (total) The system changes the total call.
The action MODI is contained in action PIN. See also: Action PIN.
MODH Change call (call header and components group) With the external status change, for example, the system changes only the call header and the components groups.

Read the rest of this article

ABAP: Deny action on JIT-calls processing

ENHANCEMENT-POINT YPDENY_OFIN SPOTS YDENY_OFIN .
if ( chained_action_iv eq 'XX20' or chained_action_iv eq 'XX30' ) and action_iv = action_outbound_finish_gc. "OFIN
data: begin of it_benum occurs 0,
        outpo type ltak-benum,
      end of it_benum,
      begin of lt_benum occurs 0,
        outpo type SYCHAR50,
      end of lt_benum.
loop at jitodiaco_ct into wa_jito.
  append  wa_jito-outpo to it_benum.
endloop.
 
select ltak~tanum from ltak inner join ltap
 on ltak~tanum eq ltap~tanum into table lt_benum
 for all entries in it_benum[] where ltak~benum = it_benum-outpo and ltap~pquit = 'X' and ltap~vorga <> 'ST' and ltap~vorga <> 'SL'. "ST/SL - should not be cancelled
 if sy-subrc eq 0.
  message s002(Y_SAP).
  read table lt_benum into sy-msgv1.
 
  call function 'JITOUT04_FILL_ERROR_TABLE'
  exporting
    sy          = sy
  changing
    jitodata_cs = jitodata_cs.
  message s002(Y_SAP)
    with sy-msgv1
    raising no_action_done.
 endif. "sy-subrc eq 0
endif. "ACTION_IVs

JIT action, mass change planned requirements date

BAdI interface IF_EX_JITO_ACTION.
JIT-action ZDAT creates popup window with date and time fields.

method if_ex_jito_action~customer_action.
"*********************************** jit.sap.sd, 09.2015"
" IMPORTING"
" REFERENCE(ACTION_IV) TYPE CJIT07-AKTION"
" REFERENCE(CHAINED_ACTION_IV) TYPE CHAR1 DEFAULT ' ' "
" REFERENCE(FRAME_ACTION_IV) TYPE CJIT07-AKTION OPTIONAL"
" EXPORTING"
" REFERENCE(STATUS_UPD_DONE_EV) TYPE CHAR1"
" CHANGING"
" REFERENCE(JITODIAHD_CT) TYPE JITODIAHD_TT OPTIONAL"
" REFERENCE(JITODIAIT_CT) TYPE JITODIAIT_TT"
" REFERENCE(JITODIACO_CT) TYPE JITODIACO_TT OPTIONAL"
" REFERENCE(JITOAD_CT) TYPE JITOAD_TT OPTIONAL"
" REFERENCE(JITO_IT_SPEC_CT) TYPE JITO_IT_SPEC_TT OPTIONAL"
" REFERENCE(ASYNC_POSTING_CV) TYPE CHAR1 DEFAULT ' ' "
" REFERENCE(MSSG_RET_CT) TYPE MSSG_RET_TT"
" REFERENCE(JITODATA_CS) TYPE JITODATA OPTIONAL"
" EXCEPTIONS"
" NO_ACTION_DONE"

case action_iv.

"**********************************"

when 'ZDAT'. "Geplantes Bedarfsdatum"
data: l_returncode(1) type c,
ivals type table of sval,
lt_fields type sval,
lv_foop type sval,
lv_xdate type datum,
lv_xtime type uzeit,
ls_jitodiaco type jitodiaco,
lv_timestamp type tzntstmps.

clear: lt_fields.
lt_fields-tabname = 'RKAUF'.
lt_fields-fieldname = 'TODATE'.
lt_fields-value = sy-datum.
lt_fields-field_obl = 'X'.
lt_fields-fieldtext = 'Set the date: '.
append lt_fields to ivals.

clear: lt_fields.
lt_fields-tabname = 'SFSRFW_TIMES'.
lt_fields-fieldname = 'CREATETIME'.
lt_fields-field_obl = 'X'.
lt_fields-value = sy-uzeit.
lt_fields-fieldtext = 'Set the time: '.
append lt_fields to ivals.

call function 'POPUP_GET_VALUES'
exporting
popup_title = 'Planned requirements date'
importing
returncode = l_returncode
tables
fields = ivals
exceptions
error_in_fields = 1
others = 2.

if l_returncode eq 'A' or sy-subrc <> 0.
" lv_error = 'X'."
exit.
else. " √ -ОК-!"
loop at ivals[] into lv_foop.
if lv_foop-fieldname eq 'TODATE'.
lv_xdate = lv_foop-value.
else.
lv_xtime = lv_foop-value.
endif.
endloop.

call function 'CONVERT_INTO_TIMESTAMP'
exporting
i_datlo = lv_xdate
i_timlo = lv_xtime
i_tzone = sy-zonlo
importing
e_timestamp = lv_timestamp.

if jitodiaco_ct[] is not initial.
loop at jitodiaco_ct into ls_jitodiaco.
update jitoit set rdate = lv_timestamp where outpo eq ls_jitodiaco-outpo and intst eq 'XX10'.
endloop.
endif.

endif.

"ZDAT"
endcase.
endmethod.

JITR: Reorganisation Grunddaten

Die Transaktion JITR wird als Reorganisation der Grunddaten bezeichnet und wird immer dann verwendet, wenn bestehende Daten aus dem JIT bereinigt werden sollen. Je
nach Anwendungsfall stehen in der Transaktion drei verschiedene Funktionalitäten zur Verfügung:

  • Grunddaten im Shared Buffer neu aufbauen: SAP JIT speichert für die Optimierung der Performance Kundendaten, Materialdaten, Teilegruppendaten und die
    Komponentenliste im Shared Buffer. Dieser wird dann für das Prozessieren der Bewegungsdaten verwendet und das System liest nicht immer die Grunddaten neu
    nach, um so Performance einzusparen. Wenn sich Grunddaten im SAP JIT ändern, werden diese nicht automatisch im Shared Buffer aktualisiert, somit muss entweder
    eine manuelle Aktualisierung oder ein erneutes Aufbauen über einen beispielsweise zeitlich eingeplanten Hintergrundjob erfolgen. Folgendes Beispiel beschreibt diesen
    Fall. In Abschn. 3.4.1 wurde zur Teilegruppenfndung beschrieben, dass bei einer Teilegruppenfndung per Teilegruppenmaterial das Teilegruppenmaterial im Feld
    „Werksüberg.konf.Mat.“ im Materialstamm (Grunddaten 2) hinterlegt werden muss. Wird das Material im Feld „Werksüberg.konf.Mat.“ verändert, verwendet SAP JIT
    immer noch das zuletzt hinterlegte Teilegruppenmaterial. Um die Änderung im Shared Buffer durchzuführen, muss der Shared Buffer neu aufgebaut werden.
    Werden in der Praxis viele verschiedene Applikationsserver verwendet, empfehlt es sich die Transaktion JITR mit einzelnen Steps für jeden einzelnen Applikationsserver
    auszuführen. Würde der Haken „alle Server“ bei vielen Servern verwendet werden, so erhöht dies die Laufzeit des Hintergrundprogramms.

  • Reorganisation der JIT-Materialstammdaten: Unter JIT-Materialstammdaten werden Einträge aus der Tabelle JITMA verstanden. Die Tabelle JITMA bekommt
    immer neue Einträge hinzu, wenn ein neuer JIT-Lieferplan (Kennzeichen „J“ im Customizing für Verkaufsbelegarten) angelegt wird. Wird ein JIT-Lieferplan allerdings abgesagt, wird die Tabelle JITMA nicht automatisch aktualisiert. Nicht mehr benötigte Einträge können somit über die Funktion „Reorganisation der JIT-Materialstammdaten“ aus der Tabelle JITMA gelöscht werden.

  • Übernahme von neuen Lieferplanpositionen in bestehende Abrufe: Im Laufe eines JIT-Prozesses kann es vorkommen, das ein bestehender JIT-Lieferplan abgesagt
    und ein neuer JIT-Lieferplan angelegt werden muss. Die Zuordnung von JIT-Abrufe bzw. von der Teilegruppe zu den einzelnen JIT-Materialstammdaten findet über
    die Tabelle JITCO statt. Diese wird nicht automatisch aktualisiert, wenn ein nicht mehr benötigter JIT-Lieferplan abgesagt und ein neuer JIT-Lieferplan angelegt wird.
    Um lieferfähig bleiben zu können, muss dem JIT-Abruf der neue JIT-Lieferplan zugeordnet werden. Die Funktionalität „Übernahme von neuen Lieferplanpositionen
    in bestehende Abrufe“ aktualisiert die Einträge in der Tabelle JITCO und führt die relevanten neuen Zuordnungen durch.

© Praxishandbuch JIT JIS mit SAP

JIT: How Component group type assignment is done in call components?

sap-blau

How the system will does the job:

The system carries out this function automatically, each time a JIT call is received. In this way it assigns each call component transmitted to a components group type. The components group type then takes on the internal control of the call components.

With sequenced JIT calls for assemblies, the system assigns several call components to the same components group type. With the other call types the call components and the components group type form a logical unit and the system therefore assigns a different components group type to each call component.

In the components group determination the system compares whether the characteristics of the call components match a components group type. As soon as it can assign a call component, it continues with the next one. In the profile for the components group determination you can define with which priority the system should consider the various characteristics. The system determines the relevant characteristics of the call components as follows:

JIT customer

The JIT customer is made up of the sold-to party and the partner description and can therefore be taken from the IDoc.

Unloading point and assembly location

The unloading point and, if necessary the assembly location, are also transmitted with the JIT call. The system can also take these characteristics of the call components from the IDoc.

Components group material

The JIT customer generally transmits the components group material with a call. You have several options for defining the components group material of the call component before the components group determination.

You can realize an individual components group material determination using a customer exit. This is particularly recommended for sequenced JIT calls for assemblies, due to the large number of variants.

If you use the process for discrete materials, you can transfer the material of the call components as a components group material.

If you use the process for discrete materials and exactly one components group material can be assigned to a call component, you can transfer the configurable material of the call component as a components group material. To do this you must have entered the configurable material in the material master of the call component in the tab page Basic data 2 in the field Cross plant conf.mat.

Production version

You can also assign the production version using a customer exit. The production version allows you to assign two otherwise equal call components to different components group types, to produce them on different production lines, for example.

There are also call types – please follow the below link:

Call Structure and Call Types

IDocs sending

IDocs sending via ALE

JIT inbound from scratch proccess IMG

First of all we’ll create a plant, and then – sales organization:

SPRO > Enterprise structure > Definition > Define, copy, delete, check sales organization

img_56151a2c1b378

Checking SPRO – step by step:

Creating Reconciliation Account in General Ledger (FS00):

In OX19 please assign Control area to Control company (new entries).

Now we will create customer for JIT proccess, t-code XD01, on the tab page „Unloading points“ enter an unloading point:

On the „Sales area data > Shipping“ select the indicator Order combination.

On the tab page Partner Functions enter a Partner Description. If you want to enter other goods recipients, make an entry in the table.

XD02

Then you have created a JIS system partner profile (t-code WE20).

Next step – is to creating a couple of component group material (KMAT):


Read the rest of this article

JIT Humor

Receiving invoice via EDI: INCINV_CREATE

Basic types INCINV_CREATE01 / INCINV_CREATE02 – Incoming Invoice (IncomingInvoice) are available since EHP5.

Next MRM BAPI’es provides Invoice Verification:

  1. ALE_INCOMINGINVOICE_CREATE1
  2. BAPI_INCOMINGINVOICE_CANCEL – Invoice Verification: Reverse Invoice
  3. BAPI_INCOMINGINVOICE_CHANGE – Invoice Verification: Change Provisional Invoice
  4. BAPI_INCOMINGINVOICE_COMPLAIN – Invoice Verification: Display Letter of Complaint
  5. BAPI_INCOMINGINVOICE_CREATE – Invoice Verification: Post Invoice
  6. BAPI_INCOMINGINVOICE_CREATE1 – Invoice Verification: Hold/ Park/ Park As Complete/ Post Incoming Invo
  7. BAPI_INCOMINGINVOICE_DELETE – Invoice Verification: Delete Provisional Invoice
  8. BAPI_INCOMINGINVOICE_GETDETAIL – Invoice Verification: Display Incoming Invoice
  9. BAPI_INCOMINGINVOICE_GETLIST – Invoice Verification: List Incoming Invoices
  10. BAPI_INCOMINGINVOICE_PARK – Invoice Verification: Park Invoice
  11. BAPI_INCOMINGINVOICE_POST – Invoice Verification: Post Provisional Invoice
  12. BAPI_INCOMINGINVOICE_RELEASE – Invoice Verification: release invoice
  13. BAPI_INCOMINGINVOICE_SAVE – Invoice Verification: Flag Invoice for Background Processing

IncomingInvoice INCINV_CREATE IDoc will be passed to FM’s BAPI_IDOC_INPUT1 (Inbound BAPI IDoc: Individual Processing) or BAPI_IDOC_INPUTP (Packet Processing) which calls
IDOC_INPUT_INCINV_CREATE and subroutine CREATEFORMDATA1 (SAPLMRM_BAPI).

Sample IDoc INCINV_CREATE02 from quality system is listed below: