1. SABIC IT PMO ZFDS - Development Specification
STEP
SABIC Transformation through Execution of Projects
STEP 3 - Execute Program or Project
Development Specification
Template Version 1.0
Rebrand of Netback Batch TO Manufacture Batch inside
Bonded WH when MFB comes from multiple affiliates
[EP_LE_EXXXX]
Process: Warehouse Sales order
processing Reseller
[FANAR +]

2. SABIC IT PMO ZFDS - Development Specification
[Project ID]
[Project Manager]
[SBU Name]

3. Table of Contents
1 Business Requirement.............................................................................................5
2 Development Specification.....................................................................................9

4. [SBU Name] ZFDS - Development Specification
[FANAR+] [1.0] | [15.10.2014]
Version History
Version Author Date Description
1.0 Ronen Madar 12-March-2015 Initial
SAP Competence Centre 4 of 15

5. [SBU Name] ZFDS - Development Specification
[FANAR+] [1.0] | [15.10.2014]
1 Business Requirement
The business requirement for this change is as follow:
• All stock in bonded warehouse need to be managed by MFB.
• WH clerks need to have a full visibility of manufacturing batches.
• Information from Fanar system (affiliate) with container information (a.o.
production batch, volume, seal no, batch ID)
• Follow-up operational processes after GR require the production batch to be
transparent/clear at all times;
Stock overviews
Goods movements
Documentation
Be able to change the MFB when the MFB already exist in the WH
1.1 Functional description
As part of the replenishment process to the bonded warehouse we need to convert
the NBB we have received from SABIC HQ to a MFB as part of the inbound process.
SABIC has a scenario where the MFB received already exist in the bonded
warehouse as part of a different GR from different affiliate. In such a case we will
need to change the MFB and add a prefix to it to avoid valuation type issues since
we have no capacity to manage one batch with different valuation types.
In order to facilitate the business requirements for this process we will change the
batch number before posting GR to the bonded warehouse and then convert the
NBB to the new MFB.
SAP Competence Centre 5 of 15

6. [SBU Name] ZFDS - Development Specification
[FANAR+] [1.0] | [15.10.2014]
1.2 Scope
Before posting GR the program will check if the MFB entered exist in stock and if not
a material document will be created with movement type 101 the conversion
program will be called to convert the NBB to the new MFB and copy all
characteristics from the NBB to the new MFB.
SAP Competence Centre 6 of 15

7. [SBU Name] ZFDS - Development Specification
[FANAR+] [1.0] | [15.10.2014]
1.3 Reason for development
To support the business requirements to have only one valuation type per MFB.
1.3.1 Description of alternative
To avoid having to receive the same MFB from more than one affiliate.
1.3.2 Reason why alternative is not acceptable
SABIC cannot promise that more than will affiliate will not produce a MFB with the
same number.
1.4 Authorisation
N/A
1.5 Risk analysis
None
1.6 Test cases
Step # Description Expected results Actual results
1 Create an Inbound delivery
for STO into the Bonded WH
with MFB which exist already
in the BWH and post GR.
The program will check if
the batch exists already
and if so the user will see
an error message asking
to change the batch
number to another MFB.
A material document will
be created with IM
movement type 101 and
additional material
document will be
generated with IM MVT
309. As soon as material
document 309 will be
generated a posting
change and transfer order
in WM will be created and
confirmed.
SAP Competence Centre 7 of 15

8. [SBU Name] ZFDS - Development Specification
[FANAR+] [1.0] | [15.10.2014]
1.7 Program Type
Choose the correct program type:
Enhancement
BADI
Customer Program
User Exit
Data model
Report
UI
Other
SAP Competence Centre 8 of 15

