S2L – save planning mode on jitcall

By Ruslan on November 1, 2017

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:

method IF_EX_S2L_PLN_CALC_FACTORY~CREATE_PLNG_CALCULATION.

* type s2l_planning_mode type c:
* s2l_no_planning - initial
* use replenishment quantity entered at segment level
* s2l_plan_by_wish_qty - '1',
* automatically create plan but keep firmed quantities
* s2l_plan_suggest_keep_firmed - '2',
* automatically create plan
* s2l_plan_suggest_all - '3'.

select * from zparam into corresponding fields of table lt_params where paramid = 'YS2L_PLAN' and paramval = 'X'.
if sy-subrc eq 0.
  data ccy_ctrl type ref to cl_ccy_pseg_control_s2l.
  ccy_ctrl ?= segment->control.
  if segment->planning_mode is not initial.
    call method ccy_ctrl->pkhd_ref->yset_plan exporting y_plmod = segment->planning_mode.
  endif.
endif.
endmethod.

method IF_EX_S2L_PLN_CALC_FACTORY~CREATE_PLNG_CALCULATION.

* type s2l_planning_mode type c:

* s2l_no_planning - initial

* use replenishment quantity entered at segment level

* s2l_plan_by_wish_qty - '1',

* automatically create plan but keep firmed quantities

* s2l_plan_suggest_keep_firmed - '2',

* automatically create plan

* s2l_plan_suggest_all - '3'.

select * from zparam into corresponding fields of table lt_params where paramid = 'YS2L_PLAN' and paramval = 'X'.

if sy-subrc eq 0.

data ccy_ctrl type ref to cl_ccy_pseg_control_s2l.

ccy_ctrl ?= segment->control.

if segment->planning_mode is not initial.

call method ccy_ctrl->pkhd_ref->yset_plan exporting y_plmod = segment->planning_mode.

endif.

endmethod.

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

YSet_Plan (Y_PLMOD type C)

1	YSet_Plan (Y_PLMOD type C)

which called above.

method yset_plan.
  me->val-s-yys2lmode = y_plmod.
endmethod.

method yset_plan.

me->val-s-yys2lmode = y_plmod.

endmethod.

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

S2L, SCM
No comments

EDI-Cookies

By Ruslan on September 23, 2017

Plätzchen zum Neuen Jahr von der Firma „EDISoft“, unserem EDI Dienstleister 🙂

EDI, IDoc, ORDRSP
No comments

S2L set up

By Ruslan on Februar 22, 2017

S2L results can be easily changed using enhancements in FM JITOUT04_SET_ACTION_INTERN.
As well as creating enhancement to the class CL_APO_MANAGER_S2L.

Note, that S2L will call this FM for every Call Control group in the final Supply Segments.

Destinations (or logical systems) are fetched from db-tables CIF_IMAX and CIF_IMOD (integration models can be created-activated-viewed using CFM1-CFM4 transaction codes). The destination determined through numerous parameters: material number, supply area, shipping point and so on.
The determination FM’s are CIF_IMOD_DESTINATIONS_RPM and CIF_IMODEL_CHECKACTIVEENTRIES (parameter IV_IMTYP type CIF_IMOD-IMTYP = T_RPM).

FM CIF_IMOD_DESTINATIONS_RPM fetches data from CIF_IMRPM, a table for RPM recipient determination.

Getting requirements from APO done via module S2L_APO_REQS_GET.

Reservation and dependent requirements are generated from table RESB into views V_S2L_RESB and V_S2L_RESB_NB (postprocessing records for production supply)

SAP S2L JIT

Component groups are splitting via FM JITOUT03_DETERMINE_COMP_GROUPS (e.g. modify outbound call action OMOD ‚FM JITOUT04_ACTION_MODIFY_JC‘ corresponds and uses the same logic), depends on JIT call profile setting CPABPRF-PABZUS (‚Grouping by‘ of summarized JIT calls, can be reached via „Define JIT call profile“ tree in IMG):
eq 0: no aggregation
eq 1: summary by plant
eq 2: by plant and unloading point (jitodiaco_ls-ablad aka Storing Position)
eq 3: aggregation by plant, unloading point and supply area (jitodiaco_ls-prvbe):

TABLES: PPC_HEAD

