www.KNAPP.

com

Development Order
C903A

7007

RF Loading Workflow

Customer: ESTÉE LAUDER Companies

Project: C903A ELC

Consultant: Spela Vodusek

Developer: Florian Rüschitz

Time recording: 0171-7007: Loading

BBP Version: 20190618_ELC_BBP_Outbound_shipping_V2.0

BBP Chapter.: 8 Loading

FRICE-ID 6346

KNAPP IT Solutions GmbH • Parkring 1 • 8074 Grambach bei Graz • Austria • +43 50 495 - 9100
Uni Credit Bank Austria AG • BIC: BKAUATWW • IBAN: AT611200052959159109 • FN: 383109 x • UID: ATU67349648 • DVR number: 4017059
 www.KNAPP.com

Change log

Version Date Author Remarks

0.1 01.10.2019 VOD Initial version

1.0 08.10.2019 VOD 2nd version

2.0 17.04.2020 WIN Added CR – PPF action

11/06/2023 753423138.docx 2/19

 www.KNAPP.com

Content
1 Introduction 4
2 US 1: Start Loading 4
2.1 Acceptance criteria 4
2.2 Execution flows 4
2.3 Mockups / Use Cases / Processes 4
2.4 Additional information 5
3 US 2: Scan door 7
3.1 Acceptance criteria 7
3.2 Execution flows 7
3.3 Mockups / Use Cases / Processes 7
3.4 Additional information 8
4 US 3: Scan HU 8
4.1 Acceptance criteria 8
4.2 Execution flows 9
4.3 Mockups / Use Cases / Processes 9
4.4 Additional information 10
5 US 4: Scan HU to door 11
5.1 Acceptance criteria 11
5.2 Execution flows 11
5.3 Mockups / Use Cases / Processes 12
5.4 Additional information 12
6 US 5: Finish - seal 12
6.1 Acceptance criteria 12
6.2 Execution flows 13
6.3 Mockups / Use Cases / Processes 13
6.4 Additional information 13
7 Customizing 13
8 Architecture 14
9 Technical implementation 14
9.1 Entry point 14
9.2 Packages 14
9.3 Implemented BAdI’s 15
9.4 Important classes / function modules 15
9.5 Database tables 15
9.6 Checkpoint groups 15
9.7 Others 15

11/06/2023 753423138.docx 3/19

 www.KNAPP.com

1 Introduction
The loading of the truck cannot be done using the standard RF transaction as the pallets are already
posted GI and only re-created as empty HUs. Therefor a custom RF transaction must be developed.
When the user scans the door, the system looks for the corresponding vehicle and TUs (in the z-table
described below). When loading, the user confirms the loading of each pallet with scanning the door.
Multiple TUs can be assigned to a vehicle and therefore the system has to recognize this and inform
the user in case there are still TUs/pallets to be loaded. After loading all pallets to the vehicle, the
user enters the seal number and the standard status of the TUs is set to “Loading completed”. At this
point also the print of an unloading list is triggered.

2 US 1: Start Loading
In this screen the user must choose Outbound Processes, then Loading and Loading by door in the
RF main menu to start loading with the help of SAP EWM RF.

2.1 Acceptance criteria

a. The system provides the submenus of the RF (please see chapter 3 for more details).
b. The system forwards the user to the “Scan door”-screen to start with the Loading process.

2.2 Execution flows

1. The user enters the RF transaction.

2. The user selects the submenus “04 Outbound processes”  “03 Loading”  “01 Loading by
door”.
3. The system forwards the user to the “Scan door”-screen.

2.3 Mockups / Use Cases / Processes

11/06/2023 753423138.docx 4/19

 www.KNAPP.com

2.4 Additional information

Process flow of loading.

11/06/2023 753423138.docx 5/19

 www.KNAPP.com

Loading allowed scenarios:

11/06/2023 753423138.docx 6/19

 www.KNAPP.com

TU# Loading_allowed SHPBLKD

1 X initial
2 X blocked
3 initial
4 blocked

TU-Kombo Warning Error

