Infosys’ blog on industry solutions, trends, business process transformation and global implementation in Oracle.

« September 2016 | Main | December 2016 »

November 29, 2016

Minimizing multi-tier transportation costs with smart network routing

Oracle Transportation Management (OTM) is designed to support both shippers and logistics service providers (LSPs). In fact, OTM can be configured to manage all transportation activities in the global supply chain. It integrates transportation planning and execution, freight payment, and business process automation through a single application across all modes of transportation -- road, air, ocean, and rail shipments.

OTM's integrated option--Oracle Transportation Operational Planning--supports all transportation operations, including inbound, outbound, simple point-to-point, complex multi-modal, multi-leg, and cross-docking. It also enables us to validate a shipment through an optimized route.

Network routing is an additional enhancement in OTM version 6.3 through which the shipping cost can be reduced. It also maximizes consolidation opportunities by routing orders from different origins to destinations through a network. Network routing is a new approach to model multi-tier transportation networks. The network routing logic of OTM is a solution for different multi-leg journey problems.

When is network routing recommended?

A network is a combination of locations that represents possible routes for order transportation from a source to destination. Network routing allows multiple cross-dock facilities and also consolidation of orders when appropriate. The flow of orders through a particular network can be determined by many factors like cost of the route, time constraint of an order, equipment constraints if any, and consolidation opportunities available. Network routing can be the best solution when:

  •        The order which is being transported from a source to a destination, may require multiple shipments through intermediate locations
  •         Different choices for intermediate locations are available between a source and destination
  •         Decisions related to routing are taken at the time of planning
  •         Order volumes can impact the routing choice

In network routing the orders flow from a source to a destination via cross docks. Every region will have a representative location. Itineraries and rates need to be created for each leg in a network. An itinerary can have multiple legs and each leg can form a network. When there is a network on the itinerary leg, the network leg substitutes for the itinerary leg.

Let's take an example of orders flowing from one source region to destination via cross dock,

Source region

Xdock

Destination region

Gujarat

Nagpur

Hyderabad

Karnataka

Rajasthan

Indore

 

Within the source region, multiple locations have to be created and each location should be a part of a network leg for the network routing to work efficiently. The routing should be decided based on cost effectiveness, route availability that accounts for order routing constraints, and time constraints on orders if any. Each location will have either ship-from / ship-to / cross-dock roles.

Let's see the locations within the regions and how the network legs are formed. In the below table we can see different regions and the locations from those source / destination regions which are acting as Ship from / ship to or xdock roles and how the network will be designed.

Region ID

Location ID

Roles

Gujarat

Anand

Ship from / ship to

Surat

Ship from / ship to

Ahmedabad

Ship from / ship to, x dock

Rajasthan

Udaipur

Ship from / ship to

Bikaner

Ship from / ship to

Jaipur

Ship from / ship to, x dock

 

Nagpur

X dock

 

Indore

X dock

 

Hyderabad

X dock

Karnataka

Mysore

Ship from / ship to

Hubli

Ship from / ship to

Bengaluru

Ship from / ship to, x dock

 

The orders and their transportation legs would be similar to the below:

Order 1

From manufacturer in Anand to consumer in Mysore

Order 2

From factory in Surat to showroom in Hubli

Order 3

From warehouse in Ahmedabad to retailer in Bengaluru

Order 4

From manufacturer in Udaipur to consumer in Bengaluru

Order 5

From factory in Bikaner to showroom in Mysore

Order 6

From warehouse in Jaipur to retailer in Bengaluru

 

Thus, in the above flow of orders from source to destination region, Oracle's network routing can dynamically make an intelligent decision on when it is ideal to go directly from Ahmedabad to Bengaluru and when it should be routed via cross-dock. If a freight is already scheduled via cross-dock and to the same destination, then it would be a free ride in that case.

Let me elaborate this with the following examples:

  •      There are three orders--one is from Anand to Mysore, another from Surat to Hubli, and a third one from Ahmedabad to Bengaluru. These orders can be transported in the same route through cross- dock and the locations can be added to a single region as an efficient way of transportation planning
  •      Thus, Anand, Surat, and Ahmedabad will be configured as locations under the region of Gujarat with Ahmedabad as the cross-dock for the source location (Gujarat). And Mysore, Hubli, and Bengaluru will be under the region of Karnataka with Bengaluru as the cross-dock location for the destination (Karnataka). Similarly, for the order which should be transported from Udaipur, Bikaner and Jaipur will be the locations configured under Rajasthan region
  •       Now, for the order to flow from Gujarat to Karnataka and from Rajasthan to Karnataka; Nagpur, Indore, and Hyderabad will be taken as the three cross-dock locations
  •     So, if the itinerary leg links to a network, then OTM will use the network which has been configured for bulk planning, provided the appropriate planning parameter has also been configured

