www.KNAPP.

com

Development Order
C903A

3011

Interface between EWM and KiSoft Packmaster

Customer: ESTÉE LAUDER Companies

Project: C903A ELC

Consultant: Martina Gruber

Time recording: Realisierung – 0043-Interface between EWM and Packmaster

BBP Version: V1.3_Outbound_planning

BBP Chapter.: 5 Integration KiSoft Packmaster

FRICE-ID:

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 dd.mm.JJJJ XXX Initial version

03/04/2023 753422992.docx 2/18

 www.KNAPP.com

Content
1 Introduction 4
2 US 1: Interface SAP EWM <--> KiSoft Packmaster 4
2.1 Acceptance criteria 4
2.2 Execution flows 4
2.3 Mockups / Use Cases / Processes 4
2.4 Additional information 4
3 US 2: Providing data for KiSoft Packmaster 4
3.1 Acceptance criteria 5
3.2 Execution flows 5
3.3 Mockups / Use Cases / Processes 6
3.4 Additional information 6
3.4.1 ArticleGroup 6
3.4.2 Determination of ArticleGroup Content 7
4 US 3: Receive calculation result from KiSoft Packmaster 8
4.1 Acceptance criteria 8
4.2 Execution flows 9
4.3 Mockups / Use Cases / Processes 10
4.4 Additional information 10
5 US 4: Calculation of palletizing starting date and time (PST) 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: Calculation of physical palletizing start date and time (PPS) 15
6.1 Acceptance criteria 15
6.2 Execution flows 15
6.3 Mockups / Use Cases / Processes 16
6.4 Additional information 16
7 US 6: Calculation of physical palletizing end date and time (PPE) 16
7.1 Acceptance criteria 16
7.2 Execution flows 16
7.3 Mockups / Use Cases / Processes 17
7.4 Additional information 17
8 Architecture 17
9 Technical implementation 17
9.1 Entry point 17
9.2 Packages 17
9.3 Implemented BAdI’s 17
9.4 Important classes / function modules 18
9.5 Database tables 18
9.6 Checkpoint groups 18
9.7 Others 18

03/04/2023 753422992.docx 3/18

 www.KNAPP.com

1 Introduction
The KiSoft Packmaster calculates how many pallets are required for palletizing according to the pack-
ing pattern based on the result of the cartonization and the given restrictions. This calculation will be
triggered automatically in background as soon as a specific moment in time is reached. The triggering
is based on a background job, which will run regularly. The result of the calculation is a whole struc-
ture about how to pack the cartons on the pallets, which are assigned to a specific TU.

2 US 1: Interface SAP EWM <--> KiSoft Packmaster

The interface between SAP EWM and the KiSoft Packmaster is based on a TCP/IP XML connection.

2.1 Acceptance criteria

 For creating a request to Packmaster and saving the request to the outbound queue, the
entry point /knapp/if_pm_telegram_facade~get_pack_image needs to be used.
 For working off the outbound queue to the Packmaster server, the entry point /knapp/
if_pm_telegram_facade~work_off_export_queue needs to be used.
 The system provides a program to work off the outbound queue via a scheduled job.
o The program needs the warehouse number as well as the Packmaster id as parame-
ter
 Interface method /knapp/if_pm_process_import_tg needs to be implemented in order to
handle inbound telegrams.
 All Packmaster related customizing and master data tables need to be available in SPRO
(see chapter 2.4).
 XML logging table must be included in warehouse management monitor (/KNAPP/D_PM005)

2.2 Execution flows

No execution flow is needed.

2.3 Mockups / Use Cases / Processes

No mockups needed.

2.4 Additional information

Tables and views to be maintained:

/KNAPP/V_PM000  Packmaster instance

/KNAPP/D_PM001  Packmaster connection information

/KNAPP/T_PM007  Configuration properties

All interface related information are located in document Technical Documentation Packmaster.docx
on ELC sharepoint and the Packmaster business blue print.

3 US 2: Providing data for KiSoft Packmaster

After the “Packmaster planning date and time”, which is stored at the TU header, is reached, the
KiSoft Packmaster calculation is triggered. Therefor a background job is needed, which determines

03/04/2023 753422992.docx 4/18

 www.KNAPP.com

TUs with a “Packmaster planning date and time” equal to the current time or already in the past, with
an empty z-field for the “KiSoft Packmaster planning status” (= unplanned) on the header level and
with at least one entry in the z-table “ZTLGT_O_CAR”, which has the status “1 (initial)” or “3 (KiSoft
Packmaster calculation completed)”. If at least one entry has status “2 (KiSoft Packmaster calculation
started)”, the corresponding TU will not be taken into consideration for a calculation during this run.
As soon as all convenient TUs were determined, the status of the corresponding carton entries in the
z-table will be set to “2 (KiSoft Packmaster calculation started)”. All required information about the
corresponding PSHUs or already existing HUs will then be provided to the KiSoft Packmaster inter-
face via a structure and the Packmaster outbound queue.