1 no no
2 no yes
3 no yes
4 no yes
1+1 no no
1+2 yes no
1+3 yes no
1+4 yes no
2+2 no yes
2+3 no yes
2+4 no yes
3+3 no yes
3+4 no yes
4+4 no yes

3 US 2: Scan door
The user must scan the door to start the loading process. The system will check if a vehicle is docked
to the door.

The system will check if the status of the TUs, which are related to the vehicle docked at the door,
have the following statuses:
 Not “Blocked”
 Loading allowed (customs released)

If this is not the case, loading is not allowed.

The system sets the status of the corresponding TUs to “Loading started”.

3.1 Acceptance criteria

a. The system displays an active field for “Door”.
b. The system checks after door scan the assignment of the vehicle to the door (z-table, error
case – see chapter 3.3).
c. The system finds the corresponding TUs assigned to a vehicle (standard connection).
d. The status of at least one TU related to the vehicle docked to the door must be:
i. not “Blocked”
ii. “Loading allowed” (customs released, z-field ZZ_LOADING_ALLOWED).
If this is not the case, loading is not allowed.
e. If at least one TU is not allowed for loading (d) -a) and b)), the system shows a warning mes -
sage.
f. The standard status of the corresponding TUs is set to “Loading started”.

11/06/2023 753423138.docx 7/19

 www.KNAPP.com

g. The system forwards the user to the “Scan HU” screen.

3.2 Execution flows

1. The user scans the door.
2. The status of the TU is:
a. Option 1: “Blocked” and “Loading allowed”  LOADING IS NOT ALLOWED – error
case
b. Option 2: not “Blocked” and “Loading allowed”  LOADING ALLOWED – process
continues
3. The standard status of the corresponding TUs is set to “Loading started”.

3.3 Mockups / Use Cases / Processes

Error case

3.4 Additional information

Status blocked is related to the following field ZZ_SHBLK_TU on TU header.

4 US 3: Scan HU
The user gets the number of loaded pallets and the total number, as well as the source bin and even-
tually the supposed HU number displayed. He has to scan the pallet HU number (SSCC code). De-

11/06/2023 753423138.docx 8/19

 www.KNAPP.com

pending on the source bin there are different options (screens) provided to the user. If the source
storage type is dispatch lane, then the system does not show the next HU (screen 1, chapter 4.2). If
the source storage type is staging area (oversized area), then option 2 (screen 2) where the next HU
is shown, applies. The system will not force the user to stick to any sequence for loading. The pallets
will be provided to the dispatch lanes in a certain sequence during retrieval, but the user can decide
which one he loads first.

4.1 Acceptance criteria

a. The system only shows an SSCC proposal for HUs from loading allowed TUs at the staging
area.
b. The system checks which bins (lanes/staging area) have assigned HUs for this vehicle and
displays them on the screen. The system considers staging areas before dispatch lanes.
Based on the source storage bin there are different options (screens) provided to the user.
i. Option 1: If the source storage bin is Dispatch lane, the system does NOT display the
next HU.
ii. Option 2: If the source storage bin is Staging area, the system displays the Next HU.
c. The system shows a warning message if no bin proposal was found but loading is not yet
completed.
d. The system will not force the user to stick to any sequence for loading.
e. The information of Door, Loaded pallets (current number of loaded pallets and the total num-
ber of pallets to be loaded e.g. 2 of 10) and the Source Bin are displayed on the screen as
inactive fields (see chapter 4.3).
f. An active field for HU is provided.
g. An inactive field for Next HU is provided.
h. The system checks for the Next HU number and writes it in the field Next HU.
i. The system checks if the scanned HU exists in the system and if it´s related to one of the TUs
of the docked vehicle. If this is not the case an error message is shown.
j. The system creates an open WT (for internal movement) with the destination bin at the door
and books the HU to the resource. When the HU is booked to the resource, the resource is
displayed in the Source bin field.
k. The system forwards the user to the “Scan HU to door” screen.

4.2 Execution flows

