Order Management Overview:

Current Landscape:

New Landscape:
Sources of Order to S4

- Manual NGQ
- EDI
- B2B
- B2BI
- DOE

NGQ

SFDC creates the Opportunity. NGQ creates the Quotes. Once the Quote is legalized, it will sit in QIDS
and sends a customer PO to NGQC.

NGQC will send the Quote information to S4 through middleware Seeburger. Seeburger will convert the
XML to IDOC and sends to S4.

In Fusion, OIS is the middleware used today.

EDI:

This is mainly for the Channel Partners. In 2.1, EDI is enabled only for BTO. The flow is from EDI -> OIS ->
NGQC -> S4. NGQC is used just to pass through.

B2B/B2BI

Both are ecommerce assets. The flow will be through OIS->NGQC->S4. If it is a Value order, it will follow
the review and release concept in NGQC. If it is Volume order, it will be just a pass through in NGQC.
NGQC is getting the details from CORONA to differentiate value and volume order.

DOE:

- In case of Direct Order entries, Orders will be directly created in S4 manually.

Orders to S4 Vs Fusion:

- Orders to the S4 and Fusion are identified based on the S4 flag in the Quote.
- For all electronic orders, the S4 flag will be set in the quote by the OIS middleware.
- For NGQ manual Orders, the S4 flag will be set in the NGQ.
- This flag will be set based on the Sold to Country, customer and partners.
- Based on this flag, NGQC will decide whether the order has to flow to S4 or Fusion.
Order creation Flow in S4:

Inbound IDOC Processing in S4:

- S4 will receive the IDOCS from Seeburger to create the Order.

- Once the IDOC reaches the S4, it will be in status 64. In the Partner Profile, the Inbound
Parameters are maintained as Trigger by background Program. So the IDOC stops in status 64.
- Then a job picks it and creates a second Idoc. The first IDOC will be set to 68 status. The second
idoc can be 51 Failed or 53 Success.

Job Name: 010_ZOM_QUOTE_CREATE

- This job will be scheduled from Tidal and it runs every 15 minutes.
- This job picks all the available IDOCS with the below variant and process it.

Program Name: RBDAPP01

Variants: Z_INB_IDOC

- Created On = Current date

- Status = 64
- Message Type = ORDERS
- Sender Partner No = ZSEEBURGER
- Pack Size = 5

IDOC Control records:

- Basic Type: ORDERS05

- Extension: Z_SALES_ORDER_EXT01
- Partner No: ZSEEBURGER

Inbound Function Module for 1st IDOC: ZOM_NGQ_IDOC_INBOUND_ORDERS

- This is the Inbound Function Module assigned in the Partner Profile ZSEEBURGER for Message
type ORDERS and Blank Message Code.
- This FM submits the IDOC 1 data to program Z1_OMIH_ORDER3 to create the second IDOC.
- When it creates the second idoc, it updates the Message code as BOM in the idoc.
- Once the second idoc is created, the status of the IDOC 1 is set to 68. Also the Idoc 2 number is
updated in the status message of IDOC 1.

Inbound Function Module for 2nd IDOC: IDOC_INPUT_ORDERS

- For second IDOC, this is the inbound Standard FM assigned in the Partner Profile ZSEEBURGER
for Message type ORDERS and Message code BOM.
Program: Z1_OMIH_ORDER3

- This program copies the IDOC1 data and generates the IDOC2.
- Before generating the IDOC2, the BOM Nesting happens in this program. As part of BOM
Nesting, the Phantom Materials and the Care pack Materials will be added in the IDOC2.

Phantom Material:

- The Phantom Materials will be maintained in the table ZGMTL001.

- Logic to add the Phantom Material are in the FM ZSA_PHANTOM_BUILD.

- The logic in the FM compares the Class of the above Phantom Materials with the Class of each
materials in the IDOC.
- If matches, it will mark that material as Phantom Material exists and it will add the matched
Phantom material to the IDOC as sub material.
- Also for the above materials, it will pick all the associated BOM components and compare the
class of those BOM components with the Phantom class.
- Add all the BOM components to the IDOC for which the Class is matching with the Phantom
Class.
Care pack Materials:

- The logic checks whether each material is a Configurable material or Services material.
- If Config material, check whether it has Characteristics = ‘SVC_SUPORT_TYPE ’ and value =
‘FLEXIBLE’. If yes, then the care pack materials will be added.

