U.S. patent application number 13/736887 was filed with the patent office on 2013-05-16 for food tracing and tracking system and method.
The applicant listed for this patent is Michael Blaha, Gregory R. Clarke, Stephen E. Johnson, Joseph Rajkumar, Paul Sribhibhadh, James M. Thomson, Chatta Udomwongsa. Invention is credited to Michael Blaha, Gregory R. Clarke, Stephen E. Johnson, Joseph Rajkumar, Paul Sribhibhadh, James M. Thomson, Chatta Udomwongsa.
Application Number | 20130124375 13/736887 |
Document ID | / |
Family ID | 29254577 |
Filed Date | 2013-05-16 |
United States Patent
Application |
20130124375 |
Kind Code |
A1 |
Sribhibhadh; Paul ; et
al. |
May 16, 2013 |
FOOD TRACING AND TRACKING SYSTEM AND METHOD
Abstract
A food tracing and tracking system, method, and computer-program
product are provided. The present invention allows companies that
operate within these supply-chains, to exchange information
bi-directionally throughout the entire supply-chain while
maintaining data integrity and appropriate levels of security at
all times and in real-time. The present invention enables a
continuous linkage across the supply-chain-entities and changing of
supply-chain entities in near real-time and ensures data integrity
and data security, performs language translation, maintains a
continuous history over time without the need for data conversion,
and provides each entity within the supply chain the option of
publishing their identity and data to the other supply chain
entities. New fields can be added as needed for processes and
materials. The present invention supports distributed data hosted
on various machines by various organizations over a public or
private data network.
Inventors: |
Sribhibhadh; Paul; (Bangkok,
TH) ; Thomson; James M.; (Bangkok, TH) ;
Rajkumar; Joseph; (Choa Chu Kang, SG) ; Udomwongsa;
Chatta; (Bangkok, TH) ; Clarke; Gregory R.;
(Kailua Kona, HI) ; Johnson; Stephen E.; (San
Francisco, CA) ; Blaha; Michael; (Chesterfield,
MO) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
Sribhibhadh; Paul
Thomson; James M.
Rajkumar; Joseph
Udomwongsa; Chatta
Clarke; Gregory R.
Johnson; Stephen E.
Blaha; Michael |
Bangkok
Bangkok
Choa Chu Kang
Bangkok
Kailua Kona
San Francisco
Chesterfield |
HI
CA
MO |
TH
TH
SG
TH
US
US
US |
|
|
Family ID: |
29254577 |
Appl. No.: |
13/736887 |
Filed: |
January 8, 2013 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
10421630 |
Apr 22, 2003 |
8392225 |
|
|
13736887 |
|
|
|
|
60375202 |
Apr 22, 2002 |
|
|
|
60375192 |
Apr 22, 2002 |
|
|
|
Current U.S.
Class: |
705/28 |
Current CPC
Class: |
G06Q 40/12 20131203;
G06Q 10/087 20130101; G06Q 10/06 20130101; G06Q 40/02 20130101 |
Class at
Publication: |
705/28 |
International
Class: |
G06Q 10/08 20120101
G06Q010/08 |
Claims
1. A supply chain management system comprising: a server including
an application program for performing supply chain management; a
database for storing tables created or read by the application
program, the database being coupled to the server; and a plurality
of computer-based user systems coupled to the server over at least
one of a public or private data network, wherein the application
program includes one or more components from the following list of
components: a first component for storing farming information for a
material lot of a product; a second component for storing quality
information for the material lot of the product; a third component
for storing production information for the material lot of the
product; a fourth component for storing shipping information for
the material lot of the product; and a fifth component for
retrieving information stored by one or more of the first thru
fourth components, wherein the first through fourth components
include fields for entering information to be stored, and wherein
deletion, alteration, and addition of the fields is capable of
being performed in real or near real-time.
2. The system of claim 1, wherein the database is distributed
across the network.
3. The system of claim 1, wherein the application program is
distributed across multiple servers coupled to the network.
4. The system of claim 1, wherein the plurality of computer-based
user systems include at least one of a wireless hand-held
device.
5. The system of claim 1, wherein material lots and processing
stages are defined at run time of the application program within
one or more of the components.
6. The system of claim 1, wherein new processes are defined at run
time of the application program within one or more of the
components.
7. The system of claim 6, wherein at least one of attributes or
relationship types are defined at run time of the application
program within one or more of the components for one or more of the
materials or processing stages.
8. A computer program product residing on a computer-readable
medium for performing supply chain management, the computer program
product comprising one or more components from the following list
of components: a first component for storing farming information
for a material lot of a product; a second component for storing
quality information for the material lot of the product; a third
component for storing production information for the material lot
of the product; a fourth component for storing shipping information
for the material lot of the product; and a fifth component for
retrieving information stored by one or more of the first thru
fourth components, wherein the first thru fourth components include
fields for entering information to be stored, and wherein deletion,
alteration, and addition of the fields is capable of being
performed by an authorized user in real or near real-time.
9. The computer program product of claim 8, wherein the computer
program product is distributed across multiple servers coupled to
the network.
10. The computer program product of claim 8, wherein material lots
and processing stages are defined at run time of the computer
program product within one or more of the components.
11. The computer program product of claim 8, wherein new processes
are defined at run time of the computer program product within one
or more of the components.
12. The computer program product of claim 11, wherein at least one
of attributes or relationship types are defined at run time of the
application program within one or more of the components for one or
more of the materials or processing stages.
13. A system for representing a supply chain that changes over
time, the method comprising: a means for creating any number of
supply chain stages; a means for connecting the created supply
chain stages in parallel or serial order; and a means for nesting
created supply chain stages to any depth.
14. The system of claim 13, wherein information associated with the
supply chain stages are entered at multiple computer systems that
are remote from one another.
15. The system of claim 13, further comprising: a means for
performing adding, changing, and subtracting of data attributes
associated with a supply chain without interfering with other users
interaction with the system.
16. The system of claim 13, further comprising: a means for
performing adding, changing, and subtracting of business processes
and relationships based on new business requirements without
interfering with other users interaction with the system.
Description
PRIORITY CLAIM
[0001] This application is a continuation of U.S. patent
application Ser. No. 10/421,630 filed on Apr. 22, 2003 which claims
priority from Provisional Application Ser. Nos. 60/375,202 and
60/375,192 both of which were filed Apr. 22, 2002 Each of the
foregoing applications are hereby incorporated by reference.
FIELD OF THE INVENTION
[0002] This invention relates generally to supply chain tracing and
tracking and, more specifically, to food tracing and tracking.
BACKGROUND OF THE INVENTION
[0003] The food industry has a relatively low technology
penetration and companies vary widely in their ability to provide
information to their partners in any given supply-chain. This
inability to provide information is compounded by the complex
nature of the supply-chains themselves. The supply chains consist
of a complex maze of sequence and parallelisms that can be
arbitrarily mixed and changed with time as shown in the FIG. 1.
[0004] Many companies (supply-stage legal entities) or a
combination of supply-chain legal entities) require a complex
structure that enables maintenance of the manufacturing processes
across various departments, divisions or even different companies.
Further, when companies are being asked to perform a trace of a
product they fail to be able to provide answers to questions such
as: what is in the container on the ship; how many pallets are
inside the container; how many boxes are inside the pallets; how
many cans are inside the box; what is inside the can; where did the
content come from; how was it grown; what fertilizer was used; what
pesticides were used; when was the seed sown; what type of seed was
used; was the farm next to a power plant; did the farm have
toilets; what manufacturing processes were used, etc.
[0005] Existing business enterprise software and logistics software
vendors such as; SAP, Oracle, 12, People-Soft and Manugistics fail
to be able to accommodate the fact that the food supply-chain will
be in a constant state of flux. The supply-chain entities
continually aim to optimize their resources, reduce their costs,
and increase their efficiencies while still meeting all regulatory
and commercial constraints. In practice, this means that the
supply-chain entities constantly change their suppliers, their
supply-chain processes and stages.
[0006] Because the supply-chain is an environment of constant flux,
the existing systems cannot change during run-time without
affecting the database structure and application code. This means
that no application easily adaptable for defining a new process or
changing on existing process at the same time. In other words, the
present systems create new databases when the primary application
structure is altered. In addition, the present systems fail to
consider the time taken for a product to travel the supply chain
(e.g., farm to table).
[0007] As shown in FIG. 2, traditional enterprise software vendor
(ES) provide software such as Enterprise Resources Planning (ERP),
Material Requirements Planning (MRP) or financial and accounting
software. These types of software applications help companies
manage resources within their own business environment (inside the
box). These types of software are usually very expensive and thus
not all participants within the supply chain can afford them. In
the food industry very few of the manufactures/suppliers have
ERP-type solutions outside the USA and EU markets. Traditional
logistics software vendors provide software for warehouse
management, purchasing and automated inventory replenishment
solutions. These types of software applications are also expensive
and very few companies within the food industry supply-chain can
afford them. They are designed to link between companies that have
installed traditional enterprise software. They do not solve the
problems associated with food safety and traceability.
[0008] Because the supply-chain is an environment of constant flux,
there exists a need to have a structure capable of being changed
during run-time itself without affecting the database structure and
application code. There is a need to be able to define a new
process or change an existing process at the same time. In other
words, the system does not create new databases when the primary
application structure is altered. Also, there exists a need to take
into account the time taken for a product to travel the supply
chain from farm to table.
SUMMARY OF THE INVENTION
[0009] The present invention allows small, medium and large-size
companies that operate within these supply-chains, to exchange
information in near real-time and bi-directionally throughout the
entire supply-chain while maintaining data integrity and
appropriate levels of security at all times. The present invention
performs this by providing a batch-oriented process having any
number of stages connected in any mix of parallel or serial order,
nested to any depth. The present invention can be implemented in
any industry that requires business process set-up and changes,
e.g., food, pharmaceuticals, precious stones, electronic
components, etc.
[0010] Also, the present invention supports continuous processes
that can be approximated by a batch process.
[0011] The present invention enables a continuous linkage across
the supply-chain entities while allowing the configuration or
reconfiguration of the supply-chain entities to be changed, as and
when required, in real or near real-time. The present invention
accomplishes the foregoing while being capable of optionally
providing the following additional features: ensuring data
integrity and data security, maintaining a continuous history over
time without the need for data conversion, and providing each
entity within the supply chain the option of publishing their
identity and data to the other supply chain entities. New fields
can be added as needed for processes and materials. The present
invention supports distributed data hosted on various machines by
various organizations over a public or private data network.
[0012] The present invention provides the ability to create any
processes that are sequential or parallel, plus is able to change
these dynamically (i.e., at run time). The present invention allows
for manipulation at run time of a directed graph. The directed
graph includes nodes that are connected by arcs from a source node
to a target node. The nodes are supply chain stages and the arcs
are material lots that enter and exit the supply chain stages. The
present invention permits both the definition of a process and the
instantiation of a process to be defined at run time. Furthermore,
the present invention can readily customize the processing for the
particular needs of a company. The present invention can track the
evolution of a food process for a particular company.
[0013] The present invention provides a food traceability
application with advances from conventional database modeling. The
food traceability application includes a new paradigm of soft-coded
value patterns that allows for a very flexible, extensible and
robust means of handling the complex supply chain requirements.
[0014] The present invention enables all levels of enterprise from
low, limited complexity and low technical capabilities to high
complexity and high technical capabilities to participate in a
wider, more complex food industry supply-chain. The present
invention includes the following optional features:
[0015] Distributed
[0016] International
[0017] Scalable
[0018] Sequence and parallelism that can be arbitrarily mixed
[0019] Standardized processes
[0020] The present invention allows modifications to supply chain
link, processes, and procedures. The number and links in the
supply-chain can be increased or decreased as required. The links
can be configured in any configuration of sequential or
parallelism. Changes can be made to supply chain routes, process,
and procedures at any time, even while the information system is in
continuous operation.
BRIEF DESCRIPTION OF THE DRAWINGS
[0021] The preferred and alternative embodiments of the present
invention are described in detail below with reference to the
following drawings.
[0022] FIGS. 1 and 2 are illustrations of the prior art;
[0023] FIG. 3A is a system block diagram of the present
invention;
[0024] FIG. 3B is a diagram of the different software layers of the
present invention;
[0025] FIG. 4 is an explanation of notation used in describing the
present invention;
[0026] FIGS. 5-11 are software model diagrams of components of the
present invention;
[0027] FIGS. 12-15 are directed graphs shown as examples of the
present invention; and
[0028] FIGS. 16-38 are examples of user interfaces formed in
accordance with the present invention.
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT
[0029] The present invention is preferably implemented as a food
traceability software application, but could be for any number of
supply chains. The present invention includes a number of component
software applications. FIG. 3A provides an overview example of a
system 40 formed in accordance with the present invention. The
present invention allows for a very flexible, extensible and robust
means of handling the complex supply chain requirements.
[0030] As shown in FIG. 3A, the system 40 includes one or more
servers 42 and user computer devices 44. Users in a supply chain,
such as farmers, inspectors, producers, manufacturers, grocers,
consumers, or restaurants, are linked through the over a network 46
(Internet or intra-net) to the food traceability application
executed by a server 42. Examples of the user computer devices 44
are PDAs, wireless devices, browsers, existing legacy systems, or
other computer-based devices.
[0031] The food traceability application provides traceability of
food that meets regulatory and commercially driven industry
objectives. All users in the food supply chain can access or input,
at pre-determined level of details based on relevancy and
appropriateness, critical data on the life-cycle of any product.
Users external to the supply chain, such as regulatory agencies,
can access relevant data with approval from parties involved.
[0032] The application allows modifications to supply-chain links,
processes, and procedures to be easily reconfigured on-line
instantly over a network connection. For example: the number of
links within each supply-chain can be increased or decreased as the
need arises. Also the processes within each link can also be
configured on-line for any configuration of sequential or
parallelism. Thus, changes can be made in the supply chain routes,
processes, and procedures at any time even while the system 40 is
in continuous operation.
[0033] FIG. 3B provides an example of a software architecture 50 of
the present invention. The architecture 50 includes a Presentation
Abstraction Layer 52 that insulates the user access devices such as
desktop computers, PDAs, cellphones, etc, from changes in
underlying presentation services. Thus, changes in servers do not
affect the ability of users to retrieve services. The Presentation
Abstraction Layer 52 provides filtering, formatting, encryption,
and language conversion services for all the underlying
presentation services.
[0034] A Presentation Services Layer 54 provides an interface
between underlying applications and filtering, formatting,
encryption, and language conversion services of the Presentation
Abstraction Layer 52. Each presentation service receives display
requests, converts those display requests into application
requests, formats the query results, and passes those results to
the Presentation Abstraction Layer 54 for post-processing.
[0035] An Application Services Layer 56 includes value-added
offerings for which subscribers have paid. Each application
offering exists on one or more servers. For example, the
Application Services Layer 56 includes a food trace service
offering.
[0036] Application services are built using foundation services 58.
Those foundation services perform work common to all applications,
but specific to none of those applications. Identifying system
time, translating names to addresses, management directories of
computers, users, applications and software objects, reporting
alarm conditions, controlling component access and managing
communication among system elements are all examples of foundation
services shared among all applications.
[0037] A Data Abstraction Layer (DAL) 60 provides a degree of
insulation between application and foundation services and the
underlying data stores on which they draw. The DAL 60 converts all
requests and replies into relational constructs. By shielding
foundation and application services from the specifics of an
underlying data store, new applications don't get tightly linked to
specific structures, with all the problems that characterize ERP,
MRP and other legacy applications.
[0038] The following example illustrates various benefits of the
present invention. A manufacturer that is exporting produce (corn)
from Thailand to a user in the UK.
[0039] Step 1. The manufacturer's inspectors use a farm component
of the present invention to capture information for food
traceability from their existing contract farmers.
[0040] Step 2. The manufacturer's QA department use a quality
component to capture information for food traceability when the
produce arrives at their manufacturing facility from the farm.
[0041] Step 3. The manufacturer's production personnel use a
production component to capture the critical information required
for food traceability/safety, and tie this information to the
physical product (i.e., the bar code and batch number).
[0042] The present invention solution has now captured the
information needed by regulatory and commercial users.
[0043] Step 4. The manufacturer uses a (distributed) database and
communications infrastructure of the present invention to
disseminate this information on request and by exception to the
users that need this information.
[0044] Step 5. A user using the trace component with the
manufacturer's permission to request information about food safety
and traceability. The user does this by simply typing or scanning
the barcode and batch number found on the product into the trace
component to perform a trace. The user is now able to act in near
real time on issues connected with food safety and
traceability.
[0045] Step 6. Other users in the supply chain such a distributors,
cold storage, logistical providers, etc. can be captured by using a
shipping comonent.
[0046] The software of the present invention includes a Meta model
that defines types, fields and complex structure and can be
populated at runtime. Instead of hard coding fields as columns of
specific tables, a Meta model (metadata structure) is provided for
storing field definition and fields data. This is considered soft
coding. Soft-coding allows users to efficiently manage evolution of
the model as the scope expands. Application programming code is
separated from the details of a particular usage, yielding highly
flexible, customizable, and yet efficient software.
Brief Explanation of the Data Modeling Notation
[0047] FIGS. 5-16 illustrate a model of the present invention in
OMT modeling notation that is a popular enhancement of the
Entity-Relationship approach. FIG. 4 summarizes modeling constructs
that are to describe the present invention. Object models are built
from three basic constructs: classes, associations, and
generalizations.
[0048] A class is denoted by a box and describes objects with
common attributes, behavior, and intent. As shown later on
MaterialLot, SupplyChainStageType, and UnitOfMeasure are examples
of classes. Attributes describe values of the objects in a class
and may be listed in a second portion of a class box. For example,
name is an attribute of class UnitOfMeasure. By convention the
attributes for a class are shown in one figure where the class is
defined and the attributes are suppressed for all other places
where a reference to the class occurs. Generalization organizes
classes by their similarities and differences and is denoted by a
triangle.
[0049] An association describes the relationship of objects of two
or more classes and is indicated by a line. The adornment on each
end of an association line denotes multiplicity. Multiplicity
specifies how many instances of one class may relate to an instance
of an associated class. A solid ball means `many` (zero or more); a
hollow ball means `at most one` (zero or one); a line without a
multiplicity symbol means exactly one.
Material Processing Package
[0050] FIGS. 5A and 5B show a software model 100 that allows
tracing of the handling of food in object oriented notation. A
SupplyChainStage 104 is an element of processing that is relevant
to the handling of materials, such as food; examples include
farming, manufacturing, inspection, approval, transport, and
retail. A MaterialLot 106 is a substance relevant to the processing
of a SupplyChainStage 104; examples include food items such as raw
corn, washed corn, cooked corn, and canned corn as well as
byproducts, wastes, chemicals, and pesticides. It can be
appreciated that various processing elements and substances
relevant to various processing elements can be used.
[0051] Because the present invention uses an object oriented model
as shown in FIGS. 5A and 5B, the present invention can create
directed graphs that can be scaled to include any number of
processing stages with any arrangement of parallel or serial
processes or nodes of the directed graph. Also, the directed graph
can be dynamically adapted. The present invention can also be
readily distributed and can handle an arbitrarily complex process.
The model 100 is customizable to any number of different
manufacturing processes (e.g., corn, pineapple, shrimp, etc.) or
company-specific practices. The model 100 supports data distributed
between multiple servers 42 over the network 46. As long as access
permissions are granted, the present invention can navigate from
computer to computer to trace the flow of foodstuffs.
[0052] Returning to the model 100 in FIG. 5B, the SupplyChainStage
104 may have any number of MaterialLot 106 as input and any number
as output. The MaterialLot 106 may enter and exit at most one
SupplyChainStage 104. Each MaterialLot 106 is associated with an
owner LegalEntity 108 and any number of accessing LegalEntities
108. A MaterialLot 106 owner can give others permission to access
the data. Only the owner or a designate of the owner (direct or
indirect) can grant access permissions.
[0053] A MaterialMaster 110 stores general data. There is one
MaterialMaster record for each Global Trade Item Number (GTIN).
GTIN is an international standard item numbering that is replacing
the European Article Number (EAN). The EAN in turn has replaced the
UPC, Universal Product Code, that has been used in the US and
Canada.
[0054] For example, when one picks up a can of corn in a store,
there is a bar code on the can. This bar code is a GTIN. There is
one MaterialMaster record for each GTIN. In contrast, there can be
many cans of corn; each of which could be stored as a separate
MaterialLot 106, all referring to a common MaterialMaster
record.
[0055] A SupplyChainStageType 114 describes individual
SupplyChainStages 104 in a similar manner to the way that
MaterialMaster 110 describes MaterialLot 106. A
SupplyChainStageType 114 has an expected duration (e.g., how long
does it normally take to decob corn). Expected duration with time
thresholds can be set for warning and error notices.
[0056] An Application 118 describes how various
SupplyChainStageTypes 114 and their instances are grouped into
unique applications. For example, an Application object includes a
Farm Management application, a Quality Management Application, a
Production Management Application, a Shipping and Logistics
Management application, etc. Application 118 also describes how
various ProcessPrototypes 120 are made available for an Application
118.
[0057] A LegalEntityRole 122 has multiple relationships with
SupplyChainStages 104. For example, a person could be both a
manager and an inspector. An effectiveDatetime and
expirationDatetime data for Legal EntityRole 122 notes when the
binding of the person and RoleType (Manager, inspector) is in
effect. For example, one person may serve as manager of a
department for a few years and then another person may move into
the job. Many LegalEntityRoles 122 can own a SupplyChainStage
104.
[0058] A ProcessPrototype 120 is a group of MaterialLots 106 and
SupplyChainStages 104, that would normally connect together into a
directed graph. Each time there is a new processing run for food,
the user must create a new directed graph to record the precise
relationship between processing stages and material that flows in
and out. It would be tedious to construct each of these graphs by
hand, over and over again. The notion of a ProcessPrototype 120
allows for easy construction of a new graph--just find the
correct
[0059] ProcessPrototype 120 and clone it to get a new
ProcessPrototype 120 that can be used for the next food-processing
run. The notion of a ProcessPrototype 120 allows for easy
construction of a new graph--just find the correct ProcessPrototype
120 and clone it by copying all instances of its associated
MaterialLot and SupplyChainStage classes. These new copies can then
be used for the next food-processing run. The ProcessPrototype 120
is used to define repeatable processes.
[0060] The model 100 is able to readily handle recursion. For
example, Pakfood freezes shrimp and inventories them as part of
routine processing. On occasion the frozen shrimp are added to a
later batch to make up a shortfall in certain shrimp sizes. As far
as the model 100 is concerned, the recycled shrimp are just another
material lot and a trace reveals that the recycled shrimp are from
an earlier production batch.
[0061] At the core of the present invention is the notion of a
directed graph. The directed graph is a standard computer science
construct. A directed graph consists of nodes that are connected by
arcs from a source node to a target node. The nodes are supply
chain stages and the arcs are material lots that enter and exit the
supply chain stages.
[0062] The model permits both the definition of a process and the
instantiation of a process to be defined at run time. The
definition of a process is found in the SupplyChainStageType,
MaterialMaster, and ProcessPrototype classes. SupplyChainStageType
and MaterialMaster define pertinent attributes for supply chain
stages and material lots respectively. The ProcessPrototype defines
standard processes that are then cloned each time an instantiation
is needed. The MaterialLot and SupplyChainStage classes are the
primary classes used for the instantiation. The present invention
provides run time definition and instantiation of food
processes.
[0063] FIG. 6 is an illustrative example of SupplyChainStages 170,
172, 174 connected with intervening MaterialLots, 182, 184, 186,
188.
[0064] FIG. 7 shows a more complex example as compared to that
shown in FIG. 6. In practice, any diagram with boxes and arrows
constitute a valid directed graph and can be handled by the model
100. With regards to the model 100, a process is completely
arbitrary. The definition of a process is a business decision and
the model 100 accommodates any reasonable decision.
Legal Entity Package
[0065] In FIG. 8, a LegalEntity 190 may be anyone of the following
Organization 195, a Person 196, a LegalEntityRoleType 192, or an
Automation 198. A LegalEntity 190 represents someone or something
that is involved with the processing and handling of materials such
as food. A LegalEntityRoleType 192 represents a job that a
LegalEntity 190 fulfills. Purchasing agent, manager, and inspector
are examples of LegalEntityRoleTypes 192. Many business functions
can be served either by the running of software (Automation
198)--for these situations the effect of software cannot be
distinguished from the efforts of Persons 196 and Organizations
195
[0066] A LegalEntityRole 194 combines a LegalEntity 190 with a
LegalEntityRoleType 192. The LegalEntity 190 includes a
parent-child relationship that LegalEntity 190 captures
miscellaneous relationships between other LegalEntities 190. The
association is recursive and LegalEntities 190 can be structured to
an arbitrary depth. Thus, for example, a company (an Organization
195) can have multiple divisions (also Organizations 195), a
division can have multiple departments (more Organizations 195),
and a department can have multiple offices (still more
Organizations 195).
Softcoded Value Package
[0067] Some classes in the model 100 can have an arbitrary number
of attributes. For example, numerous attributes are stored for
Persons 196, thus it is difficult to anticipate all of them in
advance. Furthermore, the appropriate attributes can vary by
customer, especially for MaterialLots 106 and SupplyChainStages
104. The software is tailorable for different food or even non-food
materials and customer processes. The model 100 is a good fit for
discrete batches of a material that are processed which
characterizes the food industry and some other industries. It is
also a fit for some continuous processes that can be approximated
by a batch process.
[0068] As shown in FIG. 9, the present invention includes a
mechanism for softcoding attributes and defining them at run time.
A DescribedObject 204 has softcoded Values 212. There is one record
for each of the following objects: Person 196, MaterialLot 106,
SupplyChainStage 104. Each DescribedObject 204 has a specific
DescribedObjectType 206. Some examples of DescribedObjectTypes 206
are Person, various kinds of MaterialLots 106, and various kinds of
SupplyChainStages 104. Thus there can be many Person
DescribedObjects and each refers to a single Person
DescribedObjectType record. Similarly, there can be many
MaterialLot DescribedObjects each of which refers to the
DescribedObjectType record for the kind of MaterialLot.
[0069] The model 100 states that DescribedObjects 204 must conform
to Attribute 208 defined for the corresponding DescribedObjectType
206. A corresponding database cannot enforce this constraint, so
application code must enforce it. Some Attributes 208 are
enumerated and have a pick list of possible values. An EnumValue
210 stores pick list values when they apply.
[0070] Values 212 are any of the following data types: number,
string, or datetime. One of the first three fields is filled in
(and the other two are null) for each Value record. Each Value 212
has a timestamp and LegalEntity 190 that is the source of the
value. Thus, the softcoded value mechanism keeps a history of
values. A Value 212 has a UnitOfMeasure 214 that overrides the
default specified for its Attribute 208.
[0071] Each Attribute 208 has a dataType (number, string, or
datetime) indicating the appropriate field to fill in for each
Value 212. String Values can have a maximum length. Minimum
multiplicity indicates if a Value 212 of the Attribute 208 is
required or optional for each DescribedObject 204. Similarly,
maximum multiplicity indicates if a Value 212 of the Attribute 208
are single-valued or can be multiple-valued for each
DescribedObject 204.
[0072] Some Attributes 208 are computed and have a corresponding
formula. Formulas support simple arithmetic (- + * /), declarative
if-then-else, and user defined functions. The functions can be
invoked via a case statement using a label of the function
name.
Described Object Package
[0073] As shown in FIG. 10, the DescribedObjects 254 can have
softcoded values or softcoded relationships.
[0074] As shown in FIG. 11, the DescribedObject 254 is a
placeholder for things that can have miscellaneous values and
miscellaneous relationships. A DescribedObject 254 can have many
Roles 262. A Role 262 is one end of a Relationship 264. Each Role
corresponds to one DescribedObject 204 and one Relationship
264.
[0075] A Relationship 264 is a binding between Roles 262. Most
Relationships 264 are binary, that is they have two Roles 262. A
DescribedObject 254 may have any number of Roles 262 and may
therefore participate in any number of Relationships 264. Each
Relationship 264 has effective and expiration dates that allows
history tracking. A Relationship 264 can be recorded in advance of
when it is needed or after it becomes obsolete.
Metadata
[0076] As shown in FIG. 11, the DescribedObjectType 270 is a
category for DescribedObjects 254. The DescribedObjectType 270 has
one or many RoleTypes 272. The RoleType 272 is a category for Roles
262. By analogy, the RoleType 272 is one end of a RelationshipType
274. Each RoleType 272 corresponds to one DescribedObjectType 270
and one RelationshipType 274. MinMultiplicity is the minimum number
of times that a DescribedObject 254 must participate in the
Relationship 264 and is usually 0 or 1. MaxMultiplicity is the
maximum number of times that a DescribedObject 254 can participate
in the Relationship 264 and is usually 1 or many.
[0077] The RelationshipType 274 is a category for Relationships
264. The RelationshipType 274 can have Attributes 276 describing
potential Relationship 264 values, just as the DescribedObjectType
270 can have Attributes 276 describing potential DescribedObject
values 254. An Attribute 276 is a characteristic of the
DescribedObject 254 or Relationship 264. Each Attribute 276 belongs
to one of the following: DescribedObjectType 270 or
RelationshipType 274.
SCENARIOS
Scenario 1
[0078] The following scenarios help describe the nature of change
the food industry is subject to over time and how the present
invention manages this change.
[0079] FIG. 12 shows a simple production line 400 for canned
vegetables with the following production stages (mixing 402,
cooking 404, canning 406). The following eleven tables represent
the production process using the model of the present invention.
The SupplyChainStages are owned by the LegalEntityRoles (Mixed
fruit manufacturer and inspector A).
[0080] In the following tables, metadata is represented in with a
background pattern. Application setup data is represented in Bold.
All other data is Transaction Data.
TABLE-US-00001 TABLE 1 SupplyChainStageType Stage TypeID Stage Type
Stage (PK) Name Duration 1 Mixing 0:10 2 Cooking 0:30 3 Canning
0:10
[0081] Table 1 is a SupplyChainStageType table that includes
metadata that represents each of the supply chain stage types.
There can be any number of stage types for an application.
TABLE-US-00002 TABLE 2 SupplyChainStage StageID StageTypeID
StageStart- StageStop Stage- Process (PK) Stage Name (FK) DateTime
DateTime Location PhotoTypeID 1 Mixing 1 Singapore 1 2 Cooking 2
Singapore 1 3 Canning 3 Singapore 1 4 Mixing 1 9:00 9 Singapore 5
Cooking 2 9:10 9:40 Singapore 6 Canning 3 9:50 10:00 Singapore
indicates data missing or illegible when filed
[0082] Table 2 is a SupplyChainStage table that stores various
day-to-day operations and associated data. Table 2 is used to store
dummy process data, which is used to create ProcessPrototype
clones. The user can easily represent complex processes and create
clones (copies) for ease of day-to-day data entry operations.
TABLE-US-00003 TABLE 3 Material Lot Material MaterialMaster
Material- ProcessPhoto- LotID MaterialLotName Name Quantity
TypeID(FK) 1 Mixed Fruits 1 2 Cooked Fruits 1 3 Canned Fruits 1 4
Mixed Fruits 100 5 Cooked Fruits 55 6 Canned Fruits 25
[0083] Table 3 is a MaterialLot table that is used to store
information of various Material Lots used in the SupplyChainStages.
Table 3 has dummy materials for the prototype and actual materials
with values.
TABLE-US-00004 TABLE 4 Process Prototype
[0084] Table 4 is a ProcessPrototype table that includes metadata
that represents a set of stages and MaterialLot from the real
SupplyChain process run. The user can create a dummy run first and
then create a new ProcessProtoType from it. Table 4 holds all the
related information of the PrototypeName metadata and a dummy
process is identified by the Prototype Name. The user can easily
add new SupplyChainStages, delete existing SupplyChainStageStages,
and change the direction of the supply chain.
TABLE-US-00005 TABLE 5 Application ApplicationID Application Name 1
Mixed Fruit Production Trace
[0085] Table 5 is an Application table that defines all the
SupplyChainStageTypes and ProcessPrototypes that are available for
the application. A group of SupplyChainStages are defined as
belonging to an Application. For example, in a sweet corn process
the following component applications are used: Farm component;
Quality component; and Production component.
TABLE-US-00006 TABLE 6 LegalEntity Role Legal- LegalEntity-
LegalEntity- Entity Effective expirtaion RoleID LegalEntityRoleName
Datetime Datetime 1 Inspector A Jan. 1, 2002 9:00 2 Mixed Fruit
Manufacturer Jan. 1, 2000 10:00
[0086] Table 6 is a LegalEntityRole table that stores the
information of various legal entity roles. The manufacturer (e.g.,
Mixed Fruit Manufacturer) own some SupplyChain stages. The
inspector who plays a role in the inspection process may also be
related to the same SupplyChain Stages as the manufacturer.
TABLE-US-00007 TABLE 7 MaterialLot IN SupplyChainStage
MaterialLotID SupplyChainStageID 1 2 2 3 4 5 5 6
TABLE-US-00008 TABLE 8 MaterialLot OUT SupplyChainStage
MaterialLotID SupplyChainStageID 1 1 2 2 3 3 4 4 5 5 6 6
[0087] Tables 7 and 8 are used to store information of various
Material Lots used in the SupplyChainStages. Materials going IN and
material going OUT connect the SupplyChainStages.
TABLE-US-00009 TABLE 9 ProcessProtoType Application
ProcessProtoTypeID ApplicationID 1 1
[0088] Table 9 stores the information of which process prototypes
are available for the application.
TABLE-US-00010 TABLE 10 SupplyChainStageType Application
SupplyChainStageTypeID ApplicationID 1 1 2 1 3 1
[0089] Table 10 stores the information of which SupplyChainStage
types are available for the application. For example,
SupplyChainStage type structures are defined for Farm Inspection,
Production, Quality, Shipping, etc and the application would make
use of the defined structures.
TABLE-US-00011 TABLE 11 SupplyChainStage LegalEntityRole
SupplyChainStageID LegalEntityRoleID 1 2 2 2 3 2 4 1 5 1 6 1 4 2 5
2 6 2
[0090] Table 11 stores the information of which SupplyChainStage
types were created or modified by which legalEntity role (person)
and to which organization legal entity the SupplyChainStage belongs
to.
Scenario 2
[0091] In Scenario 2 a new parallel production line is add to
Scenario 1. A company has set up a new parallel production line. An
additional capacity for the Canning process is added. Now the
company has the two canning lines Canning B1 and Canning B2. The
output of the Canning B1 line is Canned Fruits Small Can and the
output of the Canning B2 line is Canned Fruits Large Can.
[0092] The SupplyChainStages are show in FIG. 13.
[0093] Metadata is represented with background shading, Application
setup data is represented in Bold, and all other data is
Transaction Data.
TABLE-US-00012 TABLE 12 SupplyChainStageType StageType
StageTypeName StageDuration 1 Mixing 0:10 2 Cooking 0:30 3 Canning
Small Cans 0:10 4 Canning Large Cans 0:13
[0094] In the above table a SupplyChainStage type is defined to
record the activities in the Canning Large Cans process line.
TABLE-US-00013 TABLE 13 SupplyChainStage StageID Stage StageType
StageStartDate StageStop Stage- Process (PK) Name ID (FK) Time
DateTime Location PhotoTypeID 1 Mixing 1 Singapore 1 2 Cooking 2
Singapore 1 3 Canning 3 Singapore 1 4 Mixing 1 Jan. 3, 2002 9:00
Jan. 3, 2002 9:10 Singapore 5 Cooking 2 Jan. 3, 2002 9:10 Jan. 3,
2002 9:40 Singapore 6 Canning 3 Jan. 3, 2002 9:50 Jan. 3, 2002
10:00 Singapore 7 Canning B 4 Singapore 1 8 Mixing 1 Feb. 3, 2002
9:00 Feb. 3, 2002 9:10 Singapore 9 Cooking 2 Feb. 3, 2002 9:10 Feb.
3, 2002 9:40 Singapore 10 Canning B 3 Feb. 3, 2002 9:50 Feb. 3,
2002 10:00 Singapore 11 Canning B 4 Feb. 3, 2002 9:50 Feb. 3, 2002
10:03 Singapore indicates data missing or illegible when filed
TABLE-US-00014 TABLE 14 Material Lot Material Material- Material
ProcessPhoto LotID MaterialLotName Master Name Quantity TypeID(FK)
1 Mixed Fruits 1 2 Cooked Fruits 1 3 Canned Fruits Small 1 4 Mixed
Fruits 100 5 Cooked Fruits 90 6 Canned Fruits Small 9 7 Cooked
Fruits 1 8 Canned Fruits Large 1 9 Mixed Fruits 200 10 Cooked
Fruits 100 11 Cooked Fruits 100 12 Canned Fruits Small 9 13 Canned
Fruits Large 7
TABLE-US-00015 TABLE 15 Process Prototype ProcessProtoTypeID (PK)
PrototypeName 1 New prototype with canning for Large cans
TABLE-US-00016 TABLE 16 Application ApplicationID Application Name
1 Mixed Fruit Production Trace
TABLE-US-00017 TABLE 17 LegalEntity Role LegalEntity- LegalEntity-
LegalEntity- LegalEntity- RoleID RoleName EffectiveDatetime
expirtaionDatetime 1 Inspector A Jan. 1, 2002 9:00 2 Mixed Fruit
Jan. 1, 2000 10:00 Manufacturer
TABLE-US-00018 TABLE 18 MaterialLot IN SupplyChainStage
MaterialLotID SupplyChainStageID 1 2 2 3 4 5 5 6 7 7 9 9 10 10 11
11
TABLE-US-00019 TABLE 19 MaterialLot OUT SupplyChainStage
MaterialLotID SupplyChainStageID 1 1 2 2 3 3 4 4 5 5 6 6 8 7 9 8 10
9 11 9 12 10 13 11
[0095] Tables 18 and 19 are used to store information of various
Material Lots used in the SupplyChainStages. Materials going IN and
material going OUT connect the SupplyChainStages.
TABLE-US-00020 TABLE 20 ProcessProtoType Application
ProcessProtoTypeID ApplicationID 1 1
TABLE-US-00021 TABLE 21 SupplyChainStageType Application
SupplyChainStageTypeID ApplicationID 1 1 2 1 3 1 4 1
TABLE-US-00022 TABLE 22 SupplyChainStage LegalEntityRole
SupplyChainStageID LegalEntityRoleID 1 2 2 2 3 2 4 1 5 1 6 1 4 2 5
2 6 2 8 1 9 1 10 1 11 1 8 2 9 2 10 2 11 2
[0096] Table 22 stores the information of which SupplyChainStage
types was created or modified by the given legalEntity role
(person) and to which organization legal entity the
SupplyChainStage belongs to.
Scenario 3
[0097] In Scenario 3 a new cooling and CCP point are added to the
production line of Scenario 2. The output of the Canning process
line is sent to a new process line for cooling. There are separate
cooling lines for Small Cans and Large Cans.
[0098] The typical SupplyChainStages are show in the above FIG. 14.
As a first step, the existing clone to support the new Cooling
Process is modified. Two new stage types CCP for Small Can and CCP1
for large Can are declared.
TABLE-US-00023 TABLE 23 SupplyChainStageType StageTypeID(PK)
StageTypeName StageDuration 1 Mixing 0:10 2 Cooking 0:30 3 Canning
Small Cans 0:10 4 Canning Large cans 0:13 5 CCP Small Cans 0:05 6
CCP Large Cans 0:07
TABLE-US-00024 TABLE 24 SupplyChainStage Process StageID StageType
StageStart- StageStop Stage- Photo- (PK) Stage Name ID (FK)
DateTime DateTime Location TypeID 1 Mixing 1 Singapore 1 2 Cooking
2 Singapore 1 3 Canning B1 3 Singapore 1 4 Mixing 1 Jan. 3, 2002
9:00 Jan. 3, 2002 9:10 Singapore 5 Cooking 2 Jan. 3, 2002 9:10 Jan.
3, 2002 9:40 Singapore 6 Canning 3 Jan. 3, 2002 9:50 Jan. 3, 2002
10:00 Singapore 7 Canning B2 4 Singapore 1 8 Mixing 1 Feb. 3, 2002
9:00 Feb. 3, 2002 9:10 Singapore 9 Cooking 2 Feb. 3, 2002 9:10 Feb.
3, 2002 9:40 Singapore 10 Canning B1 3 Feb. 3, 2002 9:50 Feb. 3,
2002 10:00 Singapore 11 Canning B2 4 Feb. 3, 2002 9:50 Feb. 3, 2002
10:03 Singapore 12 CCP Small Cans 5 Singapore 1 13 CCP Large Cans 6
Singapore 1 14 Mixing 1 Jan. 10, 2003 9:00 Jan. 10, 2003 9:10
Singapore 15 Cooking 2 Jan. 10, 2003 9:10 Jan. 3, 2002 9:40
Singapore 16 Canning B1 3 Jan. 10, 2003 9:50 Jan. 10, 2003 10:00
Singapore 17 Canning B2 4 Jan. 10, 2003 9:50 Jan. 10, 2003 10:03
Singapore 18 CCP Small Cans 5 Jan. 10, 2003 10:00 Jan. 10, 2003
10:05 Singapore 19 CCP Large Cans 6 Jan. 10, 2003 10:03 Jan. 10,
2003 10:10 Singapore
TABLE-US-00025 TABLE 25 Material Lot Material- Material- Material-
ProcessProto- LotID MaterialLotName MasterName Quantity TypeID (FK)
1 Mixed Fruits 1 2 Cooked Fruits 1 3 Canned Fruits Small 1 4 Mixed
Fruits 100 5 Cooked Fruits 90 6 Canned Fruits Small 9 7 Cooked
Fruits 1 8 Canned Fruits Large 1 9 Mixed Fruits 200 10 Cooked
Fruits 100 11 Cooked Fruits 100 12 Canned Fruits Small 9 13 Canned
Fruits Large 7 14 Cooled Small Cans 1 15 Cooled Large Cans 1 16
Mixed Fruits 300 17 Cooked Fruits 200 18 Cooked Fruits 100 19
Canned Fruits Small 9 20 Canned Fruits Large 7 21 Cooled Small Cans
9 22 Cooled Large Cans 7
TABLE-US-00026 TABLE 26 Process Prototype ProcessProtoTypeID (PK)
PrototypeName 1 New prototype with canning for Large cans
TABLE-US-00027 TABLE 27 Application ApplicationID Application Name
1 Mixed Fruit Production Trace
TABLE-US-00028 TABLE 28 LegalEntity Role Legal- LegalEntity-
LegalEntity- Entity Effective expirtaion RoleID LegalEntityRoleName
Datetime Datetime 1 Inspector A Jan. 1, 2002 9:00 2 Mixed Fruit
Manufacturer Jan. 1, 2000 10:00
TABLE-US-00029 TABLE 29 MaterialLot IN SupplyChainStage
MaterialLotID SupplyChainStageID 1 2 2 3 4 5 5 6 7 7 9 9 10 10 11
11 3 12 8 13 16 15 17 16 18 17 19 18 20 19
TABLE-US-00030 TABLE 30 MaterialLot OUT SupplyChainStage
MaterialLotID SupplyChainStageID 1 1 2 2 3 3 4 4 5 5 6 6 7 2 8 7 9
8 10 9 11 9 12 10 13 11 14 12 15 13 16 14 17 15 18 15 19 16 20 17
21 18 22 19
TABLE-US-00031 TABLE 31 ProcessProtoType Application
ProcessProtoTypeID ApplicationID 1 1
TABLE-US-00032 TABLE 32 SupplyChainStageType Application
SupplyChainStageTypeID ApplicationID 1 1 2 1 3 1 4 1 5 1 6 1
TABLE-US-00033 TABLE 33 SupplyChainStage LegalEntityRole
SupplyChainStageID LegalEntityRoleID 1 2 2 2 3 2 4 1 5 1 6 1 4 2 5
2 6 2 7 2 8 1 9 1 10 1 11 1 8 2 9 2 10 2 11 2 12 2 13 2 14 1 15 1
16 1 17 1 18 1 19 1 14 2 15 2 16 2 17 2 18 2 19 2
Scenario 4
[0099] In Scenario 4 the company has added a new cooking capacity
to the production line of Scenario 3. The output of the Cooking B1
and Cooking B2 process line is sent to a new process line for
Canning. There are separate cooling lines for Small Cans and Large
Cans. The output of the SupplyChainStages Cooking B1 and Cooking B2
are sent to a common process for merging to mix the materials into
one. The output of the Merging process is sent to Canning B1 or
Canning B2 process line.
[0100] The SupplyChainStages are show in FIG. 15. As a first step,
the existing clone to support the new Cooking Process is modified.
The existing Cooking Stage would be renamed as Cooking B1 and a new
line added called Cooking B2. The output of these processes would
be merged in the process Merge.
TABLE-US-00034 TABLE 34 SupplyChainStageType StageTypeID(PK)
StageTypeName StageDuration 1 Mixing 0:10 2 Cooking B1 0:30 3
Canning Small Cans 0:10 4 Canning Large Cans 0:13 5 CCP Small Cans
0:05 6 CCP Large Cans 0:07 7 Cooking B2 0:30 8 Merge 0:10
TABLE-US-00035 TABLE 35 SupplyChainStage Process StageID StageType
StageStart- StageStop Stage- Photo- (PK) Stage Name ID (FK)
DateTime DateTime Location TypeID 1 Mixing 1 Singapore 1 2 Cooking
2 Singapore 1 3 Canning B1 3 Singapore 1 4 Mixing 1 Jan. 3, 2002
9:00 Jan. 3, 2002 9:10 Singapore 5 Cooking 2 Jan. 3, 2002 9:10 Jan.
3, 2002 9:40 Singapore 6 Canning 3 Jan. 3, 2002 9:50 Jan. 3, 2002
10:00 Singapore 7 Canning B2 4 Singapore 1 8 Mixing 1 Feb. 3, 2002
9:00 Feb. 3, 2002 9:10 Singapore 9 Cooking 2 Feb. 3, 2002 9:10 Feb.
3, 2002 9:40 Singapore 10 Canning B1 3 Feb. 3, 2002 9:50 Feb. 3,
2002 10:00 Singapore 11 Canning B2 4 Feb. 3, 2002 9:50 Feb. 3, 2002
10:03 Singapore 12 CCP Small Cans 5 Singapore 1 13 CCP Large Cans 6
Singapore 1 14 Mixing 1 Jan. 10, 2003 9:00 Jan. 10, 2003 9:10
Singapore 15 Cooking 2 Jan. 10, 2003 9:10 Jan. 3, 2003 9:40
Singapore 16 Canning B1 3 Jan. 10, 2003 9:50 Jan. 10, 2003 10:00
Singapore 17 Canning B2 4 Jan. 10, 2003 9:50 Jan. 10, 2003 10:03
Singapore 18 CCP Small Cans 5 Jan. 10, 2003 10:00 Jan. 10, 2003
10:05 Singapore 19 CCP Large Cans 6 Jan. 10, 2003 10:03 Jan. 10,
2003 10:10 Singapore 20 Mixing 1 Singapore 2 21 Cooking B1 2
Singapore 2 22 Cooking B2 7 Singapore 2 23 Merge 8 Singapore 2 24
Canning B1 3 Singapore 2 25 Canning B2 4 Singapore 2 26 CCP Small
Cans 5 Singapore 2 27 CCP Large Cans 6 Singapore 2 28 Mixing 1 Feb.
10, 2004 9:00 Feb. 10, 2004 9:10 Singapore 29 Cooking B1 2 Feb. 10,
2004 9:10 Feb. 10, 2004 9:40 Singapore 30 Cooking B2 7 Feb. 10,
2004 9:10 Feb. 10, 2004 9:40 Singapore 31 Merge 8 Feb. 10, 2004
9:40 Feb. 10, 2004 9:50 Singapore 32 Canning B1 3 Feb. 10, 2004
9:50 Feb. 10, 2004 10:00 Singapore 33 Canning B2 4 Feb. 10, 2004
9:50 Feb. 10, 2004 10:03 Singapore 34 CCP Small Cans 5 Feb. 10,
2004 10:03 Feb. 10, 2004 10:08 Singapore 35 CCP Large Cans 6 Feb.
10, 2004 10:03 Feb. 10, 2004 10:10 Singapore
TABLE-US-00036 TABLE 36 Material Lot Material- MaterialMas-
Material- ProcessProto- LotID MaterialLotName terName Quantity
TypeID(FK) 1 Mixed Fruits 1 2 Cooked Fruits 1 3 Canned Fruits Small
1 4 Mixed Fruits 100 5 Cooked Fruits 90 6 Canned Fruits Small 9 7
Cooked Fruits 1 8 Canned Fruits Large 1 9 Mixed Fruits 200 10
Cooked Fruits 100 11 Cooked Fruits 100 12 Canned Fruits Small 9 13
Canned Fruits Large 7 14 Cooled Small Cans 1 15 Cooled Large Cans 1
16 Mixed Fruits 300 17 Cooked Fruits 200 18 Cooked Fruits 100 19
Canned Fruits Small 9 20 Canned Fruits Large 7 21 Cooled Small Cans
9 22 Cooled Large Cans 7 23 Mixed Fruits 2 24 Mixed Fruits 2 25
Cooked Fruits b1 2 26 Cooked Fruits b2 2 27 Merge Fruits B1 2 28
Merge Fruits B2 2 29 Canned Fruits Small 2 30 Canned Fruits Large 2
31 Cooled Small Cans 2 32 Cooled Large Cans 2 33 Mixed Fruits 34
Mixed Fruits 35 Cooked Fruits b1 36 Cooked Fruits b2 37 Merge
Fruits B1 38 Merge Fruits B2 39 Canned Fruits Small 40 Canned
Fruits Large 41 Cooled Small Cans 42 Cooled Large Cans
TABLE-US-00037 TABLE 37 Process Prototype ProcessProto TypeID(PK)
PrototypeName 1 New prototype with canning for Large cans 2 Latest
production with two cooking lines
TABLE-US-00038 TABLE 38 Application ApplicationID Application Name
1 Mixed Fruit Production Trace
TABLE-US-00039 TABLE 39 LegalEntity Role LegalEntity- LegalEntity-
LegalEntityEffec- LegalEntityexpi- RoleID RoleName tiveDatetime
rationDatetime 1 Inspector A Jan. 1, 2002 9:00 2 Mixed Fruit Jan.
1, 2000 10:00 Manufacturer
TABLE-US-00040 TABLE 40 MaterialLot IN SupplyChainStage
MaterialLotID SupplyChainStageID 1 2 2 3 4 5 5 6 7 7 9 9 10 10 11
11 3 12 8 13 16 15 17 16 18 17 19 18 20 19 23 21 24 22 25 23 26 23
27 24 28 26 29 25 30 27 33 29 34 30 35 31 36 31 37 32 38 33 39 34
40 35
TABLE-US-00041 TABLE 41 MaterialLot OUT SupplyChainStage
MaterialLotID SupplyChainStageID 1 1 2 2 3 3 4 4 5 5 6 6 7 2 8 7 9
8 10 9 11 9 12 10 13 11 14 12 15 13 16 14 17 15 18 15 19 16 20 17
21 18 22 19 23 20 24 20 25 21 26 22 27 23 28 23 29 24 30 26 31 25
32 27 33 28 34 28 35 29 36 30 37 31 38 31 39 32 40 33 41 34 42
35
[0101] Rows with a background pattern denotes prototype clone
data.
TABLE-US-00042 TABLE 42 ProcessProtoType Application
ProcessProtoTypeID ApplicationID 1 1 2 1
TABLE-US-00043 TABLE 43 SupplyChainStageType Application
SupplyChainStageTypeID ApplicationID 1 1 2 1 3 1 4 1 5 1 6 1 7 1 8
1
TABLE-US-00044 TABLE 44 SupplyChainStage LegalEntityRole
SupplyChainStageID LegalEntityRoleID 1 2 2 2 3 2 4 1 5 1 6 1 4 2 5
2 6 2 7 2 8 1 9 1 10 1 11 1 8 2 9 2 10 2 11 2 12 2 13 2 14 1 15 1
16 1 17 1 18 1 19 1 14 2 15 2 16 2 17 2 18 2 19 2 20 2 21 2 22 2 23
2 24 2 24 2 26 2 27 2 28 2 29 2 30 2 31 2 32 2 33 2 34 2 35 2
[0102] The following scenario demonstrates how the present
invention is able to manage changing requirements and process over
a period of time. The present invention does this while
simultaneously maintaining data integrity, thus allowing the user
to obtain information despite the changes that have been made in
the data storage structure. The present invention allows all these
changes to be made with the solution, which is in continuous
use.
Scenario A
[0103] A shrimp manufacturer has a lab test process
(Oxytetracycline Residue Analysis Report) for the shrimp received
in the tanks. This process (process prototype 1) was created and
used on 5 Feb. 2003 as shown in a screen shot of a graphical user
interface window 500 shown in FIG. 16.
Scenario B
[0104] After 1 month of operation the shrimp manufacturer was told
by its customer that a Chloramphenical residue analysis test was
now needed to in addition to the Oxytetracycline residue analysis
test. To add the new test the user makes use of the original
process in Scenario 1 (process prototype 1) as a clone to create a
new process prototype 2. The user modifies process prototype 1 to
create the new prototype while the system is still running This is
done by using the existing Oxytetracycline residue analysis test
screen as a template to add a new test for the Chloramphenical
residue analysis test, see FIGS. 17 and 18.
Scenario C
[0105] After three months the shrimp manufacturer was asked again
by its customer to add a third test. The new test is a
Microbiological analysis test. This was as a direct result of new
legislation that had been introduced in the customer's country.
[0106] To do this the user uses the process prototype 2 as clone to
create a new process prototype 3, see FIGS. 20-22. The user
modifies the process prototype 2 to create a new prototype while
the system is still running This is done by using the existing
Oxytetracycline and Chloramphenical residue analysis test as a
template screen to create the new Microbiological analysis test
Tracing
[0107] When the shrimp manufacturer, inspector, or other authorized
user wants to do a trace of lab information based on the Tank and
Raw Material date, the user keys in the required information into a
trace criteria window 600 as shown in FIG. 22. After the user
selects a GO button, a trace is initiated.
Trace Scenario 1
[0108] When a user enters the following search information in the
window 600:
[0109] Tank Number: TTR-1002
[0110] Raw Material Date: 5 Jun. 2003
[0111] and initiates a trace, the reports that were created for
that tank number on the entered date are made available to the
user. FIG. 23 shows as window 620 that is presented to the user
once the search is complete. The user is presented with links
(boxes 624-628) to the three reports that area available for the
entered information. The respective activity reports are obtained
by activating the associated link. FIGS. 24-26 are example reports
that are displayed upon activation of the corresponding box
624-628.
Scenario 2
[0112] When the user enters the following information (as shown in
FIG. 27):
[0113] Tank Number: TTR-1002
[0114] Raw Material Date: 10 Mar. 2003
[0115] and initiates a trace, the reports that were created for
that tank number on the entered date are made available to the
user. FIG. 28 shows as window 680 that is presented to the user
once the search is complete. The user is presented with links
(boxes 682, 686) to the three reports that area available for the
entered information. The respective activity reports are obtained
by activating the associated boxes 682, 686. FIGS. 29 and 30 are
example reports that are displayed upon activation of the
corresponding box 682, 686.
[0116] FIGS. 31-35 show customized FarmTrace user interfaces that
allow a farmer, inspector, or other user to enter farm related
information regarding a harvested product. FIG. 31 is a screen shot
of a window 700 that lets a user select a Process Prototype. In the
window 700, inspectors or other user creates a set of activities
for a farm. This is repeated on a daily basis as necessary. A
process prototype clone helps the user to easily create the set of
interconnected activities in a single operation.
[0117] As shown in FIG. 32, farm information has been entered.
[0118] In FIG. 33 Sweet Corn Land Preparation Inspection activities
are entered. Land Preparation Inspection activities include other
details, such as fertilizer, planting, pesticide details, or any
other details desired.
[0119] FIG. 34 shows an entry window for entering Seeding
Germination details as wells as other details, such as fertilizer
and pesticide details.
[0120] FIG. 35 shows an entry window for entering Growth
Development details as wells as other details, such as fertilizer
and pesticide details.
[0121] FIG. 36 illustrates a customized user interface for a
QualitiyTrace component of the application. FIG. 36 shows an entry
window for entering Received details that include other details,
such as previously entered farmer details, sampling information,
and detail inspection information.
[0122] FIGS. 37 and 38 illustrate customized user interfaces for a
ProductionTrace component of the application. The ProductionTrace
component allows entry of information regarding various user
specified production activities.
[0123] While the preferred embodiment of the invention has been
illustrated and described, as noted above, many changes can be made
without departing from the spirit and scope of the invention.
Accordingly, the scope of the invention is not limited by the
disclosure of the preferred embodiment.
* * * * *