1. The system displays the Door, Loaded pallets, Source bin on the RF screen and depending
on the source storage bin also the Next HU.
a. Option 1: If the source storage bin is Lane, Next HU is NOT shown (chapter 4.3,
Screen for option 1)
b. Option 2: If the source storage bin is Staging area, Next HU is shown (chapter 4.3,
screen for option 2)
2. The user scans the HU.
a. Option 1: HU exists in the system and is related to one of the TUs of the docked vehi-
cle.  Process continues.
b. Option 2: HU doesn´t exist in the system or is not related to one of the TUs of the
docked vehicle.  Error case (please see chapter 4.3, Error case screen)
3. The system creates an open WT with the destination bin at the door and books the HU to the
resource.

11/06/2023 753423138.docx 9/19

 www.KNAPP.com

4.3 Mockups / Use Cases / Processes

Screen for option 1, where the source bin is Lane.

Screen for option 2, where the source bin is staging area (oversized area).

Error case

11/06/2023 753423138.docx 10/19

 www.KNAPP.com

4.4 Additional information

The z-table “ZTLGT_O_PAL” is needed to save all pallet-related outbound process information, which
can occur or be changed within the whole process. More information on the table “ZTLGT_O_PAL”
are part of the DO Interface between EWM and KiSoft Packmaster.

The z-table “ZTLGT_O_PAL” needs to be extended with the column “Loaded”.

The table will look like this e.g.:
WH SSCC Reference Cate- Sta- Assign. KiSoft PM cal- Loading
no. number gory tus WC culation time status
CHG 45678965 1 1
1 4
CHG 12345678 02 3 20190424143711 2
1 8
CHG 95123541 05 4 MPS1 20190423131107 3
1 1

The following table explains the different columns of this z-table:

Field Description Value Data type /
length
Loaded status Status to identify where the pallet 1 - Requested
is 2 - HBW delivered
3 - HBW provided
4 - Loaded

5 US 4: Scan HU to door
To ensure that the user puts the HU to the right vehicle he has to scan the dock door once more. The
system checks if the HU is connected to one of the TUs from the vehicle. The system sets the value
in the column “Loading status” to “4” for the respective HU in a z-table “ZTLGT_O_PAL”. The empty
HUs will be deleted directly by the system.
If this step was successful, he will continue with loading in step 4 (US 3) until all the pallets are
loaded. If there are more TUs assigned to a vehicle, the user has to continue until all pallets from the
corresponding TUs are loaded (loop). The counter of loaded pallets increases.

5.1 Acceptance criteria

a. An active field for “Door” is provided.
b. The system backwards the user to the Scan HU screen.
c. The HU remains assigned to the resource until it is confirmed to the door.
d. A check if the loaded HU is on the right vehicle needs to be done (standard connection TU-
Vehicle and the z-table "ZTLGT_O_PAL" for the PAL-TU connection).
e. The Loaded status of the HU is set to “Loaded” (“4”, in table ZLGTL_O_PAL).
f. The number of loaded pallets is increased with every pallet successfully put on the vehicle.
g. The system confirms the WT.
h. Empty HU is deleted.
i. A check if all the HUs were loaded needs to be done(“4” (=loaded) in column “Loaded” in
table “ZTLGT_O_PAL”). If not all pallets from the TUs are loaded, the system returns to the
“Scan HU” screen in and the process repeats until all pallets from the TUs corresponding to a
vehicle are loaded.
j. The system forwards the user to the next “Finish -seal” screen.

11/06/2023 753423138.docx 11/19

 www.KNAPP.com

5.2 Execution flows

Option 1:
1. The system provides an active field for “Door”.
2. The user scans the dock door.
a. Option 1: Correct HU is scanned to the vehicle.  Process continues.
b. Option 2: Wrong HU is scanned to the vehicle.  Error case (see chapter 5.3, Error
case)
3. The system confirms the WT for internal movement.
4. After the pallet was successfully loaded there are 2 options:
a. Option 1: Not all pallets are loaded  The system returns the user to the “Scan HU”
screen.
b. Option 2: All pallets are loaded  The system forwards the user to the “Finish seal”
screen.