The network routing feature in OTM has many more features, which makes it the ideal option to model multiple pathways in a very simple manner. This modeling of routing also provides greater flexibility in the approach and design of networks. By making simple changes in the design of the network, any variations in operation can be accommodated as well. Thus, network routing is set to offer huge optimization benefits in OTM's routing process.

To know more, please attend our session on Network Routing at OTM SIG 2016 APAC Conference (Singapore) and we will be overwhelmed to take you through our solutions.

                                                    Written by: Julie Jose

November 10, 2016

Supply chain visibility

OTM
Oracle Transportation Management (OTM) has provided companies the flexibility to manage all transportation related activities across supply chains on one platform. Apart from minimizing costs, optimizing service levels and providing flexible models of business process automation within their logistics networks, OTM also helps organizations in mapping their highly complex business requirements from logistics domain.

What is supply chain visibility (SCV) and what role does it play in OTM?
Supply chain visibility (SCV) is the ability of parts, components, or products in transit to be tracked from the manufacturer to their final destination. SCV's major focus is to improve and strengthen the supply chain by making data readily available to all investors - including the customer - and enabling transparency and a greater understanding of product movement and overall performance. SCV monitors and controls logistics processes more effectively by reducing inventory levels with real-time monitoring of inventory and management capabilities.

Key elements of SCV
Production
Supply
Inventory
Transportation

Production: Strategic decisions regarding production focus on customer preferences as well as demand in the market. They also analyze the type and quantity of products to be manufactured and the parts or components that should be produced, and whether they should be produced at a particular plant or outsourced to a capable supplier. They must also keep in mind production quality and the capacity of the goods to be produced that will ultimately have to meet the expectations of the customer and the market. 

Supply: An organization must select a supplier that provides the best raw materials at the best possible price. Organizations should also determine what goods their facility / facilities are able to produce both economically and efficiently so that they can maintain the availability of stocks whenever required in order to support the smooth functioning of the supply chain.
Inventory: Strategic decisions in this area always focus on inventory, particularly stock-in-hand. In SCV, this aspect is a very critical issue and determining the optimal level of stock at each location is vital in ensuring customer satisfaction as demand fluctuates.

Transportation: OTM is the world's leading transport management tool providing planning and execution solution for shippers and third-party logistics providers. A single application integrates and channelizes shipment planning, execution, freight settlement, and business process automation. OTM can be implemented for varied modes of transport, ranging from full truckloads to complex multi-leg combinations of air, rail and sea shipments. As a consequence, this tool substantially brings down transportation costs, leads to an improvement in customer service and asset utilization, and helps in delivering the benefits of a flexible solution.

Objective of SCV 
Maintaining the reliability of the supply chain is critical in ensuring that a high demand for goods percolates through at all times, as in today's competitive world, meeting deadlines and achieving customer satisfaction is of utmost importance.

Business challenges of SCV
The execution phase poses formidable challenges in terms of the entire plan. Key challenges such as order modification, shipment damage, unfavorable weather, production backlog, and similar unexpected events culminates into 'delayed shipments' and leads to serious 'supply chain issues' regardless of how robust the initial plan was. Thus, organizations constantly strive to achieve real-time tracking of their goods within the supply chain. Real-time monitoring of Goods-in-transit provides companies opportunities of identifying pertinent problems and arrive at mitigation plans for reducing their impact.
Event management through visibility: Service-level agreements (SLAs) are specified for each lane which varies from one another. These SLAs need to be monitored so that, if and when any SLA is not met, a notification is sent to the Service Provider. In order to meet this requirement, a milestone monitor is setup and configured.
The entire lifecycle of orders and shipments is managed proactively by SCV through automated milestone monitoring. When pickup confirmations have not been received within a specified tolerance interval, SCV automatically accelerates shipments and status updates are received from transportation service providers using multiple communication formats such as web, XML, or mobile telephony.

