Oracle Warehouse Management System (WMS) is advanced inventory module with lot of unique features that improves productivity of distribution centers, manufacturing or inventory handling facilities. Oracle WMS supports manual data entry, bar code readers scanning for data entry as well as Radio Frequency Identification (RFID) scanning. WMS can be enabled at Inventory organization level.

Key business processes supported by Oracle WMS:

• Inbound Logistics (Receiving, supplier returns, corrections)
• Stocking and internal inventory movements
• WIP Job assembly completion, component issues
• Outbound Logistics (pickimg, packing, shipping)
• Reverse logistics (customer returns)

License Plate Numbers (LPN) LPN is an object carries the location where it is residing and items that are holding. LPN need not be a physical object, it could be logical grouping. LPN simpley a group of items represented systematically. The major advantage of LPN is less number of transactions. Entire LPN can be transacted at once instead of by each line that LPN holds.

Material Status This is one of the beautiful features of WMS, you can assign status to an item, lot or serial number. Each status is defined with a list of permissble transactions. Eg. if you have status called ‘No Sale’ and set the rules such that shipping is not allowed but all other internal inventory movements are allowed. Material status can enforce this kind of business rules.

Label printing WMS partially supports this fucntionality. You can define label formats and fields (data) needed, you can associate this with WMS rules to print the label automatically. WMS can generate xml output, but you need a 3rd party label printing/formatting tool to actually print.

Cost groups This is another major functionality offered by WMS module. In standard Inventory module Inventory valuation accounts are derived by subinventory setups. In WMS based on cost group rules you can have different valuations independent of subinventories.

Putaway Rules When a matrial is received you need to receive into stock. In a major distribution center it is often complex to know where to store the material. WMS offers putaway rules that can be setup based son business criteria. Eg. If all hazarad material categy must be received into hazardous area then putaway rules can be setup.

WMS Rules engine WMS rules engine enforces the rules defined for putaway, cost group or label printing. You can simulate the results based on set of rules defined.

Demantra is a recent acquisition of Oracle, since then Oracle is strategically positioning Demantra in place of Oracle Demand Planning module that was earlier developed by Oracle. 

Demand Management covers forecasting of demand using statistical techniques and sales and operations planning to facilitate consensus demand and supply planning. Demand Management consist of three modules that can be licensed and implemented separately.

• Demand Management (DM)
• Advanced Forecasting & Demand Modeling (AFDM)
• Real-Time Sales and Operations Planning (RTSOP)

Demantra Demand Management Demand management helps in understanding historical demand and predicting the future demand. Demand management cycle consists of

• Collecting historical data
• Generating forecast
• Review and approve forecast
• Publish the forecast
• Analyze the forecast accuracy

Demantra Advanced Forecasting & Demand Modeling This is extended module for demantra demand management. It supports six more forecasting methods listed below

• Auto and Linear Regression (ARIX)
• Auto Regressive Logistic (ARLOGISTIC)
• Dual Multiplicative Linear Regression (DMULT)
• Multiplicative Monte Carlo Regression for Intermittent
• Multiplicative Monte Carlo Regression for Logistic (LOGISTIC)
• Multiplicative Monte Carlo Regression for Modified Ridge Regression (MRIDGE)

Demantra Real-Time Sales & Operations Planning Sales and Operations Planning brings different functions to collaborate in business demand and supply and operational planning. It consists of four critical steps

• Demand Review
• Supply Review
• Finance Review
• Executive Review

To implement this functionality, we would have to know the following:

1. The concurrent request id of the program that is tied to an xml publisher defined layout
2. The path and name of the output file that is generated by the output post processor for the concurrent request
3. An email utility that can mail the generated output as an attachment

It is quite obvious for us to know from where to pick up the request id. It would be interesting to know the name of the file and the path where the xml publisher generated output is stored.

Let us assume that we have a concurrent request that is tied to an xml publisher layout which will format the output to a PDF document. When the concurrent request completes its run, it generates 2 output files in this case. The first file is the xml data file and the second file is the pdf file. Both the files get generated and stored in the usual $APPLCSF/$APPLOUT path.