3.1 Acceptance criteria

a. The system provides a program, which can be scheduled as a background job.
b. The system provides a variant for this program, which includes the warehouse number as
filter criteria.
c. The system determines all Outbound-TUs with an empty z-field for the “KiSoft Packmaster
planning status” (= unplanned) on the header level and a “Packmaster planning date and
time”, based on the z-fields “ZZ_PLAN_DATE_PM” and “ZZ_PLAN_TIME_PM” equal to the
current time or already in the past (see chapter 3.4).
d. The system determines all corresponding entries (= PSHUs) in the z-table “ZTLGT_O_CAR”,
which do have the status “1 (initial)” or “3 (KiSoft Packmaster calculation completed)” (see
chapter 3.4).
e. The system does not send any information to the KiSoft Packmaster calculation if at least one
ZTLGT_O_CAR entry for this TU has status “2 (KiSoft Packmaster calculation started)” in the
corresponding z-table.
f. The system fills the corresponding structure with the required data and saves the filled struc-
ture in the Packmaster outbound queue (see chapter 3.4).
g. The system sets the status of all related entries (= cartons) in the z-table “ZTLGT_O_CAR” to
“2 (KiSoft Packmaster calculation started)”.
h. The system determines the content of the ArticleGroup and the corresponding combine ma-
trix according to several rules (see chapter 3.4.2).

3.2 Execution flows

Option 1:
1. The user schedules a background job, which runs regularly.
2. The system starts the background job.
3. The system determines all Outbound-TUs with an empty z-field for the “KiSoft Packmaster
planning status” (= unplanned) on the header level and a “Packmaster planning date and
time”, based on the z-fields “ZZ_PLAN_DATE_PM” and “ZZ_PLAN_TIME_PM” equal to the
current time or already in the past.
4. The system determines all corresponding entries (= PSHUs) in the z-table “ZTLGT_O_CAR”,
which do have the status “1 (initial)” or “3 (KiSoft Packmaster calculation completed)”.
5. The system determines the content of the ArticleGroup and the corresponding combine ma-
trix according to several rules.
6. The system fills the corresponding structure with the required data and saves the filled struc-
ture in the Packmaster outbound queue.
7. The system sets the status of all related entries (= cartons) in the z-table “ZTLGT_O_CAR” to
“2 (KiSoft Packmaster calculation started)”.

Option 2:
1. The user schedules a background job, which runs regularly.
2. The system starts the background job.
3. The system determines all Outbound-TUs with an empty z-field for the “KiSoft Packmaster
planning status” (= unplanned) on the header level and a “Packmaster planning date and

03/04/2023 753422992.docx 5/18

 www.KNAPP.com

time”, based on the z-fields “ZZ_PLAN_DATE_PM” and “ZZ_PLAN_TIME_PM” equal to the

current time or already in the past.
4. The system determines all corresponding entries (= PSHUs) in the z-table “ZTLGT_O_CAR”,
which do have the status “1 (initial)” or “3 (KiSoft Packmaster calculation completed)”.
5. The system checks if there are entries in the z-table ZTLGT_O_CAR”, which do have the
status “2 (KiSoft Packmaster calculation started)”.
6. The system stops the program for the corresponding TU and does not save any data in the
corresponding structure (no data for this TU send to KiSoft Packmaster).

3.3 Mockups / Use Cases / Processes

No mockups needed.

3.4 Additional information

For further information regarding the z-fields “ZZ_PLAN_DATE_PM” and “ZZ_PLAN_TIME_PM” as
well as the assignment of outbound deliveries (ODOs) to TUs see document “C903A_2008_A_PPF-
action for creation of a TU and assignment of ODO to TU”.

For further information regarding the z-table “ZTLGT_O_CAR” see document “C903A_2011_A_Ex-
tension of KNAPP Cartonization”.

The following table shows, which fields in the structure need to be filled with which values by the sys -
tem and how to determine the value if needed:
Structure Structure field Value Determination
level
WPO WpoNo TU number value in field “TU_NUM” on TU
header (/SCWM/DE_TU_NUM)
CONTAINER ContTypeId Packaging 3-digit code in z-field “ZZ_PKINS” on
instruction ODO header
CONTAINER Length/Width/Height/Weight Dimensions dimensions in z-table
and weight ZTLGT_PACK_INST based on the
3-digit code in z-field “ZZ_PKINS” on
ODO header
WS ItemNo Carton HU value in field “SSCC number” in z-
number table ZTLGT_O_CAR
WS ItemDescription Packaging value in field “PMAT_NO” on HU
material of header
carton
WS ArticleGroup Division Combined string. See chapter 3.4.1
WS Weight Weight of value in field “G_WEIGHT” of either
carton PSHU or HU
WS MatchingCode Allowed same value as in structure-field
packaging “ContTypeId”
material for
pallet
WS Qty 1 No determination, always 1