9. [SBU Name] ZFDS - Development Specification
[FANAR+] [1.0] | [15.10.2014]
2 Development Specification
2.1 Configuration and other pre-conditions
Create new output type for inbound delivery ZBGR to be linked to FM
MB_CREATE_GOODS_MOVEMENT
Configuration of WM MVT 309 to IM 309 link will be required as well as creation of
posting change for WM MVT 309.
Automatic TO confirmation for MVT 309 needs to be configured.
In order to be able to execute the conversion program we will need to have the stock
received in the WH and posted in IM.
The vendor batch field (MFB’s) will contain the MFB and the batch field (NBB)
should contain the NBB from the outbound delivery and be mandatory.
Change batch number range configuration to facilitate the new batch number
creation with the prefix.
Allow creation of new batch at time of GR to the plant.
2.2 Menu path
N/A
2.3 Processing logic
1. An inbound delivery with the NBB and the MFB will be generated by the
SASP interface for the full quantity.
2. A warehouse clerk will verify that the stock they received is what has been
declared and will post GR for inbound delivery with actual quantity where a
material document will be created.
As soon as we click on the post GR for the inbound delivery we check if the MFB
entered exist in the warehouse already. If so an error message will be displayed
saying that the batch number needs be changed.
3. As soon as we update the batch number we click on the post GR again to
post material into the bonded warehouse using IM MVT 101 and check if a
material document movement type 101 has been created for the outbound
delivery.
4. If a material document has been created with IM MVT 101 we call FM
MB_CREATE_GOODS_MOVEMENT to process the conversion program. The
SAP Competence Centre 9 of 15

10. [SBU Name] ZFDS - Development Specification
[FANAR+] [1.0] | [15.10.2014]
source materials and batched for this program will be from the inbound
delivery NBB in LIPS table and the destination material and batches will be
taken from the LIPS table which contain the MFB’s entered at the time of GR
for the inbound delivery.
5. As soon as conversion material document will be created for IM MVT 311 we
will generate a posting change in WM as well as transfer order and transfer
order confirmation the MFB’s in the warehouse.
6. We will also copy the NBB characteristics to the MFB classification.
Differences will be posted on the same inbound delivery with the storage
location 1080.
2.4 Enhancements
2.5 BADI’s
2.6 User exits
2.7 Customer programs
1. An inbound delivery for the NBB will be generated by the SASP cockpit.
Remember the NBB entered.
As part of the SASP cockpit functionality we will click on the CREATE
INBOUND button which will generate an inbound for STO from the mirror
plant to the Bonded warehouse.
As soon as the stock will physically arrive we will update the inbound with the
NBB and actual quantity on the inbound delivery as well as update the MFB
on the vendor batch section for the actual quantity. (Remember the inbound
delivery number, material number, batch and quantity in a memory
table).
Take the plant LIPS–WERKS for the inbound delivery you process in
LIPS-VBELN
SAP Competence Centre 10 of 15

11. [SBU Name] ZFDS - Development Specification
[FANAR+] [1.0] | [15.10.2014]
2. A warehouse clerk will verify that the stock they received is what has been
declared and will post GR for inbound delivery with actual quantity where a
material document will be created.
As soon as we click on the post GR for the inbound delivery we check if the MFB
entered exist in the warehouse already. If so an error message will be displayed
saying that the batch number needs be changed.
Question: do we change it manually or automatically.
2.1. Process inbound delivery for container.
Inbound delivery created.
SAP Competence Centre 11 of 15

12. [SBU Name] ZFDS - Development Specification
[FANAR+] [1.0] | [15.10.2014]
NBB and MFB Batch have been populated automatically in the inbound delivery.
Click on Post GR button. This can be done via the cockpit or the delivery itself.
SAP Competence Centre 12 of 15