What is of interest here is the file name given to the pdf file. This file name looks to be a combination of the XML publisher definition code, the request id and a running number. How do we get to know this filename from within oracle?

There is a table named FND_CONC_REQ_OUTPUTS that stores the request id, dir path and the file name, filesize and so on. This is the table that we use to read the file name from after looking it up with a particular request id. Once this is done, we are all set to email the file as an attachment. How do we do it from within oracle?

Oracle provides us with a PL/SQL wrapper named SendMailJPkg for its internal java mail utility that is loaded into the database. We can use this to send the email and the contents of the pdf file as an attachment. The utility has a method named SendMail. This method has a list of parameters which are pretty straightforward to lookup and understand. The last parameter is a pl/sql table named attachments. We can send multiple attachments using this pl/sql table type parameter. In our case, to send the pdf as an attachment, we would simply have to instantiate one element in the pl/sql table and pass the file name including the path as a value to the element. Set all the other appropriate param values and call the method. The pdf file would land up nicely in the user's inbox.

Oracle WIP module facilitates in creating WIP job or work order to manufacture the goods. Oracle WIP supports discrete, repetitive, project and assemble-to-order (ATO) type of work orders.

Non-standard WIP Job When the material and resources needed to manufacture is not pre-determined or pre-calculated then non-standard WIP job can facilitate issuing material and resources as needed. Prototype manufacturing is a good example to this.

WIP Accounting Classes Accounting class is a setup that have pre-defined list of valuation and variance accounts. Each discrete job is assigned with a accounting class.

Out-Side-Processing (OSP) With more and more industries are moving towards Outsourcing or contract manufacturing, ERP systems should have functionality to send goods out and receive back after performing certain operations. Oracle WIP module have Out side processing (OSP) functionality to support this.

Work Order Less Completion (WOLC) This is an alternative to standard discrete job. In this method on-hand can be increased by performing WOLC transaction instead of creating a WIP Job. This functionality will be very useful if you are using other legacy system as your shop floor manufacturing tool and WIP is used for inventory tracking purpose.

Backflushing When you manufacture a job or assembly you need to issue material or resources to the job, this can be done in two ways. Manually issuing or automatically backflushing. Backflushing deducts reduces the onhand of sub components and updates configuration of assembly being manufactured as components issued.

PICK RELEASE    Pick release is an activity to confirm picking of goods from stock and keeping aside for shipping to a sales order. Normally pick release happens based on scheduled ship date on sales order. Pick release process can be done manually or automatically scheduled. Once pick release is activated it normally prints Pick ticket or Pick Slip for warehouse personnel to pick the material. Pickslip displays the information like Item, quantity, location from where it should be picked and destination place where it should be moved (eg. docking station). Pick release doesn’t decrements the onhand inventory but it decrements the available inventory for next picking.

DELIVERY    Delivery is a batch of sales order lines grouped together based on some criteria (criteria could be shipto location, sales order etc). Delivery can be automatically created by system during pick release or it can be manually created.

TRIP    Trip is primarily the shipment routing plan, it has pick up location and drop off location. Most of the cases multiple deliveries can be grouped under a trip.

SHIP CONFIRM    It is an activity where it is confirmed systematically that goods are shipped from the warehouse that finaly reduces the onhand quantity and updates the install base with customer & sales order details.

The TEMPLATE form is the starting point for all development of new forms. The first step in creating a form for use in Oracle Applications is to copy the template form from $AU_TOP/forms/US, to a local directory and renaming it.

The Template form is unique because it contains some special libraries and triggers that render the application using the template form some standard characteristics. 

<< Click the image to enlarge >>