3.4.1 ArticleGroup

Full example:

Pallet string | Division | Material (Product) + Batch | Purchase Order | Loose Pick Flag

H 0000338288|01|16810200000000236505|7694259781|LP

Example without batch:

03/04/2023 753422992.docx 6/18

 www.KNAPP.com

H 0000338288|01|1681020000|7694259781|LP

Example without Batch and without Loose Pick Flag:

H 0000338288|01|1681020000|7694259781|~

Combine Matrix 1 (Full example):

<CombineMatrix>

<Matrix Group1="~" Group2="~" Position="1" RuleName="NEW_DEVICE"/>

<Matrix Group1="~" Group2="~" Position="2" RuleName="NO_SPLIT_SOULD_STICK"/>

<Matrix Group1="~" Group2="~" Position="3" RuleName="NEW_DEVICE"/>

<Matrix Group1="~" Group2="~" Position="4" RuleName="NO_SPLIT_SOULD_STICK"/>

<Matrix Group1="~" Group2="~" Position="5" RuleName="NEW_DEVICE"/>

</CombineMatrix>

Combine Matrix 2 (Example without batch):

<CombineMatrix>

<Matrix Group1="~" Group2="~" Position="1" RuleName="NEW_DEVICE"/>

<Matrix Group1="~" Group2="~" Position="2" RuleName="NO_SPLIT_SOULD_STICK"/>

<Matrix Group1="~" Group2="~" Position="3" RuleName="NO_SPLIT_SOULD_STICK"/>

<Matrix Group1="~" Group2="~" Position="4" RuleName="NO_SPLIT_SOULD_STICK"/>

<Matrix Group1="~" Group2="~" Position="5" RuleName="NEW_DEVICE"/>

</CombineMatrix>

3.4.2 Determination of ArticleGroup Content

The palletizing can be controlled via specific criteria. It is possible to send KiSoft Packmaster the in-
formation, that product- and batch-clean pallets should be built. Additionally, it is possible to pack
loose pick cartons on a separate pallet.
To determine if the document type of the either linked ODO in combination with the shipping point
and ship-to partner or the linked IMST is marked for product / batch clean palletizing or loose picks
separately, the z-table “ZTLGT_DOC_TYPE_RLT” needs to be extended with the following two col-
umns:

Field name Description Data element / type

Product / batch clean palletizing Checkbox
Separate pallet for Loose picks Checkbox

For further information regarding this z-table see document “C903A_2011_A_Extension of KNAPP
Cartonization_v2”.

The following rules apply for the determination of the ArticleGroup:

Carton type Product / Product / LP sep- Result Combine
batch batch arately matrix
clean clean
car- palletiz-
toniza- ing
tion
Loose pick False True False PS | DIV | ~|PO|~ 1
03/04/2023 753422992.docx 7/18
 www.KNAPP.com

Full case False True False PS | DIV | PROD+BAT|PO|~ 1

Loose pick False False False PS | DIV | ~|PO|~ 2
Full case False False False PS | DIV | PROD | PO|~ 2
Loose pick True True True PS | DIV | PROD + BAT|PO|LP 1
Full case True True True PS | DIV | PROD+BAT|PO|~ 1
Loose pick False True True PS | DIV | ~|PO|LP 1
Full case False True True PS | DIV | PROD+BAT|PO|~ 1
Loose pick True False False PS | DIV | PROD | PO|~ 2
Full case True False False PS | DIV | PROD | PO|~ 2

4 US 3: Receive calculation result from KiSoft Packmaster

After the KiSoft Packmaster finished the calculation it will send an result to SAP EWM. Based on this
message, the received incremented number for each needed pallet will be used for creating a SSCC
number. This SSCC number, the category based on the category of the related cartons and the status
“3 (KiSoft Packmaster calculation completed)” will be stored in the z-table “ZTLGT_O_PAL” for each
pallet. Furthermore, the pallet SSCC will be assigned to the corresponding cartons in the z-table
“ZTLGT_O_CAR” and the status of the cartons will be changed to “3 (KiSoft Packmaster calculation
completed)” too. Additionally, the “KiSoft Packmaster planning status” on the TU header will be
changed to “X” (= planned). The system saves the corresponding received XML-file in background for
later usage