13. [SBU Name] ZFDS - Development Specification
[FANAR+] [1.0] | [15.10.2014]
If the MFB entered does not exist in the warehouse the material document will be
posted.
If the MFB exist in the warehouse an error message will be displayed asking to
change the MFB number on the vendor batch field.
POPUP_GET_VALUES
3. As soon as we click on the post GR for the inbound delivery and before we
create the material document we first have to check the warehouse plant for
the inbound delivery in order to see if a conversion program is required or
not.
When LIPS-WERKS= ZMFB_NBB-WERKS Check if ZMFB_NBB-VALUE=1
We will also check if the GR storage location from LIPS is not equal to 1080.
If so we need to convert the stock to the original MFB. Otherwise do not
convert the NBB to the MFB.
Table ZMFB_NBB
Plant= ZMFB_NBB-WERKS
(CHAR 4 DIGITS)
Activity= ZMFB_NBB-VALUE (1 DIGIT)
1054 (Polymers) 1
1053(Liquid chemicals) 2
4. Then we check if a material document has been created for the inbound
delivery in table MKPF where MKPF-LE_VBELN=LIPS-VBELN for the
inbound delivery created in step 1.
5. If a material document has been created we call function module
MB_CREATE_GOODS_MOVEMENT to generate the NBB to MFB
conversion program.
Source information for the FM:
The source plant, storage location, materials and batched for this program will
be taken from the inbound delivery from table LIPS where LIPS-VBELN= the
SAP Competence Centre 13 of 15

14. [SBU Name] ZFDS - Development Specification
[FANAR+] [1.0] | [15.10.2014]
inbound delivery processed from step 1 and the IM MVT we will use will be
309.
LIPS-WERKS=the source plant we enter to the FM source plant.
LIPS-LGORT=the source storage location we enter to the FM source SL.
LIPS-MATNR=the source material we enter to the FM source material field.
LIPS-CHARG=the source is the NBB we enter to the FM source batch field
from the inbound.
Destination information for the FM:
Destination plant=the source plant from the inbound delivery process.
Destination SL=the source SL from the inbound process.
Destination material=the source material for the inbound delivery.
Destination batch will be the MFB we have entered in the inbound delivery
vendor batch field for each one of the NBB received.
If there is more than one line item on the inbound delivery or we have a batch split
on the inbound delivery remember the MFB entered on the vendor batch field for
each item.
6. As soon as conversion material document will be created for IM MVT 309 we
will generate a posting change in WM as well as transfer order and transfer
order confirmation.
Below development was done to meet the requirements mentioned in this Functional
Specs:
Implicit enhancements are implemented as below:
1. For T-code VL32N – ZEHI_LICHN_CHECK
2. For T-code ZLE_CUST_COCKPIT_IN – ZEHI_LICHN_CHECK_VL06IG
Logic written –
1. During PGR of IBD, check if the Vendor Batch in IBD already exists in table MCHA
for Material and Plant combination, if yes then change the 1st
character of Vendor
Batch to ‘A’. Check if the new determined batch with prefix ‘A’ already exists in
MCHA for Material and Plant combination, if yes then change the 1st
character of
Vendor Batch to ‘B’. Continue to change the Vendor Batch unless and until a unique
Vendor Batch is determined that do not exists in table MCHA for Material and Plant.
2. Once new Vendor Batch is determined, create this batch in system using FM –
VB_BATCH_CREATE.
3. Read the Batch Classification details of NBB Batch (CHARG) of IBD using FM -
CLAF_CLASSIFICATION_OF_OBJECTS
SAP Competence Centre 14 of 15

15. [SBU Name] ZFDS - Development Specification
[FANAR+] [1.0] | [15.10.2014]
4. Copy this classification to newly created Vendor Batch by replacing Manufacturing
Affiliate Batch with the Old Vendor Batch number using FM -
BAPI_OBJCL_CHANGE.
5. Once the above steps are performed allow to do PGR.
6. Vendor Batch checking and replacing logic must be executed only when the
Valuation type of that Vendor Batch and Valuation type of IBD’s corresponding line
item is different.
2.8 User Interface (UI)
N/A
2.8.1 Screens
N/A
2.8.2 Form
N/A
2.8.3 Report
N/A
2.8.4 Webdynpro for ABAP / JAVA
N/A
2.9 Interface
2.9.1 SAP PI
N/A
2.10Data model
N/A
2.11Jobs
N/A
2.12Portal Content
N/A
2.13Workflow
N/A
2.14Result of Test case
Pl. capture the results of the test cases defined in 1.6 above.
SAP Competence Centre 15 of 15