Option 2 – F7:
1. The system provides an active field for “Door”.
2. The user presses “F7 – Back”.
3. The system backwards the user to the Scan HU screen.
4. The HU remains assigned to the resource until it is confirmed to the door.

5.3 Mockups / Use Cases / Processes

Error cases

11/06/2023 753423138.docx 12/19

 www.KNAPP.com

5.4 Additional information

Error messages for the possible errors during the process.

1. HU 173498630964 not valid. / HU 173498630964 does not exist.

2. HU 173498630964 not belonging to a TU for the vehicle assigned to the door.
3. HU 173498630964 already loaded.

6 US 5: Finish - seal
After loading all the pallets on the vehicle, the user must enter the seal number which will be saved
on the vehicle. The standard status of the TU will be set to “Loading completed” and a print of the
unloading list will be triggered.

6.1 Acceptance criteria

a) One inactive, pre-filled field “Door” and one active field “Seal” are provided.
b) The seal number is saved in a standard field on the vehicle.
c) The standard status of the TU is set to “Loading completed”.
d) CR: The vehicle will be undocked from the door. (Delete “X” in z-field ZZ_DOCKED_DOOR on
vehicle header, save leads to an update in table ZTLGT_DOOR_VEH)
e) The standard status of the vehicle will be set to “Loading completed”.
f) CR: The system triggers the printing of the unloading list by writing an entry into the spool.
g) The printing will always be triggered at the printer assigned to the document type at the manual
pallet finishing station based on the printing control table assignment (ZLC_PRINT_WC)
h) A pop-up will be shown to the user in case the button F7 / Back was pressed, which shows the
message: “Seal has to be confirmed to complete the loading process! Do you want to abort?"

6.2 Execution flows

Option 1:
1. The system displays information of “Door” and empty field for “Seal”.
2. The user enters the seal number in the corresponding field and clicks on OK.
3. The seal number is saved.
4. The system sets the status of the vehicle to “Loading completed” and undocks the vehicle
from the door.

11/06/2023 753423138.docx 13/19

 www.KNAPP.com

5. CR: The system triggers the printing of the unloading list by writing an entry into the spool.
6. The system triggers the print at a printer assigned to the MPF1 station for the doc type load-
ing list
7. The system returns to the first screen of the RF.

Option 2:
1. The system displays information of “Door” and empty field for “Seal”.
2. The user presses the button F7 / Back
3. The system shows a pop-up to the user with the warning message: Seal has to be confirmed
to complete the loading process! Do you want to abort?"
a. The user presses “YES” and will be returned to the main screen. In order to continue
the process, the door need to be scanned again, afterwards the user will be able to
finish the process with the F1 button.
b. The user presses “NO” and will be returned to the seal screen to finish the process.

6.3 Mockups / Use Cases / Processes

6.4 Additional information

No additional information needed.

7 US 6: Loading to Airport hangar

When pallets should be loaded to the airport hangar a loading and unloading list must be printed. The
pallets are loaded onto a truck based on the airport hangar transfer bin the pallets are stored after
taking off the dispatch lane. Due to this the VEH cannot be used as indication what goes onto the
same truck, therefore a new GUI transaction had to be built which uses the airport hangar transfer bin
and physical truck as loading criteria as basis for the loading and unloading list. For this process pal-
lets are either already PGIed or not, both will be considered for printing.

Most of the data need to be entered manually by the user in the transaction, please see the detailed
information below.

11/06/2023 753423138.docx 14/19

 www.KNAPP.com

7.1 Acceptance criteria

a) A new GUI transaction will be provided in order to enter all the required data for the print of
the loading and unloading list from the airport hanger transfer bin
 Warehouse number (active, mandatory)
 Storage bin (active, mandatory)
 Internal VEH no. (active mandatory)
 Internal TU no. (active mandatory)
 Seal Number (active mandatory)
 License plate Number (active mandatory)
 Haulier (carrier) (active mandatory)
 Container Number (active mandatory)
 Driver name (active mandatory)
 Phone number (active not mandatory)
 Remarks 1 (active not mandatory)