4.1 Acceptance criteria

a. The system checks if for there are already captured pallets for the corresponding TU” and
creates a SSCC number for each additionally required pallet based on the corresponding
number range object in the z-table “ZTLGT_O_PAL (see chapter 4.4).
b. The system determines the category for the pallet based on the category of the related car-
tons and the corresponding z-table.
c. The system captures the SSCC number, the category based on the category of the related
cartons as well as the status “3 (KiSoft Packmaster calculation completed)” and the packag-
ing material (based on packaging instruction of the KiSoft Packmaster result
(ContTypeID) in the z-table “ZTLGT_O_PAL”.
d. The system changes the status of the related cartons to “3 (KiSoft Packmaster calculation
completed)” in the z-table “ZTLGT_O_CAR”.
e. The system sets the value of the z-field “PGI readiness indicator” (ZZ_PGI_READY) on the
TU header to empty if more than 20 pallets are planned for this TU or if the sum of the weight
of all related pallets exceeds the maximum allowed weight per TU based on the customer
(see chapter 4.4).
f. The system sets the value of the z-field “PGI readiness indicator” (ZZ_PGI_READY) on the
TU header to “X” if 20 or less pallets are planned for this TU or if the sum of the weight of all
related pallets does not exceed the maximum allowed weight per TU based on the customer
(see chapter 4.4).
g. The system changes the “KiSoft Packmaster planning status” on the TU header to “X” (=
planned).
h. The system saves the corresponding received XML-file in table ZTLGT_PM_RESULT for
later usage.
i. The system writes entries in the standard transaction /SCWM/SLG1 in both cases, success
as well as error cases.
j. The system changes the status of all cartons that could not be packed onto a pallet to “1 (ini-
tial)”, sets the “Packmaster planning date and time” to the current time plus a custom addi-
tional time based on the z-table “ZTLGT_WH_DFLT” and does not update the z-field “PGI
readiness indicator” (ZZ_PGI_READY) in case it receives the calculation result including data
in the field WC_NOT_LOADED (see chapter 4.4).

03/04/2023 753422992.docx 8/18

 www.KNAPP.com

k. The system writes an alert in the standard transaction /SAPAPO/AMON1 in case an error
occurred including all needed information dependent from the kind of error (e.g. TU number,
PSHU number, executed and failed checks, error code based on handbook, …).

4.2 Execution flows

Option 1:
1. The KiSoft Packmaster sends the calculation result via the Packmaster inbound queue to
SAP EWM.
2. The system receives the calculation result and deletes all related entries from the structure in
the Packmaster outbound queue.
3. The system checks that there are no already captured pallets numbers (= SSCC) for the cor-
responding TU.
4. The system creates a SSCC number for each incremented number received from the KiSoft
Packmaster.
5. The system captures the SSCC number, the category based on the category of the related
cartons as well as the status “3 (KiSoft Packmaster calculation completed)” and the packag-
ing material (based on packaging instruction of the KiSoft Packmaster result
(ContTypeID) in the z-table “ZTLGT_O_PAL”.
6. The system assigns the pallet number (= SSCC) to the corresponding carton and changes
the status to “3 (KiSoft Packmaster calculation completed)” in the z-table “ZTLGT_O_CAR”.
7. The system updates the “PGI readiness indicator” on the TU header based on the number of
finally planned pallets and the sum of their weight.
8. The system changes the “KiSoft Packmaster planning status” on the TU header to “X” (=
planned).
9. The system saves the corresponding received XML-file in background for later usage.
10. The system writes entries in the standard transaction /SCWM/SLG1.

Option 2:
1. The KiSoft Packmaster sends the calculation result via the Packmaster inbound queue to
SAP EWM.
2. The system receives the calculation result and deletes all related entries from the structure in
the Packmaster outbound queue.
3. The system checks that there are already captured pallets numbers (= SSCC) for the corre-
sponding TU.
4. The system creates a SSCC number for all required pallets, which are not yet captured in the
z-table “ZTLGT_O_PAL”.
5. The system captures the SSCC number, the category based on the category of the related
cartons as well as the status “3 (KiSoft Packmaster calculation completed)” and the packag-
ing material (based on packaging instruction of the KiSoft Packmaster result
(ContTypeID) in the z-table “ZTLGT_O_PAL”.
6. The system assigns the new pallet number (= SSCC) to the corresponding carton and
changes the status to “3 (KiSoft Packmaster calculation completed)” in the z-table
“ZTLGT_O_CAR”.
7. The system updates the assignment of a pallet number (= SSCC) to a carton and changes
the status to “3 (KiSoft Packmaster calculation completed)” in the z-table “ZTLGT_O_CAR” if
needed.
8. The system updates the “PGI readiness indicator” on the TU header based on the number of
finally planned pallets and the sum of their weight.
9. The system changes the “KiSoft Packmaster planning status” on the TU header to “X” (=
planned).
10. The system saves the corresponding received XML-file in background for later usage.
11. The system writes entries in the standard transaction /SCWM/SLG1.

Option 3:
1. The KiSoft Packmaster sends the calculation result to SAP EWM.

03/04/2023 753422992.docx 9/18

 www.KNAPP.com

2. The system receives the calculation result including cartons that are not able to be packed on
a pallet (WS_NOT_LOADED).
3. The system executes all updates for the correctly packed cartons like in case it receives the
calculation result without not-packed cartons.
4. The system changes the status of all cartons that could not be packed onto a pallet to “1 (ini-
tial)” and sets the “Packmaster planning date and time” to the current time plus a custom
additional time based on the z-table “ZTLGT_WH_DFLT”.
5. The system saves the corresponding received XML-file in background for later usage.
6. The system writes an alert in the standard transaction /SAPAPO/AMON1.

4.3 Mockups / Use Cases / Processes

No mockups needed.

4.4 Additional information

The following table shows, which fields in the structure need to be read out in order to execute some
further checks and processes in SAP EWM:
Structure level Structure field Value
WPO WpoNo TU number
CONTAINER CntNo Sequential number to determine how
many pallets are planned
WS ItemNo Carton HU number (SSCC number)

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. The table will look like this e.g.:
WH SSCC Reference num- Cate- Sta- Assign. KiSoft PM cal-
no. ber gory tus WC culation time
CHG1 45678965 1
4
CHG1 12345678 02 3 20190424143711
8
CHG1 95123541 05 4 MPS1 20190423131107
1

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

Field name Description Date type /
length
Warehouse number Number of the warehouse; key field CHAR / 4
SSCC Serial Shipping Container Code; key field CHAR / 18
Reference number Number of the IM_ST document CHAR / 35
Category Categorization based on category of related cartons CHAR / 2
in order to handle the “assignment of pallets to pal-
letizing station” correctly; lowest category of cartons
will be overtaken
Status Status of the pallet CHAR / 1
Assigned work center Number of the work center (= palletizing station) to CHAR / 4
which the pallet was assigned for palletizing
KiSoft PM calculation Timestamp of the last KiSoft Packmaster calculation DEC / 21/7
time for this pallet

The following table shows the potential categories a pallet can get assigned to depended on the cate-
gory of the cartons linked to the pallet:
Category Description Carton categories

03/04/2023 753422992.docx 10/18

 www.KNAPP.com

no.
01 Non-mech cartons 01
02 Oversized cartons 02
03 M2P cartons 03
04 OSR cartons 04
05 M2P & OSR cartons 03 + 04

The following table shows the potential statuses that can be assigned to a pallet in the column “sta-
tus” in the above-mentioned table:
Status Description
1 initial
2 KiSoft Packmaster calculation started
3 KiSoft Packmaster calculation completed
4 Palletizing started
5 Palletizing finished

For further information regarding the custom status for “Packmaster planning status” on the TU
header see document “C903A_2008_A_PPF-action for creation of a TU and assignment of ODO to
TU”.
For further information regarding the new setting of the “Packmaster planning date and time” see
document “C903A_2014_A_Logic for G2P station”.

For further information regarding the z-table “ZTLGT_O_CAR” as well as the extension of the stan-
dard transaction /SCWM/AMON1 to write an alert in case of an error see document
“C903A_2011_A_Extension of KNAPP Cartonization”.

The weight restrictions per customer are maintained in the z-table “ZTLGT_WEIGHT_CUST”. For
further information regarding the z-table see document “C903A_5010_A_MON Extension for TU
split”.

5 US 4: Calculation of palletizing starting date and time (PST)

Furthermore, the finishing of this calculation always triggers the calculation of the palletizing starting
date and time (PST). This date/time is based on the planned date and time for GI, which is captured
on the TU header level as well as the average time to retrieve a carton from the OSR and transport it
to the palletizing station, the calculated time for palletizing all cartons on all pallets and the time
needed to finish a pallet. The corresponding formula looks like this:

PST = PGI – CR – PAL – PFT

The calculated PST will be saved in the corresponding fields on the TU header, which need to be
implemented additionally. As soon as the planned date and time for GI changes or the calculation of
the KiSoft Packmaster is retriggered, the calculation of the PST will automatically be executed again
too. This can happen in several steps during the whole outbound process.

5.1 Acceptance criteria

a. The system determines all required variables for the calculation of the PST.
b. The system captures the calculated palletizing starting date in the z-field “ZZ_PSD” and the
time in the z-field “ZZ_PST” on the TU header.

5.2 Execution flows

Option 1:
1. The system receives the calculation result from the KiSoft Packmaster.

03/04/2023 753422992.docx 11/18

 www.KNAPP.com

2. The system calculates the palletizing starting date and time based on the corresponding for-
mulas.
3. The system captures the calculated date and time in the corresponding z-fields.

Option 2:
1. The user updated the planned date and time for GI.
4. The system calculates the palletizing starting date and time based on the corresponding for-
mulas.
2. The system captures the calculated date and time in the corresponding z-fields.

5.3 Mockups / Use Cases / Processes

No mockups required.

5.4 Additional information

In order to be able to store the calculated palletizing starting date and time on the TU header, addi-
tional z-fields are needed. The following table shows the details about them:
Data type /
Field name Description Editable
length
ZZ_PSD Planned palletizing starting date DATS / 8
ZZ_PST Planned palletizing starting time TIMS / 6

As soon as the PST changes, the calculation of the LSD will automatically be executed again. For
more information regarding the calculation of the latest starting date and time (LSD) see document
“C903A_2011_A_Extension of KNAPP Cartonization”.

The following table describes the single parameter of the formula for the PST:

Name Description Where to find

PGI date for the Time, when all pallets from one TU need to be TU header level z-fields:
TU (PGI) ready in the HBW or staging area for PGI and ZZ_PLAN_GI_DATE
creation of the shipment. ZZ_PLAN_GI_TIME

Carton retrieval Average time to retrieve a carton from the Z-table ZTLGT_PST_TIMES
(CR) OSR and transport it to the palletizing station.
Will only be considered once, as an average
value for automated (incl. FastBox) and man-
ual stations.

Time for palletiz- Calculated time for palletizing all cartons on -

ing (PAL) all pallets for the TU based on corresponding
formula (see below).

Pallet finishing Calculated time for pallet finishing (incl. label- -

time (PFT) ing, hooding, re-storage in HBW, …) based
on corresponding formula (see below). Will
only be considered once, as the finishing
starts during palletizing.

To be able to get the time for palletizing all cartons the following formula applies:

PAL = (#pal_a*PCTa + #pal_m*PCTm + #car_a*Tcar_a + #car_m*Tcar_m) / (PSA * FAC)

The following table describes the single parameter of the formula for the PAL:
03/04/2023 753422992.docx 12/18
 www.KNAPP.com

Name Description Where to find

Time for carton Average time for palletizing one carton manu- Z-table ZTLGT_PST_TIMES
palletizing manu- ally by the user
ally (Tcar_m)

Time for carton Average time for palletizing one carton auto- Z-table ZTLGT_PST_TIMES
palletizing auto- matically by the robot
matically
(Tcar_a)

Pallet changing Average time how long the pallet exchange Z-table ZTLGT_PST_TIMES
time manual sta- takes at the manual station (time for releasing
tion (PCTm) the finished pallet and transport the new pallet
to the station)

Pallet changing Average time how long the pallet exchange Z-table ZTLGT_PST_TIMES
time automatic takes at the automatic station (time for releas-
station (PCTa) ing the finished pallet and transport the new
pallet to the station)

Number of man- Number of pallets belonging to the TU, which -

ual pallets will be palletized manually (containing M2P
(#pal_m) cartons) based on the z-table ZTLGT_O_PAL

Number of auto- Number of pallets belonging to the TU, which -

matic pallets will be palletized by the robot (NOT containing
(#pal_a) M2P cartons) based on the z-table
ZTGLT_PAL_OUTBND

Number of man- Number of cartons per TU, which will be pal- -

ual cartons letized manually (containing M2P cartons)
(#car_m) based on the z-table ZTLGT_O_CAR

Number of auto- Number of cartons per TU, which will be pal- -

matic cartons letized by the robot (NOT containing M2P
(#car_a) cartons) based on the z-table
ZTLGT_CAR_OUBND

Factor for simul- Factor to reduce 100% of workstation avail- Z-table ZTLGT_PST_FACTORS
taneity (FAC) ability to reflect parallel usage of workstations
for different TUs. Different values depending
on time of the day. The PGI date will be com-
pared with the according customized value for
that timeslot (from-to).

Palletizing station Factor to increase the capacity of the worksta- Z-table ZTLGT_PST_FACTORS
availability (PSA) tions and to reduce therefore the time for pal-
letizing. Workstation availability to reflect par-
allel usage of different workstations. Different
values depending on time of the day.
The PGI date will be compared with the ac-
cording customized value for that timeslot
(from-to).

03/04/2023 753422992.docx 13/18

 www.KNAPP.com

To be able to get the time for pallet finishing the following formula applies:

PFT = [ Min(#pal, FSA) * Tpft ] * FAC

The following table describes the single parameter of the formula for the PFT:

Name Description Where to find

Pallet finishing Average time how long the finishing per pallet Z-table ZTLGT_PST_TIMES
time (Tpft) takes (incl. labeling, hooding, re-storage in
HBW, …)

Pallet finishing Factor to increase the capacity of the worksta- Z-table ZTLGT_PST_FACTORS
station availability tions and to reduce therefore the time for pal-
(FSA) let finishing. Workstation availability to reflect
parallel usage of different workstations. Differ-
ent values depending on time of the day.
The PGI date will be compared with the ac-
cording customized value for that timeslot
(from-to).

The z-table “ZTLGT_PST_TIMES” will be integrated in the customizing as an application table and
therefore maintainable if needed. This table will look like this e.g.:
Activity Required time
Carton retrieval (CR) 00:05:00
Time for carton palletizing manually (Tcar_m) 00:00:20
Time for carton palletizing automatically (Tcar_a) 00:00:10
Pallet changing time manual station (PCTm) 00:02:00
Pallet changing time automatic station (PCTa) 00:01:00
Pallet finishing time (Tpft) 00:05:00

The following table explains the different fields of this table:

Field name Description Date type / length
Activity Name of the required activity CHAR / 40
Required time Time period, which is needed to execute the activity; TIMS / 6
hh:mm:ss

The z-table “ZTLGT_PST_FACTORS” will contain values per weekday and time ranges to capture
the different needed factors for the calculation, will be integrated in the customizing as an application
table and therefore maintainable if needed. This table will look like this e.g.:
Weekday From time To time FAC PSA FSA
1 00:00:00 05:59:59 1.00 02 02
1 06:00:00 11:59:59 0.25 10 10
1 12:00:00 17:59:59 0.50 08 08
1 18:00:00 23:59:59 1.00 02 02
2 00:00:00 05:59:59 1.00 02 02
2 06:00:00 11:59:59 0.25 10 10
2 12:00:00 17:59:59 0.50 08 08
2 18:00:00 23:59:59 1.00 02 02
3 00:00:00 05:59:59 1.00 02 02

03/04/2023 753422992.docx 14/18

 www.KNAPP.com

3 06:00:00 11:59:59 0.25 10 10

3 12:00:00 17:59:59 0.50 08 08
3 18:00:00 23:59:59 1.00 02 02
4 00:00:00 05:59:59 1.00 02 02
4 06:00:00 11:59:59 0.25 10 10
4 12:00:00 17:59:59 0.50 08 08
4 18:00:00 23:59:59 1.00 02 02
5 00:00:00 05:59:59 1.00 02 02
5 06:00:00 11:59:59 0.25 10 10
5 12:00:00 17:59:59 0.50 08 08
5 18:00:00 23:59:59 1.00 02 02
6 00:00:00 05:59:59 1.00 02 02
6 06:00:00 17:59:59 0.75 05 05
6 18:00:00 23:59:59 1.00 02 02
7 00:00:00 23:59:59 1.00 02 02

The following table explains the different fields of this table:

Field name Description Date type / length
Weekday Number that represents the weekday in SAP stan- NUMC / 1
dard; based on standard field “WKDAY”
From time Starting time for the time range; hh:mm:ss TIMS / 6
To time End time for the time range; hh:mm:ss TIMS / 6
FAC Factor to reflect parallel usage of workstations for NUMC / 1 / 2 dec
different TUs in percent
PSA Number of on average available palletizing worksta- CHAR / 2
tions
FSA Number of on average available pallet finishing work- CHAR / 2
stations

6 US 5: Calculation of physical palletizing start date and time

(PPS)
Furthermore, after the palletizing starting date and time (PST) was calculated, the system also calcu-
lates the physical palletizing start date and time, which is required for reporting purpose. This date/
time is based on the planned date and time for GI, which is captured on the TU header level as well
as the calculated time for palletizing all cartons on all pallets and the time needed to finish a pallet. All
single parameters needed for this calculation are already calculated / determined during the calcula-
tion of the PST. The corresponding formula looks like this:

PPS = PGI – PAL – PFT

The calculated PPS will be saved in the corresponding fields on the TU header, which need to be
implemented additionally. As soon as the planned date and time for GI changes or the calculation of
the KiSoft Packmaster is retriggered, the calculation of the PPS will automatically be executed again
too. This can happen in several steps during the whole outbound process.

6.1 Acceptance criteria

a. The system determines all required variables for the calculation of the PPS.
b. The system captures the calculated physical palletizing starting date in the z-field
“ZZ_PPS_DATE” and the time in the z-field “ZZ_PPS_TIME” on the TU header (see chapter
6.4).

03/04/2023 753422992.docx 15/18

 www.KNAPP.com

6.2 Execution flows

Option 1:
1. The system receives the calculation result from the KiSoft Packmaster.
2. The system calculates the physical palletizing start date and time based on the corresponding
formula.
3. The system captures the calculated date and time in the corresponding z-fields.

Option 2:
1. The user updated the planned date and time for GI.
2. The system calculates the physical palletizing start date and time based on the corresponding
formula.
3. The system captures the calculated date and time in the corresponding z-fields.

6.3 Mockups / Use Cases / Processes

No mockups required.

6.4 Additional information

In order to be able to store the calculated physical palletizing start date and time on the TU header,
additional z-fields are needed. The following table shows the details about them:
Data type /
Field name Description Editable
length
ZZ_PPS_DATE Physical palletizing start date DATS / 8
ZZ_PPS_TIME Physical palletizing start time TIMS / 6

For further information regarding the single parameters of the formula for the PPS see chapter 5.

7 US 6: Calculation of physical palletizing end date and time

(PPE)
Furthermore, after the palletizing starting date and time (PST) was calculated, the system also calcu-
lates the physical palletizing end date and time, which is required for reporting purpose. This date/
time is based on the planned date and time for GI, which is captured on the TU header level as well
as the time needed to finish a pallet. All single parameters needed for this calculation are already
calculated / determined during the calculation of the PST. The corresponding formula looks like this:

PPE = PGI – PFT

The calculated PPE will be saved in the corresponding z-fields on the TU header. As soon as the
planned date and time for GI changes or the calculation of the KiSoft Packmaster is retriggered, the
calculation of the PPE will automatically be executed again too. This can happen in several steps
during the whole outbound process.

7.1 Acceptance criteria

a. The system determines all required variables for the calculation of the PPE.
b. The system captures the calculated physical palletizing starting date in the z-field
“ZZ_PPE_DATE” and the time in the z-field “ZZ_PPE_TIME” on the TU header (see chapter
7.4).

7.2 Execution flows

Option 1:

03/04/2023 753422992.docx 16/18

 www.KNAPP.com

1. The system receives the calculation result from the KiSoft Packmaster.
2. The system calculates the physical palletizing end date and time based on the corresponding
formula.
3. The system captures the calculated date and time in the corresponding z-fields.

Option 2:
1. The user updated the planned date and time for GI.
2. The system calculates the physical palletizing end date and time based on the corresponding
formula.
3. The system captures the calculated date and time in the corresponding z-fields.

7.3 Mockups / Use Cases / Processes

No mockups required.

7.4 Additional information

In order to be able to store the calculated physical palletizing end date and time on the TU header,
additional z-fields are needed. The following table shows the details about them:
Data type /
Field name Description Editable
length
ZZ_PPE_DATE Physical palletizing end date DATS / 8
ZZ_PPE_TIME Physical palletizing end time TIMS / 6

For further information regarding the single parameters of the formula for the PPS see chapter 5.

8 Architecture
to be filled in by the developer before implementation

<This part describes the implementation concept for the whole Development Order. It consists of
textual and/or tabular descriptions as well as diagrams of process flows and components which are
produced. In case of modification only the change is documented. There could be:
- (optional) description of implemented parameters
- (optional) diagram of classes
- (optional) description of implemented configuration tables, inputs, etc. …

For this chapter it is needed to create a ‘task’ in JIRA, which is linked to the ‘epic’.>

9 Technical implementation

9.1 Entry point

to be filled in by the developer during or after implementation

<Enumeration of entry points.>

9.2 Packages
to be filled in by the developer during or after implementation

<Enumeration of all packages.>

03/04/2023 753422992.docx 17/18

 www.KNAPP.com

9.3 Implemented BAdI’s

to be filled in by the developer during or after implementation

<Enumeration of all used BAdIs.>

9.4 Important classes / function modules

to be filled in by the developer during or after implementation

<Enumeration of the most important classes and function modules.>

9.5 Database tables

to be filled in by the developer during or after implementation

<Enumeration of all tables.>

9.6 Checkpoint groups

to be filled in by the developer during or after implementation

<Enumeration of the checkpoints group.>

9.7 Others
to be filled in by the developer during or after implementation

<Enumeration of other development objects like authorization objects, number ranges, change docu-
ments, etc.>

03/04/2023 753422992.docx 18/18