EXIT in IDOC 2 Inbound FM:

- Since the IDOC 2 uses the standard Inbound FM IDOC_INPUT_ORDERS, all the custom
validations are written in the customer exit of the inbound FM.

MCC Material:

- Logic written in below include to add the MCC material if the received material is part of MCC
Bundle.
o Z_MCC_MATERIAL_ADD_INCL
- The MCC materials for each material are maintained in the Condition tables of Condition type
ZL10. So each received materials are passed into these condition tables and checked is there any
MCC material exists for it.
- If found, those MCC materials will be added to the Quote.
- Following are the different condition tables found for the condition type ZL10.

Partner Functions:

CBN/CRS id is replaced with Party id in S4.

- Following are the list of Partner Functions in scope for R2.1.

o Sold To
o Ship To
o Bill To
o Payer
o Reseller
o Entitled Party
 o Asset Location
o End Customer
- For Sold-to and Payer, we will receive the BP-ID or CRS id from the IDOC. If CRS id is received, it
will be converted to the BP-ID using the below API
o ZCA_XREF_CUST_VEN_API

- If not found in the above API, the CRS id will be passed in the below service to get the BP Id from
eMDM
o CALL METHOD lo_ref_mdm->bpid_search

- For Ship-to, Bill-to and Asset Location, the IDOC will have only the name and address. The below
service is used to get the BP-ID from EMDM based on given Name and Address.
o CALL METHOD lo_ref_mdm->location_search

- For end customer and entitle party, the below service is used to get the BP-ID from EMDM.
o CALL METHOD lo_ref_mdm->endcustomer_search

Incoterms and Payment terms:

- Logic to determine the Incoterm and Payment term is added in the below include
o Z_IDOC_PAYMENT_INCOTERM_FILL
- If incoterm is not received in the idoc, Incoterms will be picked from the table
ZOM_D_DEAL_HEAD by passing the deal id.
- If incoterms not found for deal id, get it from the Purchase agreement from tables ZCUSTAGR or
ZPARTNERAGR.
- If not found in PA, get it from the customer master.
- If not found in customer master, set it default Incoterm DDP.
- Same logic for Payment term. Search will in sequence Deal id , PA and then Customer Master .
if not found set it to default NT30.

RTM:

- Logic to determine the RTM is added in the below include

o Z_OM_ORDER_CAPTURE_BRIDGE
- Same logic similar to Incoterm and payment term. First check in the Deal id table if not found
check in the PA tables.
- If not found, pick from the table WCOCOI by passing the PA and Sold to BP id.
- If not found, pick the BR code from the characteristics of BP id and pass that to the table
ZBRTMAP and pick the RTM
- This selected RTM will be updated to the field VBAK-SUBMI.

Validations in IDOC:

- There are multiple validations regarding the PF, PA and Deal id are added in the below Include
o Z_IDOC_PARTNERINFO_VALIDATE_I
 - Following are some of the key validations happen in the customer exit of Idoc2. If any of these
validation fails, idoc will be set to status 51.
o RTM is not assigned to DEAL ID: & as per records
o Deal ID & is not within validity
o Deal ID & doesn't exist in S4 database
o RTM is not assigned to PA:
o BR Type is not assigned to PA:
o Purchase Agreement & is not within validity
o Purchase Agreement & is invalid
o PA and Deal id Missing
o There is an order block for partner & for customer & (Overall block )
 AUFSD(Central order block for customer)
 LIFSD(Central delivery block for the customer)
 FAKSD(Central billing block for customer)

o WebService call failed for WE Reason: &

o No WE segment in Inbound IDOC and hence idoc failed

SFDC Case:

- If any of the above validation fails, a case will be created automatically in SFDC.
- The below method is used to trigger an idoc to SFDC workflow to create a case.
lo_ref_mdm->sfdc_wf_trigger

BDC to update custom fields in QUote

- Custom BDC is written to update the custom fields of the Quote in the below include.
o ZOM_SAI214_ZXVEDU04
- Following are custom fields in the Quote updated using the custom BDC

