By Jukka Pelkonen, Uponor
Uponor is a leading international provider of plumbing and indoor climate systems and services for the building and utility sectors. Available in some 100 countries, Uponor solutions meet the needs of customers and end users, while helping to preserve the natural environment. They are designed for efficient performance, long lifetime, easy installation and a low environmental footprint. With ca. 3,800 committed employees and a local presence in over 30 countries, Uponor is at your service all over the world.
One of the challenges for suppliers of manufactured products is that transportation carriers and customers insist on having shipments properly packed and documented. This means shipping license plate numbers (LPNs) must have the correct container item information with the right package dimensions and weights.
To improve our ability to meet these requirements, Uponor enhanced functionalities in Mobile Supply Chain Applications (MSCA) and in Oracle Warehouse Management (WMS).
Developing MSCA and WMS enhancements takes time and can be complex. Even more challenging is, first, defining the right processes and then getting end users committed to the change and prepared to follow through with the new processes.
The first Oracle E-Business Suite (EBS) go-live at Uponor was in Germany in summer 2006. After that, Uponor launched a program to roll out EBS across Europe. Uponor is using a very large scale of different Oracle EBS modules, and EBS is the standard ERP system to run Uponor's operations. In 2013, EBS was upgraded from R11.5.10 to R12.1.3.
Transport carriers commonly require exact information about packaging and expect that information to be correct and exact. This is especially true in the case of export shipments; Uponor handles a lot of shipments both within and outside of EU countries. Key information includes:
Good customer service means that we are able to deliver shipments with proper delivery, packing and transportation documentation that is correct, detailed and correctly labelled. Uponor provides a range of different kinds of logistics services, and many customers have special packing requirements. Fulfilling these packing requirements is challenging but must be done efficiently and correctly. At the same time, so called standard sales orders must be managed even more efficiently and with a lean process.
There were multiple challenges to overcome before we were able to meet the carrier and customer requirements.
First, it must be possible to update packaging dimensions at any time in any status of the LPN at the warehouse. A typical situation is that a container item can be updated to the LPN, but it only gives default dimensions for the LPN from the container item master data. However, in real life, packing is different: Boxes are modified to be higher or smaller, and pallet height differs based on the items packed on the pallet. In addition, there are other types of products that are not palletized, such as loose coils. In that case, dimensions are often unknown before packing/staging the goods. So there is a need to be able manage different kinds of container items and products.
Another aspect is the need for an efficient way to update container items to LPNs in the case of full single-item pallets. For example, this is the case when we ship 20 pallets of the same item to a customer. All information is preknown, but we need an efficient way to get all of the LPNs updated at once, instead of manually updating them LPN by LPN. Our approach was to establish that one pallet means one parent LPN.
We wanted a user-friendly tool to work with during the packing operation. There are two ways in standard Oracle WMS to perform packing: either with the Oracle Packing Workbench tool at physical packing stations or with MSCA via handheld scanners. The challenge was to determine how to efficiently perform picking and packing in the case of special packing requirements.
These functionalities are enhanced at Uponor:
To be able to update dimensions and weights in MSCA at any point of time for LPN, we built a customized MSCA page "Update LPN." The customized page is modified from the standard MSCA page "Update LPN." In the new customized page, it is possible to update a container item when LPN is in different phases, e.g., receiving, inventory, loaded, staged. Also, the container item can be re-updated as many times as is required. To avoid mistakes when a selecting container item, the description was also required to be shown.
Update Gross Weight feature: In addition to the possibility of changing the gross weight of LPN, we required visibility into the tare weight and net weight. Our principle is that tare weight (weight of the packaging material of the container item) is, by default, correct; we trust that and there is no need to update it. This means that if gross weight is updated, then net weight is automatically adjusted as tare weight is always with the default value.
Calculation for Net Weight:
Net Weight = Gross Weight – Tare Weight
In the customized solution, the volume of LPN is only calculated based on dimensions, meaning volume itself cannot be directly changed. So volume is always automatically calculated from given dimensions. Container items are divided to Box Type (IN-TO) and Pallet Type (ON-TO).
When the Box Type container item is selected, dimensions are defaulted automatically from the Container Item Master Data Dimensions. If needed, any of the dimensions can be manually changed, which automatically recalculates volume.
When the Pallet Type Container Item is selected, then only width and length dimensions are automatically taken from the Container Item Master Data Dimensions. Height is calculated based on the height of the pallet itself and based on product item volumes on top of the pallet. The height calculation formula is:
Height = Height of the Container Item + (Total LPN Product Item Volumes / Container Item Width / Container Item Length)
For example, if the pallet container item master data height dimension is 15 cm, width is 80 cm, length is 120 cm, volume of the packed product items are 1m3, and the calculated height of the items on to pallet based on total volume of the items and width and length of the pallet is 104 cm, then the height dimension calculation is:
Height = 15cm + (1m3/80cm/120cm) = 15cm + 104cm = 119cm (See Figure 1.)
Users can always measure the real height of the pallet and update the height at the customized "Update LPN" screen. For us, volume always means total volume including the container item volume, which means the pallet itself is taken into the calculation for total volume.
To be able to automate updating full-size, single-item package LPNs with the container item, we built a customized concurrent request run. The idea is that this concurrent run checks setup data and updates all LPNs accordingly when the setup data matches LPN item onhands. In Container Item Relationship descriptive flexfields (DFFs), there is defined container item information for this specific container-item/item relationship. This is especially handy for palletized items because the height of the full-size, single-item pallets varies depending on product.
As the Finish Good (FG) Item Master information is globally harmonized, meaning the same item has the same packing sizes in all warehouses, it was decided that container item relationship data is set up at the master level. This way, we need only a single setup per item, which eliminates the need to do the same setting in each inventory organization.
Running this concurrent as a scheduled request, we are getting automatically a large amount of LPNs ─ that are stored in our warehouses ─ updated with correct container item information. Without this automated LPN updating process, we would not have had the possibility of a feasible and efficient way to update all LPNs in our warehouses.
One of the key challenges with LPN dimensions (length, width, height) was that as these fields in our solution are added as new DFFs for LPN, there is no good visibility afterwards as to what the dimensions are. So, we needed to build a visibility screen. Our approach was to build the new screen on top of our previously customized "Transportation Planning Form." With this screen, it is easy to see all key data for each LPN, and it is also easy to see all LPN data for a whole delivery at one time. Our main use for this visibility allows users to double check, if needed, what data is being updated for each LPN.
We saw that we needed to improve our system support for packing stations in our outbound warehouse process. Earlier, we had physical packing stations to perform physical packing operations, but we did not use the existing standard Oracle Packing Workbench. The main reasons to start looking at using the Oracle Packing Workbench tool were that earlier we were forced to use paper picking lists to show all special packing requirements since MSCA picking screen attachments cannot manage to handle a variety of special packing information data. Also, there was a strong need to separate picking and packing processes to make sure that both operations could be run most efficiently.
At the beginning, there were three options for packing tool for packing stations:
We decided to customize a totally new Packing Workbench Tool. The main reasons for our decision:
The main implementation challenges were related to the different kinds of requirements for the outbound process. Europe is dispersed geographically by countries and nationalities to different local markets and their needs. Customers and carriers vary a lot between countries, and country-specific regulations still exist. This means the model that fits one country won't work in another country. Regulations for export shipments require special attention; it is a must to take care of these.
Uponor's product portfolio varies from small-size fittings to very large products. Storage of these large products is commonly done at warehouse outdoor areas, which increases the challenges for warehouse processes compared to traditional indoor warehouse processes. Also important is that the size of the warehouses varies a lot. The model that is efficient in a big warehouse won't necessarily be the same in a small-size warehouse.
In some of our markets, there are big needs for different kinds of special packing and delivery services. Other markets may have the opposite situation or at least can have different kinds of services required. Building cost-efficient processes that are supported by a WMS system is not easy in such a situation.
It is very important is to get "buy-in" and commitment from the whole logistics organization. This takes a long time, and implementing new processes is a big effort. The challenge was to justify additional work for the warehouses to gain better customer service and transportation management. Packing items correctly and updating LPNs with exact information is clearly some additional work for the warehouse. It required a lot of change management to prove that what we are doing is worthwhile and is our way forward
This is much different than customizing EBS application forms, as Java coding is needed. Finding the right partner for this work was the most important step.
When doing any customization, it is necessary to think about how to manage support and how much effort is required for future maintenance. This is especially important when doing transactional customizations, which was the case in most of the customizations in our scenario. Also, there is always extra work when doing patching, especially with Rollup Patches (RUPs) and version upgrades; every time, there is a risk of impact to customizations, and this requires additional evaluation and testing. We have already been required to modify our MSCA customizations because of Oracle patching or upgrades.
Having correct item master data as weights and volumes is very important. At the starting point, this information was not at a reliable level. Measuring all items is demanding work and needs coordination and resources. It was also important to harmonize container item usage across warehouses to minimize maintenance work.
Jukka Pelkonen is the lead concept owner in Supply Chain and Offering at Uponor and is located in Finland. He has more than 13 years' experience with Oracle EBS, including playing a major role in 18 different rollout or upgrade projects across Europe.