OTM and its contribution to SCV
OTM in its recent versions have helped a great deal in improving the logistics business and streamlining order fulfillment and procurement to bring down production costs and lead times. In the coming years, OTM is poised to play a significant role in determining future of logistics enterprises. Improving visibility all throughout the supply chain and removing wastages/bottlenecks shall be the key tenets of implementing OTM solution. These functionalities shall undoubtedly lead to higher levels of efficiency and effectiveness across supply chains, thus meeting the ever increasing expectations of tech savvy customers who want their orders delivered in the fastest manner possible at an optimized cost.
In a nutshell, OTM and its upgraded version have largely emphasized on:
Increasing  supply chain visibility with carrier and trading partner communications
Improving operations and network performance with embedded analytics
Reducing freight costs and increasing profit margins
Increasing customer service and supply chain reliability
Reducing supply chain and compliance risk worldwide
Outsourcing transportation, production, and warehousing that has increased unexpectedly, meeting all the challenges of SCV
To know more, please meet us at the Infosys Booth during the OTM SIG APAC 2016 Conference (Singapore) and we will be delighted to showcase our solutions.
Written by: Rachana Singh

Optimization overdrive

Eventually, every business must optimize its processes. Every organization has goals - be it improving revenues, increasing its customer base, or even sustaining itself in a competitive environment. Organizations incentivize their employees to achieve their annual goals and it often works out very well. But in certain cases, such as the logistics industry, where multiple organizations collaborate and compete at the same time, and where forward integration is always looming right around the corner, the simplified focus of improving profits year-on-year may not be the best approach.

Forward Integration is ruthlessly executed by Freight Forwarders and Custom Brokers whereby they add a long list of logistics services to their portfolio, eroding the customer base from existing logistics players in the market.

An order placed by the end customer is typically subjected to multiple iterations of optimization by the manufacturer, carrier, third-party logistics (3PL) service provider, freight forwarder, etc. This article presents the downside of optimization in the logistics industry, in favor of a single meta-optimization.

Retailer's perspective

Can companies collaborate to optimize total supply chain costs? Can a company forego its immediate margins for a sustainable future?

Let us consider a supermarket in a country like Australia where land-based transportation is ubiquitous. This supermarket has its own fleet but primarily depends on 3PL service providers for most of its transportation needs. This supermarket, like most players in this segment, thrives on stocking fresh consumables and moving the items off the shelves in the quickest manner possible. To ensure this, two things need to happen:

  1.        The fresh food products need to be delivered from the vendors to the supermarkets as quickly and as efficiently as possible. Any delays from the day the food was made available by the vendor to the day it arrives in the supermarket can have significant repercussions
  2.       For the retailers, buying 3PL's transportation services should be beneficial in the long run over using their own fleet

Its transportation management system enables the supermarket to place orders, optimize, track the movement of goods, and so forth. Goods move from the vendor's location to the distribution center. This comprises the first leg of the movement. Here, workers reassemble the cartons / pallets into smaller trucks to deliver goods to all the supermarkets in a particular zone. This second leg is usually executed in the form of a multi-stop model.

It may not be obvious at first, but it is really challenging to optimize costs on first leg movement because transportation is carried out by a 3PL. This 3PL consolidates all the orders they receive from multiple customers (supermarkets, manufacturers, and other retailers) in a way that is beneficial to them. The 3PL users initiate their load plans / shipments on top of whatever optimization was already made at the customer's site.

So, for instance, the supermarket in question has a 100 orders on a given day, which are to be picked up from 10 pickup locations and be delivered to their DC within three days. The supermarket's TMS takes these 100 orders and optimizes them based on:

  1.         The distance between pickup locations
  2.       The requested delivery date of individual orders
  3.       The truck capacity in the available lanes

Based on these factors, the supermarket's TMS arrives at say, four load plans / shipments. These are transmitted via Electronic Data Interchange (EDI) to the 3PL's TMS system.

The 3PL TMS system receives multiple load plans / shipments from multiple customers. This system also receives unplanned orders placed by smaller customers who don't have their own TMS systems yet.

The 3PL TMS performs an additional consolidation. It considers the very same factors that the upstream TMS has already considered, thereby disputing the original plans. The following scenarios are then possible:

  1.         The original load plan / shipment received from the upstream system considers a capacity limit of, say 4000 cubic meters, in a certain lane and the volume utilization achieved was around 82 percent. The downstream TMS can achieve a better volume utilization by upgrading a smaller truck to a larger truck and consolidating several other orders / shipments, effectively achieving a volume utilization of 98 percent. Of course, this is subject to slight changes to the original plan received from the supermarket
  2.      3PLs make the delivery to the doorstep, however, the supermarket only negotiates for the delivery to be made to their DCs. After the picking and packing is done, the supermarket has to buy the 3PL services a second time for the second leg of the movement. Instead of two shipments for the same order, a 3PL can make one delivery for a single price, thereby reducing the cost