The components of the template form are: 

 References to object groups The template form contains platform–independent references to 
 predefined standard object groups in the APPSTAND form. STANDARD_PC_AND_VA, 
 STANDARD_TOOLBAR, and STANDARD_CALENDAR.

   Libraries The template form contains platform–independent attachments of several libraries 
  (including FNDSQF, APPCORE, and APPDAYPK).

  Special Triggers The template form contains several form–level triggers with required code. 
  These are responsible for standard the behavior of the form.

  Predefined Program Units The template form contains predefined program units that include a 
  spec and a body for the package APP_CUSTOM, which contains default behavior for window 
  opening and closing events.

  Applications Color Palette The template form contains the application color palette. This gives 
  the forms developed using the template form the look and feel of Oracle Applications.

  Many referenced objects (from the object groups) that support the Calendar, the toolbar,  
  alternative regions, and the menu. These objects include LOVs, blocks, parameters, and property 
  classes, and so on.

  The TEMPLATE form contains sample objects that can be seen as examples for the expected 
  layout cosmetics. These samples can be completely removed from the form later as they are only 
  examples and are not required. The following objects are the samples and can be removed

Blocks           : BLOCKNAME, DETAILBLOCK

Window         : BLOCKNAME

Canvas View  : BLOCKNAME

Hence, the template form comes along with many attachments, predefined program units, and defined visual attributes as well as examples that not only give the forms that are developed using the template.fmb a standard look and feel, but also make t easier to develop forms with consistent and standard functionality.

Libraries in the Template form

As stated above, the template form contains platform–independent attachments of several libraries. These libraries are used while running the form as a part of Oracle Applications. Hence, these libraries should not be changed or modified. There are three main libraries that are attached to the template form:

<< Click the image to enlarge >>

APPCORE  APPCORE contains the packages and procedures that are responsible for the standard  ‘Oracle Applications’ behavior of the forms. The forms have to support the menu, toolbar, and other required standard behaviors in compliance with oracle applications. The Oracle Applications forms also have to display specific runtime behaviors in accordance with the Oracle Applications Interface Standards, such as the way in which fields are enabled, behaviors of specific types of windows etc. APPCORE contains the procedures to support this standard runtime behavior. APPCORE also contains various other utilities for exceptional handling, message levels, and so on.

APPDAYPK: The APPDAYPK library contains the packages that control the Oracle Applications Calendar feature. The calendar (or the date picker) is a utility that oracle apps provide to pick the dates for a date type field.

FNDSQF: FNDSQF contains packages and procedures for Message Dictionary, flexfields, profiles, and concurrent processing. It also has various other utilities for navigation, multicurrency, WHO, etc.

Other Libraries The template form also contains a few other libraries that are not linked directly to the template form, but are linked to the three libraries listed above. Although, while using the form it makes no difference whether the library is linked directly to template or to another library that is linked to template. These are discussed below.

CUSTOM library: The CUSTOM library (CUSTOM.pll) is probably the most widely used and customized in the libraries attached to the template form. This library allows extension of Oracle Applications forms without modification of Oracle Applications code. Any form goes to the CUSTOM.pll whenever any event fires on the form. Code can be written in the CUSTOM.pll with the logic branching based on the form, block and trigger on which you want it to run. 

We can use the CUSTOM library for customizations such as Zoom (such as moving to another form and querying up specific records), enforcing business rules (for example, vendor name must be in uppercase letters), and disabling fields that do not apply for your site.

GLOBE The GLOBE library allows Oracle application developers to incorporate global or regional features into Oracle Applications forms without modification of the base Oracle Applications form. Oracle Applications sends events to the GLOBE library. Regional code can take effect based on these events. The GLOBE library calls routines in the JA, JE, and JL libraries.

VERT The VERT library allows Oracle Applications developers to incorporate vertical industry features (for automotive, consumer packaged goods, energy, and other industries) into Oracle Applications forms without modification of the base Oracle Applications form. Oracle Applications sends events to the VERT library. Vertical industry code can take effect based on these events. The VERT library calls routines in various other libraries.

JA The JA library contains code specific to the Asia/Pacific region and is called by the GLOBE library.

JE The JE library contains code specific to the EMEA (Europe/ MiddleEast/ Africa) region and is called by the GLOBE library.

JL The JL library contains code specific to the Latin America region and is called by the GLOBE library.