SD - Surya - Venkat - 2016-07-25 - 27709 - Packing - New Box Type (Dan by 2017-08-26) #Delivery #abappacking

SPECIFICATIONS

24193 - Spec - Packing - New Box Type


Purpose

Create a new box series for LIDS customer.

Admin Info

Purpose
 Packing - New Box Type
Requested By
 Dan Brennan
Spec Created By
 Surya Basa
Spec Created Date
 07/28/2016
Spec QA by
 Deepak Yasam
Objects
  • ZPWEAVER_SHMAS
  • ZPWEAVER_VASRL
  • ZPWEAVER_CASHMAS
  • ZPWEAVER_PACKMAT
  • ZPWEAVER_SHALT
  • ZSD_PACK
Document Status
 Completed


Estimates


Sl.No
 Activity
 Estimation in Hours
1
 Research
 08
2
 Documentation
 08
3
 Development/ Config
 60
4
 Unit test in DEV
 32
5
 Unit test in QUA
 32
6
 Other activity

TOTAL
 142

References

Prior Tickets

[Provide links of prior associated Spec / Break Fix BOSS document(s)]

SD - Surya - 2015-10-13 - 6963 - Spec - To Pack based on Silhouettes (PH4) (Dan by 2016-03-18)


Documents

[Attach any document(s) received for the requirement(s)]

Packing - New Box - Test Scenarios.xlsx


Spec Changes

[List the changes made to program after the approval of the original requirement along with the Date on which the change request was received and the name of the initiator]

Sl.
 Change Details
 Requested By
 Requested On
 Notes if any
SD001
 Fixed dump issue when program is executed using shipping point for inbound deliveries
 Dan Brennan
 10-07-16
SD002
 Change in logic to exclude packed delivery and log change on open run and shipping point.
 Dan Brennan
 10/26/2016















Functional Requirement

Purpose/WHY:

[Explain the purpose of the project and the reason why this requirement has come]

Modify the packing program to accommodate the "D" series box, which is specific to Lids.

6/1/2016

As you know, one of the goals of the re-written packing program was that it be configurable, so that if a new box type is created, we would need little or no ABAP changes to handle it. To support Lids (our largest customer), we would like to introduce a new series of box - "D". A 1D box will hold 36 caps while a 4D box will hold 144 caps. I have reviewed the configurable tables for the packing program, and believe I've identified the necessary entries we will need (see below). Can you please review and let me know what (if any) other modifications we would also need to ensure this box is picked if the VAS triggers on the order? If the VAS codes for this box type (PL1, PL2) do not exist on the order, we'd want the existing logic to kick in - this box type would be restricted to a small set of customers, who would be given this VAS.

(1) ZPWEAVER_CASHMAS - Create a new Carton Type (Z02) and assign quantity ranges [done in NECNED-300]
(2) ZPWEAVER_SHMAS - Assign silhouette (ex. 021 - 59FIFTY) to new carton type (Z02) [was not able to complete]
(3) ZPWEAVER_PACKMAT - Assign materials to carton (1D, 4D) [done for 1D in NECNED-300]
(4) ZPWEAVER_VASRULE - Assign VAS codes (PL1, PL2) to VAS type and material [done in NECNED-300]
(5) ZPWEAVER_VASRL - Assign VAS codes (PL1, PL2) to VAS type and box size [done in NECNED-300]
(6) ZPWEAVER_SHALT - Assign silhouette (021 - 59FIFTY) to box series (D) [done in NECNED-300]

The business would like to roll out this new box type in the near future, so please treat this review with high urgency.

1. Does the same silhouette will have multiple boxes and carton types maintained in ZPWEAVER_SHMAS table. If yes, then as new cart type(Z02) is used for the new boxes (PL1, PL2), with the existing setup we can't add multiple entries in ZPWEAVER_SHMAS for same silhouette.
We don't have to use a new car type - we can use Z01 if that's what's needed. I assumed a new car type (Z02) might be necessary. We DO need to ensure the "D" series is picked if the PL1/PL2 VAS codes are on the order....if they aren't, then the existing A/B series boxes should be used.

2. Does this specific customer can have other regular packing VAS codes other than PL1 ,PL2? - yes, the customer could sometimes use A/B depending on the silhouette as well.
That's why my thinking is we'd want to drive the box choice based on silhouette.

3. Does this specific customer will always order same silhouettes ? the customer can order any of our silhouettes.
Based on the VAS in the order, the box type should be chosen.

7/28/2016