b) The system fills the value for SCC (shipping condition) on the lists based on the ODO header,
z-field ZZ_COCD
c) The system fills the value for the loading date / time on the lists based on the current date &
time
d) The system triggers the print of the loading and unloading list after the transaction was exe-
cuted and all mandatory values were filled in
e) The system shows an error message in case not all mandatory fields were filled correctly.

7.2 Execution flows

Option 1:
1) The user enters all the values in the required fields and executed the transacation with F8
2) The system triggers the print of the Loading and Unloading list

Option 2:
1) The user enters not all mandatory values and executes the transcation with F8
2) The system shows an error message to the user that not all mandatory fields are filled

11/06/2023 753423138.docx 15/19

 www.KNAPP.com

7.3 Mockups / Use Cases / Processes

11/06/2023 753423138.docx 16/19

 www.KNAPP.com

7.4 Additional information

For this process the pallets are either already PGIed or not PGIed, this means loading to the airport
hangar transfer bins and printing can happen also with pallets which are not yet PGIed, the PGI hap-
pens on the way to the airport hangar. Reason: in this process it is the goal to push as much pallets
as possible to the airport, also while palletizing might be run for other pallets belonging to the same
TU. As soon as a trailer is full it will be transported to the airport hangar independent from the PGI
status.

8 Customizing
The following sections for Dispatch lanes (storage type 0170) will be created:

1. 0001 Dispatch lane 1

2. 0002 Dispatch lane 2
3. 0003 Dispatch lane 3
4. 0004 Dispatch lane 4
5. 0005 Dispatch lane 5
6. 0006 Dispatch lane 6
7. 0007 Dispatch lane 7
8. 0008 Dispatch lane 8
9. 0009 Dispatch lane Error

The following bins for Dispatch lanes will be created:

1. Dispatch lane 1
2. Dispatch lane 2
3. Dispatch lane 3
4. Dispatch lane 4
5. Dispatch lane 5
6. Dispatch lane 6
7. Dispatch lane 7
8. Dispatch lane 8
9. Dispatch lane Error

11/06/2023 753423138.docx 17/19

 www.KNAPP.com

9 Architecture
Implementation will hold helper classes and methods of either existing implementations or newly cre-
ated parts.
These will handle reading of standard objects like vehicles, TU, assignments of door and vehicles.
TU status change will be adapted to fit inbound as well as outbound directions.
ZTLGT_O_PAL will be extended with flag indicating loading complete for specific HU. Associated
service class will have flag set method for easy use.
Regular HU handling for RF will be set up. HU will be booked to resource and confirmed onto storage
bin of door after door scan.
General logging will be implemented. Checkpoint groups will be set up.

10 Technical implementation

10.1 Entry point

RF Menu -> Outbound processes -> Loading

10.2 Packages
ZL6346_RF_LOADING
FRICE package for workflow, screens, PAI & PBO
ZL6300_BASIS
holding general service classes and helper methods

10.3 Implemented BAdI’s

none

10.4 Important classes / function modules

ZLGT6346CL_RF_LOADING
RF workflow handling class

Z_LGT6346_LOAD_S1_PBO
Z_LGT6346_LOAD_S1_PAI
Function modules for screen 1: scan door
Z_LGT6346_LOAD_S2_PBO
Z_LGT6346_LOAD_S2_PAI
Function modules for screen 2: scan HU
Z_LGT6346_LOAD_S3_PBO
Z_LGT6346_LOAD_S3_PAI
Function modules for screen 3: scan HU to door
Z_LGT6346_LOAD_S4_PBO
Z_LGT6346_LOAD_S4_PAI
Function modules for screen 4: finish, scan seal

10.5 Database tables

ZTLGT_O_PAL
Extended

11/06/2023 753423138.docx 18/19

 www.KNAPP.com

10.6 Checkpoint groups

ZLGT6300CP_RF
general check point group for RF
ZLGT6346CP_RF_LOADING
specific check point group for RF loading

10.7 Others
Sub-Log: ZELC_RF_LOADING

11/06/2023 753423138.docx 19/19