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.

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

JIT outbound actions

The action is a part of call control. The action carries out a logistical or a technical function for a components group, for example the posting of a goods receipt. You can define in which internal processing status of the components group an action is permitted and which internal processing status the components group should obtain after the action is carried out. Actions can be triggered by:

  • the receipt of a JIT call by EDI
  • a user dialog in the system, for example in Outbound JIT Monitoring (transaction JITOM)

JITOM transaction:
jitom_transaction

Integration

    • You define the possible actions in Customizing for JIT Outbound. You can use the actions provided as standard or define your own actions.
    • If the actions you have defined yourself
        • simply cause a change in the internal processing status, you can enter them in Customizing in the table.
        • trigger a function, as well as changing the internal processing status, you can use a Business Add-In (BadI).
      • You define the possible actions in Customizing for JIT Outbound. Internal actions are not visible in Outbound JIT Monitoring.
      • In Customizing, you also determine whether an action is relevant to the inbound process, to the outbound process or to both processes. JIT calls relevant to the inbound process are only displayed in Monitoring Inbound. JIT calls relevant to the outbound process are only displayed in Monitoring Outbound.
      • For summarized JIT calls outbound, actions are only relevant to the outbound process and are therefore only displayed in the Monitoring Outbound.
      • For sequenced JIT calls, actions are relevant to the inbound and the outbound processes, that is, they can be displayed in the inbound and the outbound monitoring.
      • 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
OAPP Add components group to JIT call outbound The system adds a components group to a summarized JIT call, that already exists in a summarized JIT call with the same material. Both components groups differ only in quantity and date.
JIT calls to which a components group can be added must:

  • contain the same material
  • not yet have been sent
  • be suitable with regard to timing

Should these conditions not be fulfilled, a new JIT call is created using the action OCRE.

OARC Archiving JIT Calls Outbound In archiving, the system selects only those JIT calls/components groups, whose internal processing status permits this action.
You can trigger archiving from transaction JITOA, however, not from Monitoring.
OCGR Reverse goods receipt The system cancels the material document. The status of the components group is set to the subsequent status you have defined. You can repost the goods receipt.
OCRE Create JIT calls outbound The system creates the call in the system and arranges it in the call structure. This action is triggered by a sequenced JIT call inbound for sequenced JIT calls outbound and manually using transaction PK23 for summarized JIT calls outbound.
This action only creates a new message record – no new IDoc is sent.
ODLC Send delivery confirmation for JIT calls outbound You send the delivery confirmation in transaction ODLC. This transaction triggers action ODLC.
After this action, the system sets the indicator showing that the delivery confirmation has been sent in the Outbound Monitoring.
ODLI Create delivery for summarized JIT call outbound (for stock transfer) The system creates a delivery, to which it adds the call components of the component groups selected.
This delivery is important for the creation of the transfer order which you need for an internal stock transfer within your plant.
OFIN Close components group outbound The system sets the status asclosed for this call outbound/components group.
OGRE Post goods receipt for JIT outbound The system posts the goods receipt for the JIT call outbound.
The goods receipt is posted cumulatively per material and supplier.
OMOD Modify JIT calls outbound The system changes the total call outbound.
This action only creates a new message record – no IDoc is sent at this stage.
OREO Delete JIT call outbound The system deletes the call from the database.
OREP Repeat send of outbound messages You use this action in emergencies, should any technical problems arise. The call is resent.
OSDD Send outbound message – process With this action, a message is sent for selected components groups if a message record exists for these components groups.
OSDP Send outbound call: create message You need this action for actionsOCRE and OMOD. In these two actions, action OSDP is carried out automatically by the system.
OSHP Process payment advice for outbound call. As soon as you have received the payment advice, the status of the sequenced JIT call is updated.

IDoc statuses

IDoc Inbound and Outbound statuses
Table TEDS1 contains list of all status codes.
Starting statuses may be: 01 (outbound), 50 (inbound), 42 (outbound test), 74 (inbound test)