3PL's perspective

Let us consider a 3PL in the same region as above. They would have their own fleet but a majority of their business operations are based on established contracts with multiple carriers. Some carriers specialize in providing line haul services between states while other carriers are more focused on regional deliveries.

A 3PL's buying behavior could be best described as follows:

  1.       Buy the whole truckload (TL) space if it is between major cities like Sydney and Melbourne, Perth and Brisbane, etc. This is because volumes are high and relatively stable, albeit subject to seasonality issues from time to time. Additional expenses such as fuel surcharge and accessorial costs are levied on the whole truck. Individual cartons, pallets, and consignments that make up the truck do not influence the cost of a TL. The 3PL has to make sure they maintain healthy volume utilizations on these trucks. The profit and margin that the 3PL makes on each carton / pallet / consignment is directly proportional to the truck's volume / weight utilizations. So, hiring a full truckload is only practiced on lanes where the 3PL has huge volumes
  2.      Buy less than truckload (LTL): This contract is based on the consignment's volume, weight, or other dimensions. The carrier would levy an additional fuel surcharge on each consignment. The total truck's utilization does not influence the profit and margin the 3PL makes on each carton / pallet / consignment. This is adopted for home deliveries where the customer is more than happy to upgrade to an 'expedited' service or an 'air overnight' service in place of a 'general' service. It is also useful in return deliveries where products purchased earlier are being returned to the manufacturer such as when a mobile phone that is ordered online arrives home with a manufacturing defect. If it is left to the 3PL, they would choose to negotiate only LTL rates for these and many other scenarios within the city limits. But some carriers that operate in remote locations demand fresh contracts that are neither TL nor LTL
  3.      Hourly hire: Here, carrier charges are truck-agnostic, so to speak. The 3PL will be charged only after the consignment is delivered to the recipient. It is at this point that the number of hours spent in delivering the consignment are recorded and relayed back to the 3PL. Most of this is automated; for instance, the driver of the truck opens up an app to get the recipient's signature. This app records the milestone achieved (proof of delivery) and electronically submits it to the 3PL. Since all the milestones are tracked, the 3PL's TMS can ascertain the number of hours spent on the job

Let us look at 3PLs in Australia. The 3PL's TMS receives thousands of orders every day. These orders are planned based on fixed routes that make use of their depot locations across the country. The depot locations serve as cross-dock facilities for line haul movements, typically carried out by TL carriers. Optimization is ruled out in line haul scenarios owing to the way contracts are negotiated with these carriers. The first mile and last mile carriers usually charge the 3PL based on each consignment's weight and volume.

With this in mind, let us look at their planning / optimization model. On a given day, let us consider that a 1,000 orders were placed by different customers, with each order also bearing a carrier and service nominated on them. The nominated service is used by the 3PL as a reference point for charging their customers. The 3PL's TMS can only optimize the first leg movement and the line haul movement. The last mile cannot be optimized because the customer has already nominated a carrier and the service.

Since the last mile cannot be optimized, the 3PL creates a load plan / shipment based on the requested delivery date (RDD) alone. So, the TMS segments all available orders and delegates different shipments based on what has to be delivered in N days, N+1 days, N+2 days, etc.

It is not the most efficient of planning scenarios. These load plans are then electronically submitted to the last mile carrier. The last mile carrier takes these shipments and consolidates them with other shipments / orders that it receives from other customers. So the downstream carrier's TMS essentially discards the planning that was performed in the upstream 3PL's TMS system.

In this case, the following scenarios are possible:

  1.        The 3PL's TMS creates three shipments to be delivered today, tomorrow, and the day after tomorrow respectively. These shipments have the earliest start time of yesterday, today, and tomorrow respectively.  When the carrier receives these shipments, and their TMS looks up available trucks to optimize, it is limited due to the time window sanctions imposed by the 3PL's TMS system
  2.      The carriers can benefit by maximizing their volume utilization. Ideally, a carrier should be allowed to switch between small and large trucks based on the delivery time windows of the original orders. But the original orders and the original time windows are not visible to the carrier. The carrier's TMS is fed processed data from the 3PL's system

Residual cargo carrier's perspective

