Abstract: A method, system and program product for providing supply and demand planning including backwards order item allocation is disclosed. In one embodiment, the invention includes a method for supply and demand planning in an enterprise including: identifying an order item occurring at a prospective period that exceeds an enterprise build plan for the prospective period; and allocating at least a portion of the order item back to a supplier forecast for at least one period prior to the prospective period.

Abstract: Methods, systems and apparatus for exhausting surplus inventory within currently existing supplies. Intra-enterprise and inter-enterprise lists of surplus inventories are input into a planning engine along with allocation rules for establishing priorities and preferences of allocating and exhausting parts within existing inventories. The planning engine also receives central parameter file inputs for identifying those parts within surplus inventory that can be allocated to other enterprises. Using an identifier of a requested part, the planning engine then analyzes the lists of surplus inventories for compatible parts, and builds hierarchy allocation plans using selected inputs dependent upon which list the compatible parts are located. These hierarchy allocation plans are output in tables for allowing a user to select a plan that exhausts surplus inventory prior to such inventory being declared as excess.

Abstract: Method, system and program product for providing supply and demand planning by omitting an atypical order item is disclosed. In one embodiment, the invention includes a method of identifying an atypical order item, and omitting the atypical order item from at least one of the following: a forecast demand and an order item demand.

Abstract: Methods, systems and apparatus for determining a current state of an order book for order request reconciliation. A customer inputs an order request for a desired quantity of items to be shipped to a recipient into the system. A supplier inputs a shipment quantity of any such previously shipped items into an input table, while a recipient inputs into another table a receipt quantity of any such received items. These input shipment and receipt quantities are then transmitted to a reconciliation program of the system for determining an in-transit quantity that is used along with the receipt quantity to generate an updated, current state of the order book. This current state of the order book substantially avoids any over-shipments, under-shipments and unwanted inventory returns. A Materials Requirement Planning component then generates an order book reconciliation output table for viewing by users using the current state of the order book.

Abstract: A method, system, and computer program product for performing inventory management. The method includes determining excess inventory for a plurality of site locations, determining inventory shortfalls for a plurality of site locations, and applying business logic to the excess inventory resulting in an inventory balancing plan. The inventory balancing plan includes optimal redistribution of excess inventory to site locations determined to be in need of the excess inventory. The method also includes generating and transmitting orders for the excess inventory in accordance with the inventory balancing plan prior to developing a supplier forecast.

Abstract: The inventive lightweight occurrence model uses a folded connectivity model which includes occurrence nodes. Each occurrence node includes occurrence specific data or a pointer to such data, a pointer to a parent occurrence node, and a pointer to a folded model describer. Thus, the information that would present in a full occurrence model can be included in the inventive lightweight occurrence model. The inventive model does not maintain duplicate information and requires less memory to store the inventive model. Since the inventive occurrence model is smaller than the full occurrence model, complex circuit designs, e.g. microprocessors, can be represented by the inventive lightweight occurrence model. Thus, low level characteristics of the design, e.g., timing delays, can be examined.

Abstract: The present invention allows traversal of net occurrences of a light weight occurrence model. In traversing down, a port iterator is preferably used, while in traversing up a port instance iterator is preferably used. The selected iterator is initialized with information about the current occurrence net from the inventive occurrence node that describes the occurrence net's owner and folded model describer. In traversing up, the iterator finds the next port that connects to the folded model net indicated by the describer used during initialization. Then, using information stored in the model, the iterator finds the occurrence net object that is one level higher in hierarchy than the original occurrence net object. In traversing down, the iterator finds the next port instance that connects to the folded model net indicated by the describer used during initialization.

Abstract: The present invention allows traversal of net occurrences of a light weight occurrence model. In traversing down, a port iterator is preferably used, while in traversing up a port instance iterator is preferably used. The selected iterator is initialized with information about the current occurrence net from the inventive occurrence node that describes the occurrence net's owner and folded model describer. In traversing up, the iterator finds the next port that connects to the folded model net indicated by the describer used during initialization. Then, using information stored in the model, the iterator finds the occurrence net object that is one level higher in hierarchy than the original occurrence net object. In traversing down, the iterator finds the next port instance that connects to the folded model net indicated by the describer used during initialization.

Abstract: A method and system are disclosed for creating and using a generic container as a data structure used in a software program. A selected data structure may be specified at start-up time or run-time using a mapping table that tracks the specified data structures for each generic container used by the program. Existing data structures are abstracted to a generic interface for use with the container. The program interacts with the generic container using the generic interface, which allows the container to add, delete, and look up data stored in the container and to retrieve a key used by the container. A program uses an object factory to create an instance of a generic container having the generic interface. At run-time, the object factory refers to the mapping table to determine which specific data structure is used for each generic container.