St#
OK / NOK
Description Next success status Next error status Error reason and solution
01 Outbound IDoc created 30 29
02 Error passing data to port Correct the error and Execute RSEOUT00 program again
03 Outbound IDoc successfully sent to port None, 32
04 within control information on EDI subsystem
05 during translation
12 Dispatch OK Changed from status 03 by BD75 transaction (see below)
25 Processing outbound IDoc despite syntax errors
26 during syntax check of outbound IDoc Missing mandatory segment for example You may edit the IDoc or force it to be processed
29 ALE service (for example 29, 31
30 Outbound IDoc ready for dispatch (ALE service) 03 02 Partner profile customized to not run and execute RSEOUT00 program
31 no further processing
32 Outbound IDoc was edited There was a manual update of the IDoc in SAP tables, the original was saved to a new IDoc with status 33
33 Original of an IDoc which was edited. It is not possible to post this IDoc None None Backup of another IDoc manually updated, see status 32
35 IDoc reloaded from archive. Can’t be processed
37 Erroneous control record (for example, “reference” field should be blank for outbound IDocs) None, 37
42 Outbound IDoc manually created by WE19 test tool 01 37
50 Inbound IDoc created 64 65
51 inbound IDoc data contains errors 53, 64 51, 66, 68, 69 Error triggered by SAP application, incorrect values in the IDoc data and ask functional people, modify erroneous values in the IDoc (WE02 for example) and run it again using BD87
53 inbound IDoc posted None, 53
56 IDoc with errors added (You should never see this error code) 50, 51, 56, 62, 68
60 syntax check of inbound IDoc 56, 61, 62
61 Processing inbound IDoc despite syntax error 64
62 inbound IDoc passed to application 53 51
63 passing IDoc to application
64 Inbound IDoc ready to be passed to application 62 51, 60, 63, 68, 69  execute BD20 transaction (RBDAPP01 program)
65 ALE service – incorrect partner profiles 64, 65
66 Waiting for predecessor IDoc (Serialization) 51
68 no further processing 68 None The IDoc was created using inbound test tool (WE19) and written to file to do file inbound test. Another IDoc is created if immediate processing is chosen
69 IDoc was edited 64 51, 68, 69 There was a manual update of the IDoc in SAP tables, the original was saved to a new IDoc with status 70
70 Original of an IDoc which was edited. It is not possible to post this IDoc None None Backup of another IDoc manually updated, see status 69
71 Inbound IDoc reloaded from archive. Can’t be processed
74 Inbound IDoc manually created by WE19 test tool 50, 56

More information about Inbound statuses

  • 64 -> 62: There is no way to distinguish automatic call from manual call (BD20, RBDAPP01)
  • Though an IDoc may contain partner profile errors, we may force inbound processing (status becomes 62), but then an error will happen again
  • RSEINB00 program to process IDocs from a file
  • BD20 transaction (RBDAPP01 program) to process IDocs in status 64. If you want future IDocs to be processed immediately, change partner profile customizing (WE20).
  • RBDINPUT program:
    • status 51: BD73 / RBDMANIN
    • Status 56, 61, 63, 65: BD84 / RBDAGAI2
    • status 60: RBDSYNEI
    • status 62: IDocs remaining in status 62 is abnormal. Use program RBDCHSTA (Note 92552 – IDocs-Status 62 cannot be processed), so that to change their status back to 64 and process them again
    • status 64, 66: BD20 / RBDAPP01
    • status 68: WPIE / RBDAGAIE

More information about Outbound statuses

  • RBDOUTPU program:
  • status 02, 04, 05, 25, 29: BD83 / RBDAGAIN
  • status 26: RBDSYNEO
  • status 30: WE14 / RSEOUT00
  • status 32: WPIE / RBDAGAIE
  • -> 03 : IDocs are sent to the tRFC queue.
  • 03 -> 12 : use BD75 transaction (RBDMOIND program). Idocs with with status 03 are transferred to the tRFC queue. This does not mean that they are sent out, they may stuck up on that queue (e.g. receiver system is down) in that queue. BD75 checks if it can find the idoc in that queue. If so, it is not beeing send and status remains on 03. If it is not on the t-rfc queue, the systems considers that this icon is sent and change the status to 12.
    You can check the tRfc queue with SM58 and initiate resending by right click choosing execute LUW.
    in BD75 you can check “unsent idocs” and you will get a similar list.

  • Note 189887 – ALE: Help report to search for IDocs sent twice: program ZDUPLICATEIDOC

Miscellaneous

  • RC1_IDOC_SET_STATUS program to change IDoc status. Exists since 6.10
  • Monitor for Inbound and Outbound: BD87 / RBDMON00 to restart erroneous IDocs
  • Archiving:
    • RSEXARCA archives IDocs. They must be in an archivable status (not possible to archive IDocs in status 30 or 64, ie waiting to be processed).
    • RSEXARCL to reload IDocs from archive to the database. Status will be either 35 (outbound) or 71 (inbound).
    • WE47 to change STACUST table; see Note 26564 – IDoc: Can status values be defined?
  • RSECSTAT include contains constants for status

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

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

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

Own customer exit for JITL (JITPP)

Defining the production info describes principles of using the table JITPP (“JIT : Production Information”) – repetitive manufacturing (A), stock transfer (B) and customer exit (Z). Table field is JITPP-BAFLU.

The transaction for controlling this behaviour is JITL:

The last one (customer exit) is very typical customer-function call, which is calls from functional module JIT03_DO_BACKFLUSH (CALL CUSTOMER-FUNCTION ‘009’), so function EXIT_SAPLJIT03_009 transmits into include ZXJIT0U19 next structures:

JIT call main tables linking

Inbound:

Table JITMA (JIT Material Data)

JIT Material Customer Material Sales.Doc Item Base UoM
110063 DNFG 720000000034 30000001 10 PC
100900 DNFG 720000000098 30000002 10 PC
200014 DNFG 720000000011 30000003 10 PC

Table JITIT (Components Group)

Components group Call number CG type Call control External status Internal processing status
80111117 55000828 D051 0005 280 4000
80111118 55000828 D052 0009 280 4000
80111119 55000828 D053 0009 280 4000

Table JITHD (Call header)

Call number Customer Customer external JIT call number Sequence No. Call type Add.Info 1
55000828 DNFG 15000RASA37124 1882 S NB

Table JITCO (Call components)

Components group JIT Material Qty
80111117 110063 1
80111118 100900 1
80111119 200014 1

Outbound:
Inbound and outbound JIT-calls linked together (in case of) using field JITOIT-POSID.

Table JITOHD (Call header outbound)

Call key Call type External call number Sequence No.
404565 D (sum) / S (seq) 0000404565

Table JITOIT (Components Group JIT Outbound)

Call key Components group No. Internal Processing Status
404565 5000808746 0040
404565 5000808747 0040

Table JITOCO (Call components)

Components group No. Control cycle number Quantity
5000808746 88273 1
5000808746 119793 2
5000808747 133513 1

Table PKHD (Control cycle)

Control cycle number Material
88273 72110063
119793 72100900
133513 72200014