Containerization has evolved from a novel idea to a global phenomenon over the last century. Container freight stations may be owned by carriers, the government, or a third party warehousing player. When it comes to ports, the port authority of that country plays a crucial role in determining the inbound and outbound volumes.

In the international movement of goods, the sea ports, the respective container freight station (CFS) locations, the availability of residual cargo carriers, and the distance between them influences the extent of optimization. For instance, a shipment from Shanghai to New York can be achieved in:

  1. A single-leg voyage all the way from the port of loading to the port of discharge
  2. Multi-leg voyage with the first cross-docking at Singapore and onwards

Ships usually have dedicated routes with the vessel schedules being fixed. There are simply far too many documents to fill out at each port and the volumes are just too high to be able to carry out a multi-pickup or a multi-delivery mode of transportation. There are also cutoff times for goods to arrive at all the ports, beyond which goods may not be considered for documentation purposes. For these reasons, all ocean-based modes are direct shipments, from port to port.

Let us consider the CFS in Singapore. Singapore is a cross-dock facility for many carriers. For instance, if a retailer in North America is planning to stock the goods before Christmas, they may place their orders with their supplier in Shanghai as follows:

  1.         Male garments with a delivery time window of four months
  2.       Female and kids garments with a delivery time window of three months
  3.       All footwear with a delivery time window of three months
  4.       Promotional products with a delivery time window of one month (so that the products can be displayed months before release)

Now, let us add similar orders with similar time windows from Beijing to a Latin American retailer to this mix.

Since the routes are fixed between Shanghai and North America, and between Beijing and Latin America, the only scope for optimization is in cross-docking at the CFS in Singapore. When the carrier's TMS receives the orders listed above, they would be consolidated with other orders into 20FT or 40FT containers on the next outbound vessels from the respective ports. Of course, the urgency of sending an order outbound depends on the requested delivery dates by the customer. Having said that, the first leg movement's objective would be container capacity utilization. If there is an outbound vessel that can carry about 80 percent of all the orders placed, they will be shipped right away, without considering the delivery dates. These shipments would reach Singapore and hibernate in the CFS based on the urgency, as dictated by the delivery time windows.

When the next vessel is scheduled to leave after, say a month, the residual cargo from earlier orders would be shipped in it. But if all the shipments can only make up to 10 percent of the ship's capacity, the original carrier would outsource it to another carrier. This outsourced carrier would take all such residual cargoes and reach the Singapore CFS where the goods are deconsolidated to be warehoused / shipped for the future.

Herein lies the problem. The original cargo carrier would have his own dedicated ships and would try to optimize in order to achieve the highest container utilization. So, the original carrier would wait until a cutoff time in order to give himself a decent chance at accumulating multiple orders into a single vessel. After the said cutoff time, the original carrier would make the decision, either to ship it himself or to outsource. During this time, the residual cargo carrier is also giving himself a decent chance to consolidate shipments.

Thus, the following scenarios are possible:

  1.        The residual cargo carrier has enough shipments with him to load the next vessel before the original cargo carrier can place his outsource orders. Now, the original carrier has to wait for the next vessel, and if it proves to be too late, he may have to consider an aerial route
  2.       The residual cargo carrier commits to a vessel schedule but does not have enough shipments to load on board

Conclusion

This brings us to the question of seamless optimization. Can the logistics industry evolve to overcome the above predicaments? Can multiple TMS systems interact and collaborate to benefit everyone involved? Can upstream and downstream systems intelligently predict the optimization of each other, without having to work in isolation?

In the case of the retailer in Australia, instead of committing to load plans / shipments created in their TMS system, they could submit a draft of their shipment plans to the downstream TMS. The downstream TMS can run a consolidation plan on all the draft shipment plans received from multiple customers. After a certain period of time, profit, margin, and other key performance indicators (KPI) can be compared between consolidation plans executed on draft shipments and the same plans executed on committed shipments for better planning.

In the case of the 3PL, instead of sharing the processed shipment plans with the carrier, raw orders can be submitted to the carrier. The carrier can run a draft iteration of optimization on the orders received from the 3PL for a given month and submit the draft shipment plans back to the 3PL. The 3PL can review this output. The original orders usually drop in with constraints such as their compatibility with other stock keeping units (SKU), whether to refrigerate, to be handled carefully for fragility, etc. The original orders also have the delivery time window, nominated carrier, and type of service specified on them. If the carrier's submission of the draft optimization satisfies all these conditions, the 3PL can accept the draft shipments or make amends to these draft shipments before finalizing. Initially, this may have to be handled by transportation managers from either side. But as the interface evolves, the carrier's TMS can be made intelligent to track the acceptance ratio of all the draft plans that it submits to a certain 3PL. These acceptance indicators can be used in predicting the acceptance from the upstream or downstream TMS', and adjusting the plans accordingly to gain better acceptance and so forth.