1. What is the max box size for a D (say 1D) series - 12/36?
the 1D will hold 36 caps, and the largest D-series is a 4D (144 caps)

2. Will there be LIDS specific orders for silhouettes with D series only - the scenarios don't have multiple silhouettes-multiple series tests?
good point, I will add scenarios with mix series.

3. Will there be a 5D or the maximum is 4D (144)?
max is a 4D

4. The "notes" say "should pack in D series", irrespective of silhouettes. Will these orders have just one VAS (PL1/PL2) on all items, if so pack them into D series? And should the program ignore other VAS if found on other items or error out? E.g. If a LIDS order has two items - Item 10 has PL1/PL2 and Item 20 has P19
similar to question 2, I will call out scenarios with a mix of series

5. Is there any difference between PL1 and PL2?
PL1 would be used if there is ever a case where LIDS wants to receive a max box size of a 1D. PL2 would be their standard where they would accept up to a 4D.

6. Can PL1/PL2 be assigned to other customers - if not how should the program handle a scenario if it shows up on other orders - error out?
it is possible in the future that other customers could desire to use the D-series, so if it is added to the order / delivery, we should pack it

7. Do we need to include cross dock and Alt UoM scenarios?
Cross-dock, no, because this is only planned to be used from our factories. Alt UoM I will add. Good point.

08/17/2016

1. Multiple Silhouettes and pack mix - The delivery has different silhouettes such as A,B and D , then the D series materials should be packed separately without mixing with A and B silhouettes?
ALL silhouettes going to Lids should be packed in the D series boxes if it’s a dropship.

2.Max box , single/multiple silhouettes – The delivery with PL1 or PL2 max box pack codes ,but there is no entry in the customer specific table , then should we display any error log OR should we consider the respective max boxes and pack the delivery accordingly? If there’s a delivery with those max box codes to a customer who’s not in the table there should be an error. Lids should be the only customer in that table.

3.Caselot / Crossdock , single/multiple silhouettes - Need to display an error if it has PL1,PL2 max box pack codes in any of the materials in the delivery ? This is not applicable, there will be no caselot/crossdock coming out of 9010 to LIDS

08/23/2016

1. New Shilouttes (F series and D series ) with different UoM , were provided to BMS by Daniel Brennan.
2. The new logic if the customer/silhouette are in the new table and the delivery has one of those VAS codes, it should pick the box type from the new table. Else, it should use the standard logic we built previously.
3. ONLY if the VAS codes exist, AND the customer is in the new table, should you use the new table

09/12/2016

Also, I would like to inform that , if the customer doesn’t match with the table and have PL1/PL2 VAS codes in the delivery , the packing would be done in 1 or 4 max box and the box series would be as per the old logic. Is this correct ?

If not, in the above case should we exclude PL1/PL2 VAS codes though they exists in the delivery and pack the delivery by default in 6 max box as per the old logic? Also, if along with these PL1/PL2 VAS codes , if the delivery has other max box VAS codes , then should we exclude PL1/PL2 and consider the remaining max box VAS codes and pack accordingly?

An error message should be displayed as Customer not valid for VAS codes PL1 / PL2

09/14/2016

To support the changes to the packing program, we need to populate values into the following tables:

All of these tables should be editable in Dev, QA, and Prod, but as you can see above, only one of them is. Can you please modify the table settings so that going forward these are editable in all systems, and don’t ask for a transport?

In Scope:

[List the activities to be included in scope]
The new logic should only work for the customer specific .

Out of Scope:

[Out of scope activities]
The old packing logic shouldn't be changed.

Solution Summary

[Discuss this section with Requester and get approval prior to beginning work]

1.Customer
2. Silhoutte
3. Box series
4.Package UoM
5.Carton type.

1.If they are matched then the box series and corresponding package UoM is considered for the respective silhoutte and packed accordingly.
2.If the silhoutte doesn't match with the table , then an error should be displayed.
3.If any of the conditions ie., customer and PL1/PL2 doesn't satisfy then the delivery should be packed as per the old logic.
4.For caselot/crossdock the packing shouldn't happen and an error should be displayed.


image001.png

Test Plan

[List test scenarios/cases to be executed here]

Outbound Del EA - D series.xlsx


Outbound Del Alt UoM - D series.xlsx

Inb Del Pack by SKU - D series.xls

Inb Del Pack by Family - D series.xlsx

Inb Del Pack by Mix - D series.xls

Packing negative tests.xlsx

Solution Details

[Provide complete technical details for configuration or programming here]



Issues

[List Issues / Bugs identified in configuration or development]