Header Fields
VBAK-
VBAK-ZZRECV_DAT VBAK-ZZQUOTEN VBAK-ZZXLPRC
ZZSPECIAL_CODE2
VBAK-
VBAK-ZZRECV_DAT VBAK-ZZDEAL_ID VBAK-ZZPO_CAT
ZZSPECIAL_CODE3
VBAK-
VBAK-ZZSYSHNDL VBAK-ZZF_OPP_ID VBAK-ZZPDIM
ZZSPECIAL_CODE4
VBAK- VBAK-
VBAK-ZZACKTODESK VBAK-ZZPAPER_CTRL
ZZINTGR_TIME ZZSPECIAL_CODE5
VBAK- VBAK- VBAK-
VBAK-ZZFAN
ZZSPR_INVOICE ZZSPECIAL_CODE6 ZZSPECIAL_CODE1
VBAK-
VBAK-ZZSAUL VBAK-ZZINV_ROUTR VBAK-ZLOAN
ZZSPECIAL_CODE7
VBAK-
VBAK-ZZPRBOM VBAK-ZZ_WCR VBAK-ZOFFER
ZZSPECIAL_CODE8
VBAK-
VBAK-ZZ_PLGIND VBAK-ZZULT_DEST VBAK-ZDNP
ZZFREIGHTSRLVL
VBAK-ZZINVDSK VBAK-ZZNLTD VBAK-ZZBILL_PRINT VBAK-ZZSEI
VBAK-ZZPUR_AGR VBAK-ZZNETD VBAK-ZZSRCODE VBAK-ZZETR
 VBAK-ZZCARR_ID VBAK-ZZSLA VBAK-ZZSPCL_CODE VBAK-ZZ_DEL_PRTY
VBAK-ZZUSERSTFLAG VBAK-ZZFLID VBAK-ZZPERFDAT VBAK-ZZBILLGRP
      VBAK-ZZECVAT

Item Fields
VBAP-
VBAP-ZZCUSTPO
ZZBUNDLEDESC_OEM
VBAP-
VBAP-ZZMDEAL_ID
ZZCONFIG_ITEM
VBAP-ZZULTDEST VBAP-ZZATP_FLAG
VBAP-ZZRSN_CODE VBAP-ZZSBR
VBAP-ZZITEMCOFO VBAP-ZZLOID
VBAP-ZZLEAD_DT VBAP-ZZINTORD
VBAP-ZZBUNDLEID_OEM VBAP-ZZAWB
  VBAP-ZZHWS

Standard Fields

- The values for the below standard fields are derived using the custom logic in the Exit.

VBAK-ABRVW VBAK-SUBMI
VBKD-PLTYP VBAK-FAKSK
VBAK-BNDDT VBAK-TAXK1
VEDA-VBEGDAT VBAK-LANDTX
VBAK-
VEDA-VENDDAT
STCEG_L
VEDA-VENDDAT  

Reprocess Failed Idocs:

- A Batch job is scheduled to reprocess all the failed Idocs. This job is scheduled every 30 minutes.
- Each job will wait until the previous job is completed.
- Job Name : 020_ZOM_IDOC_51_REPROCESS
Phantom Quote:

- If all the above validations are passed, Phantom Quote ZQT will be created in S4.
- IDOC2 will set to status 53 and the Quote number will be updated in the IDOC status.
- The IDOC2 number will be updated in the Relationships of the Quote.
- If any of the mandatory field is missed in the Quote, it will be updated in the incompletion log. If
the Quote is incomplete, Output type ZHLD will trigger and creates a case in SFDC.
- When the Quote is incomplete, it will not create a Order.

Incompletion Log:

- Incompletion procedure 10 is assigned for the document type ZQT.

- Based on the procedure 10, if the following fields are not filled in the Quote, it will be marked in
the Incompletion log.

- Apart from the above fields, custom logic is written in the below includes to add fields to the
incompletion based on specific conditions.
o Z_INCOMPLETION_LOG
o Z_INCOMPLETION_LOG_SAE1568
o Z_INCOMPLETION_LOG_1218

Text:

- SoldtoCRSID
- PayerCRSID
- Sales Document Type – Mandatory to determine the Order types.
- SP: ESD Identifier – Mandatory if software material exists.
- End user contact email address
- End customer PO number
- Previously Purchased Product Number – Mandatory if the Order has only standalone service
materials.
- Serial Number: Mandatory in Item for care pack materials
Custom fields in Quote:

Following are the custom field in the Quote Header of Additional Data B tab,

- Legacy Quote Number

o It comes from the Source system in IDOC
- Deal Id
o It comes from the Source system in IDOC. But it will be validated against the custom
table of Deal id (Mandatory for direct orders, if it is a Non-stocking order)
- Purchase Agreement
o It comes from Source system in IDOC. It will be validated against the two custom tables
of PA. (Mandatory for all Indirect Order, PA is mandatory)
- SFDC Opportunity ID
o It comes from the source system in IDOC. Usually starts with OPE
- System Handle Number
o This is the OIS number comes from Seeburger. Can be used as the identifier to raise any
issues to Seeburger.
- Ship Auth Letter
o Used in Rental and Leasing Order. Specific to HPE Financial Services. This field is
mandatory when the Custom Group is HPEFS. Used limitedly in R2.1.
- PO Category
o STGE, STCK or DROP
o This value will be received from the source system in IDOC. Based on this value the
Order type will be determined.
- Consolidate Invoice
o Check box (used to consolidate the invoices of a order, will be covered in detail during
Billing session)

- Item level Custom fields

o Deal id – will be same as in the Header
o PA – For R2.1 all line item will have the same PA
o Config Line item – if this field is blank, Config check will not work. If this field is missed,
SO will get under WCFG hold.

Other Key fields in Quote:

- Additional Data A -> Customer Group 1(BRT Value)

- Order Data -> Customer Reference, Customer Ref Date, PO Type and RTM

Plants

- In S4, we have V and Z plants. V plants are virtual plants(Sales office Plants). For Products we
have V plants and for services we have Z plants.
 - Plant determination in Quote has no dependency on the Purchase category(Source system). It
comes from the standard material master.
- Once the SO is processed, then there is a logic of ASD (Automatic Source Determination) which
pops in and takes care of the Fulfillment.

Order Creation:

- Upon save of each Complete Quote, a new job will be submitted and it creates Order with
reference to the Quote. This happens by the code in Quote Save Userexit.
- The Job name will be as below,
o Job Name : ZSO_CREATE_QTENO_DATE_1
o User Exit : MV45AFZZ Include : Z_SO_CREATE_WITH_QUOTE
o Submit Program name : Z_CREATE_SO_WITH_QUOTE_E
- The job will generate only if it satisfies the below condition
o Quote is complete
o There is no other active order for this Quote
- If the original Order is rejected, then the Quote can be saved manually to trigger the Job again.
- As part of R2.2, a job will be set up frequently to process all the open complete Quote.

Copy Custom fields from Quote to Order

- Logic added in the below include to copy the required custom fields from Quote to Order
o User exit : MV45AFZZ
o Include : Z_COPY_CUSTOM_QUOTE_REF

Order Notification Output types:

Order email Notification

- Once the order saved, a email will trigger to Customer Purchasing Agent. This email id will be
maintained in Customer Purchase Agent email Text of every order received from NGQC. This will
be at Header level.
- In case, if the email id is not there, it checks the Sold to email id and picks that. If no email id
there, the email will not trigger.
 - The BCC and CC recipients for this mail will be maintained in a custom table. These entries are
based on Document types in the below table.
o ZSD_ORDPACK_MAIL (Maintained by SM30)
- If the email id not exists in the Text, we can able to maintain the email id in the text manually
and can trigger repeat output.
- To maintain multiple mail id in the Text, it must separate by the Semi colon.

Change and Cancel:

- Changing or Cancelling a order is allowed only based on the status of the orders.
- Throughout the order to cash cycle, the order status will be getting changed and based on the
statuses, the fields in sales order are enabled for editing.
- Based on the order status, the code in the enhancement decides if the sales order is allowed for
cancellation or not.  
- In exception cases, Order status can be updated to OVRI and we can make the necessary
changes.
- If Sales order has multiple statuses at line item level, the most progressive status is considered
for Change/cancel determination on sales order. 
- The change and cancel matrix is maintained in the below table
o ZOM_CHANGE_CANCL
- The above functionality is handled by the below enhancement,
o User exit: MV45AFZZ
o Include: Z_CHANGE_CANCEL_PROCESS_I
o FM: Z_OM_CHANGE_CANCEL, Z_OM_GET_CHANGE_CANCEL_MATRIX