P.S. To generate and reconcile runtime versions of active models you can use program RCIFIMAX.
#S2L015: No logical system found for material and plant
of8MGuxyKawb{xr5ixKg6m

S2L, SumJC
No comments

Manage S2L partitioning

By Ruslan on Januar 20, 2017

FUNCTION jitout04_set_action_intern.
ENHANCEMENT 1  YS2L_UMSTRUKTURIERUNG.
if sy-tcode eq 'S2L'.
 types: begin of t_params,
   paramval type char7,
   parampos type parampos,
   quant type char15,
   jitoline type jitodiaco,
   jitosum type  jitodiait,
 end of t_params.
 data: lt_params type table of t_params,
       wa_params like line of lt_params,
       lt_jitodiaco type jitodiaco_tt,
       ls_jitodiaco type jitodiaco,
       lv_maxoutpo type n length 10 value 0,
       lv_parampos type i, lv_quant type i,
       yjito type ref to YCL_IM_JITO_ACTION.
 create object yjito.
 loop at jitodiaco_ct[] into ls_jitodiaco.
   "keep suggested CG max:
   if ls_jitodiaco-outpo > lv_maxoutpo.
     lv_maxoutpo = ls_jitodiaco-outpo.
   endif.
   "removing trailing dot and zeroes from quant (decimal):
   write ls_jitodiaco-quant to wa_params-quant left-justified no-grouping decimals 0.
   move: wa_params-parampos to lv_parampos, wa_params-quant to lv_quant.
   "only exceeded Qts are in processing list:
   if lv_parampos < lv_quant.
     wa_params-jitoline = ls_jitodiaco.
     "assign the same teilegruppen to the components:
     read table jitodiait_ct into wa_params-jitosum index wa_params-jitoline-outpo.
     append wa_params to lt_params.
   endif.
 endloop.
 if lt_params is not initial.
   data: lv_intcycles type i, v_intcycles type i, lv_lastquant type i.
   loop at lt_params into wa_params where paramval ne 0.
     move: wa_params-quant to v_intcycles, wa_params-parampos to lv_lastquant.
     lv_intcycles = v_intcycles div lv_lastquant.
     call method yjito->addrecords
         exporting
           lastquant     = v_intcycles mod lv_lastquant
           teil          = wa_params-parampos
         changing
           jitosum       = wa_params-jitosum
           jitodiacoline = wa_params-jitoline
           intcycles     = lv_intcycles
           jitodiaco_ct  = jitodiaco_ct
           jitodiait_ct  = jitodiait_ct
           maxoutpo      = lv_maxoutpo.
   endloop.
 endif.
endif.
clear: lt_jitodiaco, ls_jitodiaco.

ADDRECORDS method

method addrecords.
if lastquant eq 0.
  jitodiacoline-quant = teil.
  modify jitodiaco_ct from jitodiacoline transporting quant where pknum = jitodiacoline-pknum.
  "rounding value is divisible by TEIL (remainder/lastquant = 0) decreasing cycles count:
  subtract 1 from intcycles.
else.
  jitodiacoline-quant = lastquant.
  modify jitodiaco_ct from jitodiacoline transporting quant where pknum = jitodiacoline-pknum.
endif.
data: i type x value 0,
      lv_outpo type char3,
      pkn type char7.
write maxoutpo to lv_outpo right-justified.
while ( i < intcycles ).
  pkn = 'R' && lv_outpo && 'Y' && i.
  add 1 to i.
  jitodiacoline-outpo = maxoutpo + i.
  jitodiacoline-quant = teil.
  jitodiacoline-jcpos = '0001'.
  "jitodiacoline-pknum = pkn.
  append jitodiacoline to jitodiaco_ct.
  jitosum-outpo = maxoutpo + i.
  append jitosum to jitodiait_ct.
endwhile.
maxoutpo = maxoutpo + intcycles.
endmethod.

ABAP, ISAUTO_JIT
No comments

Add a new field to selection screen of S2L

By Ruslan on Dezember 30, 2016

How to add a pair of new fields „Planned requirement date“ and „Planned requirement time“ to the S2L transaction selection screen?

The steps described below cover all the configuration and code changes to add select option for SY-DATUM and SY-UZEIT on selection screen of S2L transaction under all the fields. The same steps can be used to add any other applicable field on any of S2L forks.

S2L transaction and all of its forks internally call program RS2L_SELSCREEN_ENTRY.

In our case we won’t copy the whole program but only rename and modify top include report IS2L_SELSCREEN_ENTRYTOP.
Definition of selection-screen inside it (include file is2l_selscreen_entrysel) will be also renamed and modified.
The third modification(+rename) is include IS2L_SELSCREEN_ENTRYPAI, so finally we have inside our new program ‚YS2LOrd‘ only 3 forked files, keeping all the mechanism of standard S2L working as usual. This way also allows keep sure that already S2L-integrated enhancements, userexits, BAdI’s and etc won’t be missed. Vice versa – all the new additions to standard S2L will immediately appears in our fork ‚YS2LORD‘:

Adding date and time fields to YIS2L_SELSCREEN_ENTRYSEL:

selection-screen begin of block yblock with frame title text-029.
 
selection-screen begin of line.
selection-screen position 15.
parameters: reqdate type sy-datum.
selection-screen comment 1(10) text-021 for field reqdate.
 
selection-screen position 43.
parameters: reqtime type sy-uzeit.
selection-screen comment 30(10) text-022 for field reqtime.
selection-screen end of line.
 
selection-screen end of block yblock.
 
selection-screen end of block main.

To proccess only own session, we added the next code to YIS2L_SELSCREEN_ENTRYPAI:

MODULE process_1001 INPUT.
 
  data: opcode_SID type x value 68,
        SID(32) type c,
        gv_uniq(33) type c,
        id_len type i.
 
    call 'ThUsrInfo' id 'OPCODE' field opcode_SID
            id 'SESSION_ID' field SID
            id 'ID_LEN' field id_len.
    gv_uniq = SID && sy-modno.
    export reqdate to memory id gv_uniq.
 
    gv_uniq = SID && 'R'.
    export reqtime to memory id gv_uniq.
 
  ta_mode = s2l_selfields-ta_mode.
 
ENDMODULE.

The date and time, entered in our new fileds will be updated as an enhancement in the beginning of FM JITOUT08_CREATE_JITCALL:

ENHANCEMENT 1  YS2L_BEDARFSDATUM.    "active version
***** Geplantes Bedarfsdatum
if sy-cprog eq 'YS2LORD'.
  data: opcode_SID type x value 68,
        SID(32) type c,
        gv_uniq(33) type c,
        id_len type i,
        lv_timestamp type tzntstmps,
        lv_reqtime type sy-uzeit,
        lv_reqdate type sy-datum,
        lt_jito type jitodiaco_tt,
        wa_jito like line of lt_jito.
 
  call 'ThUsrInfo' id 'OPCODE' field opcode_SID
        id 'SESSION_ID' field SID
        id 'ID_LEN' field id_len.
  gv_uniq = SID && sy-modno.
  import reqdate to lv_reqdate from memory id gv_uniq.
 
  if lv_reqdate <> '00000000'.
    gv_uniq = SID && 'R'.
    import reqtime to lv_reqtime from memory id gv_uniq.
 
    call function 'CONVERT_INTO_TIMESTAMP'
      exporting
        i_datlo     = lv_reqdate
        i_timlo     = lv_reqtime
        i_tzone     = sy-zonlo
      importing
        e_timestamp = lv_timestamp.
 
    loop at jitodiaco_ct into wa_jito.
      wa_jito-rdate = lv_timestamp.
      modify jitodiaco_ct from wa_jito transporting rdate.
    endloop.
  endif.
 
endif. " sy-cprog
ENDENHANCEMENT.

JIT outbound, S2L, SumJC
No comments

ABAP: Processing and modifying outbound JIT-calls

By Ruslan on Oktober 11, 2016

As I’ve said before – user-defined actions for JIT outbound can be implemented into BAdI interface IF_EX_JITO_ACTION (BAdI JITO_ACTION).

Below you can find JIT-action ZSDJ, which added into call control flow and doing next things with component groups, selected in JITOM transaction and accumulated in system structure JITODIACO_CT:
– a popup window with two input fields DATE and TIME
– converting these DATE and TIME into TIMESTAMP
– updates required planned date and time of selected component groups (JITODIACO_CT).

method IF_EX_JITO_ACTION~CUSTOMER_ACTION.
 
if action_iv = 'ZSDJ'.
 
 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 = 'Укажите дату:'.
 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 = 'Укажите время:'.
 append lt_fields to ivals.
 
 call function 'POPUP_GET_VALUES'
  exporting
   popup_title = 'Запланированная дата потребности'
  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.
 
endif.
 
endmethod.

ABAP, BAdI, JIT outbound, realzeitbetrieb
No comments

Components group material determination using a customer exit

By Ruslan on Oktober 6, 2016

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.

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.

Test and activate Enhancement JIT14_01 using SMOD and

Now you can open FM EXIT_SAPLJIT14_001 and create in it the include ZXJIT0U17:

*&---------------------------------------------------------------------*
*&  Include           ZXJIT0U17
*&---------------------------------------------------------------------*
*"  IMPORTING
*"     REFERENCE(DOCNUM_IV) LIKE  EDIDC-DOCNUM
*"  TABLES
*"      IDOC_DATA_IT STRUCTURE  EDIDD
*"      JITDIAPO_CT STRUCTURE  JITDIAPO OPTIONAL
*"      TXTID_JITTE_CT TYPE  JIT00_TXTID_JITTE_T OPTIONAL
*"      JITDIAHD_CT STRUCTURE  JITDIAHD OPTIONAL
*"      JITDIAPODEF_CT STRUCTURE  JITDIAPODEF OPTIONAL
*"  CHANGING
*"     REFERENCE(JITDIAHD_CS) LIKE  JITDIAHD STRUCTURE  JITDIAHD
*"       OPTIONAL
*"     REFERENCE(JITDIAPODEF_CS) LIKE  JITDIAPODEF STRUCTURE
*"        JITDIAPODEF OPTIONAL
...
sort jitdiapo_ct by liumf fldpo ablad rdatum rzeit.
...
sort jitdiapo_ct by kdmat fldpo ablad rdatum rzeit.
  "grouping by kdmat fldpo
...

Assigning call control to should be done via transaction JITV

ABAP, CG, JIT inbound, User Exit
No comments

JIT outbound actions

By Ruslan on Oktober 5, 2016

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
- 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.

actions, JIT
1 comment

Batch split in DESADV (same material)

By Ruslan on September 11, 2016

To create an inbound delivery creation with Batch Split functionality (Message Type DESADV, Process Code DELS). We need to passing below values on inbound IDOC:
Method 1 (with SNOTE 209240):

E1EDL24:

POSNR: 000010 (the splitted position)
MATNR: TEST-10
WERKS: 4020
LGORT :1000
CHARG: A0000000
LFIMG: 8 (3 PCs out of any Batch)
VRKME: PCE

E1EDL24:

POSNR: 900001
MATNR: TEST-10
CHARG: A0000010 (vendor’s batch number)
WERKS: 4020
LGORT: 1000
LFIMG: 2
VRKME: PCE
HIPOS: 000010 (main position number)
HIEVW: 1 (to use HIPOS)
(+classification):
E1EDL15-ATNAM: ZGTD_NUMBER
E1EDL15-ATBEZ: НОМЕР ГТД
E1EDL15-ATWRT: 953/469-218

E1EDL24:

POSNR: 900002
MATNR: TEST-20
CHARG: A0000011
WERKS: 4020
LGORT: 1000
LFIMG: 3
VRKME: PCE
HIPOS: 000010 (main position number)
HIEVW: 1 (to use HIPOS)
(+classification):
E1EDL15-ATNAM: ZGTD_NUMBER
E1EDL15-ATBEZ: НОМЕР ГТД
E1EDL15-ATWRT: 953/469-219

Method 2 (w/o SNOTE 209240 – so the mapping of the vendor batch (E1EDL24-CHARG, LIPS-LICHN) to the customer batch (LIPS-CHARG) is not known:

The position of inbound delivery – is segment E1EDL24. In case of position contains a batch number from supplier – the segment E1EDL24 will have a subsegment E1EDL19 with the batch name/number. In case of inbound delivery position contains more than 1 batch number, we need to fill E1EDL19 Qualifier value as „BAS“ (BAtch Split):

Classifications are inside E1EDL15, as shown above (we can create them how many we need):

DESADV, IDoc
No comments

IDoc statuses

By Ruslan on Oktober 9, 2015

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

ABAP, IDoc
No comments

S2L – save planning mode on jitcall

EDI-Cookies

S2L set up

Manage S2L partitioning

Add a new field to selection screen of S2L

ABAP: Processing and modifying outbound JIT-calls

Components group material determination using a customer exit

JIT outbound actions

Batch split in DESADV (same material)

IDoc statuses

More information about Inbound statuses

More information about Outbound statuses

Miscellaneous

Neueste Beiträge

Kategorien