The residual cargo player can request submissions from all the original carriers in the area. A constant feed of all the residual cargoes can be submitted via an automated interface between all the carriers. The residual cargo carrier can execute an iteration of optimization at the end of every day to verify container capacity utilizations. The system can track the percentage of utilization of containers and the next outbound vessel. A notification can be sent to all the carriers once the residual cargo carrier's iteration yield exceeds a certain percentage. This will enable all the original carriers in the area to plan and execute their shipments in a much more efficient manner.

TMS systems working in isolation are inferior to TMS systems collaborating, thereby achieving an all-encompassing system. An omniscient TMS system like this can iron out inconsistencies over a period of time, rule out uncertainties, and may even prove to be resilient in times of unforgiving global economic changes.

To know more on optimizing logistics, please meet us at the Infosys Booth during the OTM SIG APAC 2016 Conference (Singapore) and we shall be delighted to showcase our solutions.

Written by: Kranthi Sagar Askani

November 4, 2016

Have you planned the testing of custom reports in your Upgrade Project?

In most organizations, there are custom reports designed in ERP to satisfy the reporting needs of business. Often, these custom reports are very similar to the standard out-of-the-box report with minor tweaks as per the business need. These tweaks can be the addition of a few extra columns, formatting changes, sorting changes, removal of unnecessary columns, and some additional calculations required for analysis and decision making. Sometimes, these tweaks are performed using the standard report design / logic.

When an upgrade is performed, custom reports need to be carefully tested for remediation and changes. For custom report testing, the below six-point strategy should be followed:

  1. Testing of reports for data before upgrade - To perform the testing of reports for data before the upgrade, one test instance of the existing production application should be built using the same data backup as of the upgraded test instance. Now the reports should be executed in the upgraded test instance (with remediated code) and the test instance of the existing version (with existing production code version).  Both the report outputs should be matched for same parameters. If the report outputs do not match, then that indicates an issue with the extraction of data before the upgrade. If the report outputs match, then it signals that the remediated code can provide reports as before. It should be ensured that this testing is performed before any data entry in both instances (i.e. upgraded instance and existing version instance). This will ensure that data in both instances are same and if there is any mismatch in report output, then it is an issue which needs to be fixed.

  2. Testing of reports for data after upgrade - To perform the testing of reports for data after the upgrade, new transactions should be entered in the upgraded test instance. After entering new transactions, the report should be executed, and its output should be thoroughly reviewed. It should be ensured that the report output is tested for all possible test cases and not only just data entry, for example, in a custom report related to payable invoice, the report output should be tested not only for a standard, but various types of invoices and statuses. For the post-upgrade data, testing should be planned along with transaction entry testing so that data created in transaction entry testing can be re-used for report testing.

  3. Report format - Post-upgrade report format should be verified with pre-upgrade report format. This verification will ensure that there is no formatting issue due to upgrades / changes / code remediation. This testing should be performed along with the testing of data before upgrade. With this approach, efforts for format testing will be reduced.

  4. Testing of data which was partially processed before upgrade - Report output should be tested with the processing of transactions which were initiated before upgrade. For example, in a custom report of payable trial balance, report output should be tested with those invoices which were created before the upgrade but are paid after the upgrade. This testing will ensure that partially processed data is shown correctly in reports.

  5. Report parameter - Report parameters should be tested thoroughly. Many times standard value set are used for a list of values in report parameters. When the upgrade is performed, then these values may get modified in new release. Also, when there is a custom value set which is table-based and if the table is obsolete in upgraded version, then that value set needs to be remediated. For any such items, the parameters of the report should be thoroughly tested.

  6. Report execution after go-live - A lot of reports are part of the standard period close package. These reports are executed only during and after the period close. After the upgrade, these reports should be executed before approaching period end. Alternatively, a mock period close is suggested to identify issues before approaching period end. This will ensure that if there is any issue in reports, then it is identified a lot early before approaching period end and can be fixed. With this, the period close timelines will not be affected adversely.

    In summary, it can be said that a good test strategy should contain detail section / plan for report testing to make the upgrade project successful.




Subscribe to this blog's feed

Follow us on

Blogger Profiles

Infosys on Twitter