US007343315B2
`
`a2) United States Patent
`US 7,343,315 B2
`(0) Patent No.:
`Mar. 11, 2008
`(45) Date of Patent:
`Wittmeret al.
`
`(54)
`
`(75)
`
`SYSTEM AND METHOD OF EFFICIENT
`SCHEDULING AND PROCESSING OF
`PURCHASE ORDERS
`
`Inventors: Holger Wittmer, Riegelsberg (DE);
`AndreasFreitag, Saarbriicken (DE)
`
`(73)
`
`Assignee: SAP Aktiengesellschaft, Walldorf (DE)
`
`(*)
`
`Notice:
`
`Subject to any disclaimer, the term ofthis
`patent is extended or adjusted under 35
`U.S.C. 154(b) by 602 days.
`
`(21)
`
`Appl. No.: 10/914,614
`
`(22)
`
`Filed:
`
`Aug. 9, 2004
`
`(65)
`
`Prior Publication Data
`
`US 2005/0197912 Al
`
`Sep. 8, 2005
`
`Related U.S. Application Data
`
`6,341,351 B1*
`6,505,093 B1*
`6,507,851 Bl
`6,701,299 B2*
`6,910,017 Bl
`6,980,966 BL
`7,092,929 BL
`7,117,165 Bl
`7,139,731 Bl
`2002/0023500 Al
`2002/0078159 Al
`
`.......... 726/9
`1/2002 Muralidhran et al.
`1/2003 Thatcher et al.
`............ 700/216
`1/2003 Fujiwaraet al.
`3/2004 Kraisser et al. .......... 705/8
`6/2005 Wooetal.
`12/2005 Sobradoetal.
`8/2006 Dvorak etal.
`10/2006 Adamset al.
`11/2006 Alvin
`2/2002 Chikuan et al.
`6/2002 Petrogiannis etal.
`
`(Continued)
`FOREIGN PATENT DOCUMENTS
`
`JP
`
`2004030343 A
`
`1/2004
`
`(Continued)
`OTHER PUBLICATIONS
`
`Anon., “(A Lot of) Life After H. Ross: Electronic Data Systems,”
`Financial World, vol. 162, No. 22, p. 50, Nov. 9, 1993.*
`
`(60)
`
`Provisional application No. 60/551,221, filed on Mar.
`8, 2004, provisional application No. 60/563,284, filed
`on Apr. 16, 2004.
`
`(Continued)
`
`Primary Examiner—Nicholas D. Rosen
`(74) Attorney, Agent, or Firm—Foley & Lardner LLP
`
`(51)
`
`Int. Cl.
`
`(52)
`(58)
`
`(56)
`
`(57)
`
`ABSTRACT
`
`(2006.01)
`G06Q 10/00
`(2006.01)
`G06 30/00
`Methods and system for scheduling purchase orders are
`US. C1. ccc cceeseteerteetees
`705/8; 705/29; 705/26
`disclosed. The method includes defining a purchasing order
`Field of Classification Search .................... 705/8,
`for a delivery period, the purchase order having two or more
`705/26, 27, 29
`items, and the delivery period corresponding to two or more
`See application file for complete search history.
`order periods. The methodalso includes determiningalatest
`order period for each item to satisfy a pre-determined lead
`References Cited
`time between order placement and delivery for delivery in
`the delivery period, and assigning each item to one of the
`order periods. At least one item in the purchase order is
`assigned to a latest order period of the at least one item.
`
`U.S. PATENT DOCUMENTS
`
`5,400,253 A
`5,615,109 A *
`5,870,716 A *
`5,930,771 A
`
`3/1995 O’Connor
`3/1997 Eder
`....cceeeececseeeeeeee 705/8
`2/1999 Sugiyama et al.
`............ 705/26
`7/1999 Stapp
`
`17 Claims, 10 Drawing Sheets
`
`900
`
`
`s10—_] Organize Purchase Order Items
`
`for Delivery Period According to
`Lead Time
`
`Select Item with
`Greatest Lead Time
`
`920 ~—_|
`
`
`
`
`
`
`
`Does Lead Time
` Goto Next Order
`
`
`
`Require Ordering in
`Period
`urrent Order Period
`
`
`
`960
`
`930
`
`940
`
`950
`
`
`
`
`“Include Item in Purchase Order
`for Current Order Period
`
`
`
`
`
`
`970
`
`Additional Items.
`
`Select Next
`
`
`Remainingfor Current
`Item
`
`
`Delivery Period?
`
`980
`Go to Next Delivery Period
`
`
`
`
`
`PROVI-1018 - Page 1
`
`PROVI-1018 - Page 1
`
`

`

`US 7,343,315 B2
`
`Page 2
`
`U.S. PATENT DOCUMENTS
`
`OTHER PUBLICATIONS
`
`2002/0107713
`2002/0147668
`2002/0152128
`2003/0023500
`2003/0028437
`2003/0046195
`2003/0149631
`2003/0158791
`2003/0171998
`2003/0172007
`2003/0200150
`2003/0229502
`2004/0098358
`2004/0162763
`2004/0186783
`2004/02 10489
`2004/0220861
`2005/0055283
`2005/0060270
`2005/0086 122
`2005/0096963
`2005/0102192
`2005/0102227
`2005/0165659
`2005/0171825
`2006/0036507
`
`Al
`Al
`Al*
`
`Al
`
`8/2002
`10/2002
`10/2002
`1/2003
`2/2003
`3/2003
`8/2003
`8/2003
`9/2003
`9/2003
`10/2003
`12/2003
`5/2004
`8/2004
`9/2004
`10/2004
`11/2004
`3/2005
`3/2005
`4/2005
`5/2005
`5/2005
`5/2005
`7/2005
`8/2005
`2/2006
`
`Hawkins
`Smith et al.
`Walchetal.
`Boieset al.
`Grantet al.
`Mao
`Crampton et al... 705/22
`Gilberto et al.
`Pujar et al.
`Helmoltet al.
`Westcott et al.
`Woo
`Roediger
`Hoskin etal.
`Knight et al.
`Jacksonetal.
`Morciniecetal.
`Zarovinsky
`Ramakrishnan
`Cirulli et al.
`Myr et al.
`Gerrits et al.
`Solonchev
`Gruber
`Denton et al. wee
`Pujar et al.
`FOREIGN PATENT DOCUMENTS
`
`seeseseseseeneees 705/26
`
`teveeeeeeneees 705/26
`
`Brown,T.C., “The Effects ofAssortment Composition Flexibility on
`Operating Efficiency” (Abstract only), Dissertation Abstracts Inter-
`national, vol. 55/08-A, p. 2458.*
`Wilson, G.T., “Changing the Process of Production,” Industrial
`Management, vol. 37, No. 1, pp. 1-2, Jan./Feb. 1995.*
`Melcer, R., “Local Tech Firm Creates Retail Markdown Tool,” Mar.
`24, 2000, Cincinnati Business Courier.*
`U.S. Appl. No. 60/374,892, filed Apr. 22, 2002, Russell Krajec.
`Author unknown,“Staffware: Staffware And Biomni Join Forces To
`Provide End-To-End E-Procurement Solution With Enhanced
`Workflow Capability: Self-Service Functionality Will Enable Thou-
`sands Of Transactions To Be Handled Daily From The Desktop,”
`MS Presswire, Coventry, Feb. 6, 2001 (p. 1.).
`summer/autumn 03,
`“Beyond Markdown Management”,
`4caster, Iss. 4, vol. 2.
`Melcher, Rachel, “Local tech firm creates retail markdown tool”,
`Mar. 24, 2000, Cincinnati Business Courier (3 pgs.).
`Profitlogic,
`available
`at
`http://web.archive.org/web/
`20020603 11838/http://profitlogic.com/, available at least by Apr.
`15, 2005 (22 pp.).
`“Retailers Manage Markdown Challenges Using i2 Solutions”, Jan.
`13, 2003, NFR 92nd Annual Convention & Expo (2 pgs.).
`Subrahmanyan et al., “Developing optimal pricing and inventory
`policies for retailers who face uncertain demand”, Journal of
`Retailing, vol. 72, No. 1, Spring, 1996 (p. 7(24)).
`
`the
`
`WO
`
`WO-9945450 A2 *
`
`9/1999
`
`* cited by examiner
`
`PROVI-1018 - Page 2
`
`PROVI-1018 - Page 2
`
`

`

`U.S. Patent
`
`Mar.11, 2008
`
`Sheet 1 of 10
`
`US 7,343,315 B2
`
`a 100
`
`120
`
`
`PLANNING
`
`
`BW DATA
`
`
`SYSTEM
`
`132
`
`
`
`P.O.
`CREATOR
`
`160
`
`
`
`
`
`P.O.
`CONTROL
`
`136
`
`
`
`P.O.
`
`WORKBENCH
`
`FIG. 1
`
`PROVI-1018 - Page 3
`
`PROVI-1018 - Page 3
`
`

`

`Sheet 2 of 10
`
`US 7,343,315 B2
`
`Mar. 11, 2008
`
`U.S. Patent
`
`PROVI-1018 - Page 4
`
`PROVI-1018 - Page 4
`
`

`

`U.S. Patent
`
`Mar.11, 2008
`
`Sheet 3 of 10
`
`US 7,343,315 B2
`
`300
`
`
`
`
`
`PURCHASE
`ORDER
`USER
`PROCESSING
`INTERFACE
`312
`SYSTEM
`
` 314
`
`
`
`
`
`
`GOODS
`RECEIPT
`PROCESSING
`SYSTEM
`316
`
`BUDGET
`RULES
`VERIFICATION
`SYSTEM
`318
`
`[_
`
`USER COMPUTING SYSTEM
`310
`
`
`
`PLANNING
`SYSTEM
`322
`
`BUDGET
`RULES ODS
`324
`
`
`
`BUDGET
`RULES
`GENERATION
`SYSTEM
`326
`
`DATA COMPUTING SYSTEM
`320
`
`FIG. 3
`
`PROVI-1018 - Page 5
`
`PROVI-1018 - Page 5
`
`

`

`U.S. Patent
`
`Mar.11, 2008
`
`Sheet 4 of 10
`
`US 7,343,315 B2
`
`
` 405
`
`CONTRACT
`
`ASSOCIATION
`
`410
`
`
`BUYING OR
`SELLING SEASO
`
`f
`
`420
`
`
`
`
`
`
`
`CALCULATE
`CALCULATE
`
`
`BUDGET RULE
`BUDGET RULE
`
`
`
`FOR PERIOD
`FOR PERIOD
`
`
`NEXT PERIOD
`NEXT PERIOD
`
`
`
`
`
`
`TRANSFER
`BUDGET RULE
`
`
`TO USER
`COMPUTING
`
`SYSTEM
`
`
`FIG. 4
`
`PROVI-1018 - Page 6
`
`PROVI-1018 - Page 6
`
`

`

`U.S. Patent
`
`Mar. 11, 2008
`
`Sheet 5 of 10
`
`US 7,343,315 B2
`
`PURCHASE
`ORDER
`
`500
`
`
`
`RULES/CHECKS
`(EVALUATE
`BUCKETS)
`
`515
`
`520
`
`510 ELECTRONIC
`
`
`
`
`
`APPLY BUDGET x
`
`
`
`
`
`
`PURCHASE
`
`
`ORDER SATISFIES
`RULE?
`
`
`
`
`DISPLAY
`DISPLAY
`
`APPROVAL TO
`
`
`REJECTION TO
`USER
`
`
`
`USER
`
`ON REJECTION
`
`
`PROVIDE
`
`UPDATE STORED
`
`REMEDIAL
`
`VALUES BASED
`
`OPTIONS BASED
`
`
`ON APPROVAL
`
`
`
`
`
`535
`
`540
`
`FIG. 5
`
`PROVI-1018 - Page 7
`
`PROVI-1018 - Page 7
`
`

`

`U.S. Patent
`
`Mar.11, 2008
`
`Sheet 6 of 10
`
`US 7,343,315 B2
`
`009
`
`
`
`
`
`GsayInNosaY
`
`AWILOVS
`
`SUJUOWZ
`
`SUJUOWS
`
`SYJUOWGUO|
`
`syjuoWwpyuo|
`
`yUuOU!|SUJUOWGSUJUOWQUJUOW|SYJUOWZSUJUOWGSuJUOW¢SUJUOW
`
`000¢e
`
`€Sy
`
`
`
`Yd0dYOASVHOYNd
`
`09
`
`0€9
`
`0z9~~O19
`
`sionae006OesPhivy000600€6}SIV
`Saou90008008Ee
`sauv0002008
`swore|0008002
`saoe002se
`
`
`LSNONV-dOldsdAYSAMNAC
`0008sersg
`00081000sig
`O00cL0001LsjoIuy
`
`O0SZI00SEé8/SIyy
` o000r00SZOLspluy6sly8spy28/OIV9SIVGapy¥s|9IVV
`
`1sooALILNVNDsWALI
`
`0089OOZ}clB/IYY
`0008[sisay
`
`
`
`
`9‘Sid
`
`
`
`PROVI-1018 - Page 8
`
`PROVI-1018 - Page 8
`
`
`
`
`
`
`
`
`

`

`U.S. Patent
`
`Mar. 11, 2008
`
`Sheet 7 of 10
`
`US 7,343,315 B2
`
`ysnBny
`
`eunr
`
`Aine
`
`>o=
`
`judy
`
`0s9
`
`dgayindawwiOrg
`
`YsaGHO
`
`doluad
`
`youeyy
`
`€001ebany|SuIUOUTEaSInUOUgYe [00s009ati2SuIUOUZ[0000100hSen|SyHUOU2aaSUJUOUI YJUOU!|00ze008Qtany|:CUO[00007008orsony.CqUOUT
`
`
`syjuoWsOoszbO0SEZani|aauinbos
`
`SuJUOWG000ze__000¢|2epny
`SuIUOUTg[0082000aensyJuoWG000SGZPLepny|
`
`
`syJuoU4|-—-ooog—=esi*”00SLLalomy|
`
`SUIUOWpaa008[|san|
`syJuOWy$i—00S}02ajo
`
`
`
`syjuow€0005002€apiny
`
`1s09ALLINWNDWal
`suo0ee0096aySyJUOW0|Oke0099gay
`
`SUJUOUW0000910002Zbajoy
`
`yuo|000600€6)amy
`
`
`ISNONV-GOlYWAdAYSAITEG
`0E90z9alg
`
`
`
`Y3aduOASVHOYNd
`
`
`
`Z°Sls
`
`PROVI-1018 - Page 9
`
`PROVI-1018 - Page 9
`
`
`

`

`U.S. Patent
`
`Mar. 11, 2008
`
`Sheet 8 of 10
`
`US 7,343,315 B2
`
`004Ta5anddauinoagdolwsdYaduo
`
`
`
`
`LSNONV ‘GQOldsd
`
`000'Z9
`
`000'0S
`
`O0€'1Z
`
`000'Z2
`
`Oor'Zs
`
`ooe'Ze
`
`yoeyy
`
`dy
`
`Aew
`
`eunr
`
`Ainr
`
`isniny
`
`Laan
`
`AYSAINAG
`
`8‘Sls
`
`PROVI-1018 - Page 10
`
`PROVI-1018 - Page 10
`
`

`

`U.S. Patent
`
`Mar. 11, 2008
`
`Sheet 9 of 10
`
`US 7,343,315 B2
`
`008a
`
`OL
`
`OL
`
`OL
`
`OL
`
`OL
`
`OL
`
`OL
`
`JUUUUUL
`
`YSAOVNVWOd
`
`6Sls
`
` ULL
`
`NOILVZINVOYOASVWHOYNd
`
`
`
`
`dnOwdSASVHOYNd
`
`ALVdOdLSALV]
`
`
`
`AlvaAYaANad
`
`0c8
`
`0€8
`
`
`
`YOLVOIGNISSV31Sy
`
`WIYMSLY
`
`YOCNAAOve
`
`PROVI-1018 - Page 11
`
`PROVI-1018 - Page 11
`
`
`
`

`

`U.S. Patent
`
`Mar.11, 2008
`
`Sheet 10 of 10
`
`US 7,343,315 B2
`
`
`
`900
`
` 910
`Organize Purchase Order Items
`for Delivery Period According to
`
`
`Lead Time
`
`
`
`920
`
`Select Item with
`Greatest Lead Time
`
`
`
` 930
`
`Does Lead Time
`
`Go to Next Order
`
`
`Require Ordering in
`Period
`urrent Order Period?
`
` 940
`
`include Item in Purchase Order
`
`
`950
`
`for Current Order Period
`
`
`Additional Items
`
`
`Select Next
`
`Remaining for Current
`
`
`
`Item
`Delivery Period?
`
`
`
`
`980 Go to Next Delivery Period
`
`FIG. 10
`
`PROVI-1018 - Page 12
`
`PROVI-1018 - Page 12
`
`

`

`US 7,343,315 B2
`
`1
`SYSTEM AND METHOD OF EFFICIENT
`SCHEDULING AND PROCESSING OF
`PURCHASE ORDERS
`
`CROSS-REFERENCE TO RELATED PATENT
`APPLICATIONS
`
`2
`includes determining a latest order period for each item to
`satisfy a pre-determined lead time between order placement
`and delivery for delivery in the delivery period, and assign-
`ing each item to one of the order periods. At least one item
`in the purchase order is assigned to a latest order period of
`the at least one item.
`Another embodimentof the invention relates to a program
`product for scheduling purchase orders. The program prod-
`This application claims the benefit of U.S. Provisional
`uct includes machine-readable program code for causing,
`Application No. 60/551,221, filed Mar. 8, 2004 andentitled
`when executed, one or more machines to perform the
`“Inventory Management,” and U.S. Provisional Application
`following method steps: defining a purchasing order for a
`No. 60/563,284, filed Apr. 16, 2004 and entitled “Inventory
`delivery period, the purchase order having two or more
`Management,” both of which are hereby incorporated by
`reference.
`items, the delivery period corresponding to two or more
`order periods, determiningalatest order period for each item
`15
`BACKGROUND OF THE INVENTION
`to satisfy a pre-determined lead time between orderplace-
`ment and delivery for delivery in the delivery period, and
`assigning each item to one ofsaid orderperiods, at least one
`item in said purchase order being assigned to a latest order
`period of said at least one item.
`Another embodimentof the invention relates to a method
`of scheduling purchase orders. The method includes: a)
`receiving a purchaseorderfor a delivery period, the delivery
`period corresponding to two or more order periods,
`the
`purchase order including two or more items, each item
`having a predetermined lead time between order placement
`and delivery, b) determining whetheran item has a lead time
`requiring inclusion of the item in a sub-order corresponding
`to current order period, c) including the item in the sub-order
`corresponding to current order period whenstep c) results in
`an affirmative determination, and d) repeating steps b) andc)
`for all items in the purchase order.
`Other features and advantages of the present invention
`will become apparent to those skilled in the art from the
`following detailed description and accompanying drawings.
`Tt should be understood, however, that the detailed descrip-
`tion and specific examples, while indicating preferred
`embodiments of the present invention, are given by way of
`illustration and not
`limitation. Many modifications and
`changes within the scope of the present invention may be
`made without departing from the spirit thereof, and the
`invention includes all such modifications.
`
`The present invention relates generally to the field of
`systems for and methods of processing purchase orders.
`More particularly, the present invention relates to systems
`for and methods of efficient scheduling and processing of
`purchase orders.
`Oneparticular business that processes purchase orders is
`the retail business. Operations for a business often include
`purchasing merchandise from a supplier for sale to custom-
`ers or for use in the processes and products for the business.
`Generally, purchasing merchandise or supplies from the
`supplier involves sending a purchase order to the supplier
`requesting a specific number of items for a specific price.
`The numberof items multiplied by the price of the items
`provides a total cost associated with the purchase order.
`Prior to sending the purchase order, the purchase order may
`need to be approved by an entity, such as a budgeting
`department. The entity may apply one or morerules to the
`purchase order in determining whether to approve the pur-
`chase order. For example, a rule may dictate that
`the
`approvalis granted or denied based on whetherincurring the
`total cost of the purchase order is acceptable in view of
`budget constraints. Accordingly,
`the purchase order
`is
`approved or rejected based on budget constraints prior to
`being sent to the supplier.
`The retail business can require that certain purchase
`orders be processed in a very short amount of time, while
`other purchase orders must be placed well in advance of the
`desired delivery. For example, changes in current trends in
`the fashion industry may require that inventory be increased
`on short notice. For certain aspects of the fashion industry,
`items may be required to be ordered one or more seasonsin
`advance. An advantageous purchase order system must
`accommodate this variation in lead times of the ordered
`
`items without unnecessarily tying up funds.
`Each purchase order may include numerousitemsthat are
`desired at a particular delivery period. In order to ensure
`timely delivery, the purchase order may be placed well in
`advanceofthe desired delivery period. Typically, funds from
`the budget corresponding to the purchase order require
`binding at the time the purchase order is placed. Binding of
`the funds at this early stage may result in detrimental cash
`flow or other financial shortcomings. Accordingly,
`it
`is
`desirable to delay binding of the fundsas late as possible.
`
`SUMMARY OF THE INVENTION
`
`One embodiment of the invention relates to a method of
`
`scheduling a purchase order. The method includes defining
`a purchasing order for a delivery period, the purchase order
`having two or more items, and the delivery period corre-
`sponding to two or more order periods. The method also
`
`20
`
`30
`
`35
`
`40
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`
`45
`
`50
`
`60
`
`The exemplary embodiments will hereafter be described
`with reference to the accompanying drawings, wherein like
`numerals depict like elements, and:
`FIG. 1 is a general block diagram illustrating a system for
`processing data related to retail operations and planning,
`according to exemplary embodiment;
`FIG. 2 is a block diagram illustrating an open to buy
`control system, according to an exemplary embodiment;
`FIG. 3 is a general block diagram illustrating a purchase
`order processing system for processing electronic purchase
`orders, according to an exemplary embodiment;
`FIG.4 is a flowchart illustrating a method for creating a
`budget rule, according to an exemplary embodiment;
`FIG.5 is a flow chart illustrating a method for processing
`electronic purchase orders, according to an exemplary
`embodiment;
`FIG.6 is a chart illustrating an exemplary purchase order;
`FIG.7 is a chart illustrating the purchase order of FIG. 6
`after sorting;
`FIG. 8 is a chart illustrating the an exemplary budget
`allocation for the purchase order of FIGS. 6 and 7;
`FIG. 9 illustrates an embodiment of a screen shot for an
`
`exemplary purchase order manager; and
`PROVI-1018 - Page 13
`
`PROVI-1018 - Page 13
`
`

`

`US 7,343,315 B2
`
`3
`FIG. 10 is a flow chart illustrating an embodiment of a
`method of scheduling a purchase order.
`
`DETAILED DESCRIPTION OF THE
`PREFERRED EMBODIMENTS
`
`In the following description, for the purposes of expla-
`nation, numerous specific details are set forth in order to
`provide a thorough understanding of the present invention.
`It will be evident to one skilled in the art, however, that the
`exemplary embodiments may be practiced without these
`specific details. In other instances, structures and device are
`shown in diagram form in orderto facilitate description of
`the exemplary embodiments.
`The disclosed embodiments provide systems and methods
`for scheduling a purchase order which reduces or minimizes
`the length of time that funds are tied up. In the disclosed
`embodiments, one or more items in a purchase order are
`scheduled for ordering based on an expected lead time.
`Using the lead time,a latest order period can be determined
`to include those items in the desired delivery period. Thus,
`the binding of funds is delayed until the latest order period
`determined for particular items.
`In at least one exemplary embodimentillustrated below,
`a computer system is described which has a central process-
`ing unit
`(CPU) that executes sequences of instructions
`contained in a memory. Morespecifically, execution of the
`sequences of instructions causes the CPU to perform steps,
`which are described below. The instructions may be loaded
`into a random access memory (RAM)for execution by the
`CPU from a read-only memory (ROM), a mass storage
`device, or some other persistent storage. In other embodi-
`ments, multiple workstations, databases, process, or com-
`puters can be utilized. In yet other embodiments, hardwired
`circuitry may be used in place of, or in combination with,
`software instructions to implement the functions described.
`Thus, the embodiments described herein are not limited to
`any particular source for the instructions executed by the
`computer system.
`Referring now to FIG. 1, a general block diagram is
`shownillustrating an open-to-buy (OTB) system 100 for
`processing data related to retail operations and planning,
`according to exemplary embodiment. The OTB system 100
`includes a data warehouse 120, a purchase ordercreator 132,
`an OTB control system 130 and a purchase order control
`system 134.
`The OTB system 100 may be implemented as a work-
`bench that may be a data processing system or software
`configured to control, display, interface with operators, or
`perform other operations to manage purchase orders. The
`OTB control system 130 is preferably implemented in an
`SAP-based workbench, interface, and architecture, but any
`other systems may beutilized.
`The OTB system 100 may be implemented as a single
`system, a distributed system, or any combination thereof.
`The OTB system 100 may be implemented using a single
`computing system, a plurality of computing systems, soft-
`ware, hardware, or any other system or combination of
`systems to perform the functions described herein.
`Data warehouse 120 is a data repository configured to
`receive, sort, and process information related to retail opera-
`tions and planning. The data warehouse 120 may also be
`implementedas using a single or multiple systems. The data
`warehouse 120 may further include one or more functions
`associated with it to permit a userto efficiently organize and
`retrieve stored data. The OTB system 100 is sufficiently
`
`4
`flexible to accommodate any of a variety of types of data
`warehouses 120, such as databases, for example.
`In certain embodiments, the data warehouse 120 may be
`adapted to generate rules or checks to be used in the
`processing of purchase orders. In other embodiments, a
`planning system. 160 may be provided to generate planning
`data, rules, checks and budgets, and to provide such infor-
`mation to the data warehouse 120. In this regard, the rules
`or checks may include a planning data or planning budgets
`including budget buckets corresponding to delivery periods
`and order periods, for example. The planning data or budgets
`are provided by the data warehouse 120 to the OTB control
`system 130, which may be included in a purchase order
`workbench.
`
`The purchase order workbench may be a data processing
`system configured to allow a user to create, monitor, and
`receive approval for purchase orders for obtaining products
`or other supplies from a supplier. According to an exemplary
`embodiment, the purchase order creator 132, the purchase
`order control system 134, and the open-to-buy control
`system 130 are included in the workbench.
`Purchase order creator 132 may be any system or method
`for creating electronic purchase orders. An electronic pur-
`chase order may be any type of purchase order in an
`electronic format. Purchase order creator 132 may include
`one or more functionsto facilitate creation of the electronic
`
`purchase order. For example, purchase order creator 132
`mayinclude an auto fill function to automatically populate
`an electronic purchase order with previously stored data.
`Additionally, purchase order creator 132 may include a user
`interface configured to receive and display purchase order
`information with a user. Upon creation of a purchase order,
`the purchase order creator 132 provides the purchase order
`information to the data warehouse 120 for use in future
`planning or recalculation of planning data or budget. The
`purchase order information is also provided to the purchase
`order control system 134. An event manager system 170
`may be provided to facilitate communication between the
`purchase order creator 132 and the purchase order control
`system 134. The event manager system 170 may receive
`commands from the purchase order control system 134 to,
`for example, initiate the creation of a purchase order and
`may process that command by issuing a command to the
`purchase order creator 132.
`Purchase order control system 134 may be any system for
`controlling and monitoring electronic purchase orders. Pur-
`chase order control system 134 includes one or more func-
`tions configured to allow a user to manipulate or receive
`information related to any existing purchase order. For
`example, a user may utilize purchase order control system
`134 to retrieve information related to a specific purchase
`order and modify one or moreattributes of the retrieved
`purchase order.
`The purchase order control system 134 provides purchase
`order information to the OTB control system 130, which is
`configured to facilitate automated approval or rejection of
`electronic purchase orders including both procurement and
`budget check functions. The OTB control system 130
`receives an electronic purchase order as input and applies
`one or more rules to the electronic purchase order to
`determine whether the electronic purchase order should be
`approved or rejected. The rules, or checks, are based on the
`planning budget which is based on the planning data
`received from the data warehouse 120. Planning budgets or
`buckets may be generated from the planning data at either
`the data warehouse 120, the OTB control system 130 or in
`another module lying between the two. According to an
`PROVI-1018 - Page 14
`
`40
`
`45
`
`60
`
`PROVI-1018 - Page 14
`
`

`

`US 7,343,315 B2
`
`5
`exemplary embodiment, the one or more rules includes at
`least one budget rule. A budget rule may define the amount
`of money that is available for a purchase order based on
`information contained in the purchase order. For example, a
`purchase order may include a time frame for the purchase
`order, and the rule may be used to define the amount of
`money that is available in that time frame. According to
`alternative embodiments, the one or more rules may also
`include rules directed to the timing during which purchase
`orders may be requested. In other embodiments, other types
`of rules may be incorporated into the OTB system 100. The
`OTB control system 130 will be further discussed below
`with reference to FIGS. 2-5.
`According to alternative embodiments, a purchase order
`workbench may further include more, fewer, or different
`systemsto facilitate creation, processing, and maintenance
`of purchase orders. Further, functions associated with one or
`more systems may alternatively be associated with one or
`morealternative systems. For example, purchase ordercre-
`ator 132 may be implemented as a component of purchase
`order control system 134.
`Referring now to FIG. 2, a block diagram illustrates open
`to buy system 136, according to an exemplary embodiment.
`Open to buy system 136 includesa plurality of components
`configured to implement one or more functions to facilitate
`acceptance or rejection of an electronic purchase order.
`Open to buy system 136 may be implemented as a purchase
`order processing system as will be further discussed below
`with reference to FIGS. 3-5.
`Open to buy system 136 includes a front-end system 210
`configured to provide an interface between one or more
`users and a back-end system 230, according to an exemplary
`embodiment. Although shown as separate components,
`front-end system 210 and back-end system 230 may alter-
`natively be implemented as a single system. Yet further,
`open to buy system 136 may include a plurality of either
`front-end systems 210 or back-end systems 230. For
`example, open to buy system 136 mayincludea plurality of
`front-end systems 210 to allow multiple users in distributed
`locations to access uniform and synchronized information
`stored on backend system 230.
`Further, each of the front-end system 210 and the back-
`end system 230 may further be configured to each include
`lower-level front-end and back-end systems. In this regard,
`one or both of the front-end system 210 and the back-end
`system 230 may include components which allow user
`interaction and components whichinterface with other mod-
`ules.
`Front-end system 210 is configured to allow one or more
`users to perform functions implemented using open to buy
`system 136. In the illustrated exemplary embodiment, the
`front-end system 210 includes a planning-data transfer mod-
`ule 212 adapted to receive data from the back-end system
`230. The data received may include, for example, planned
`budget buckets, sales and budgeting information based on
`prior experience, current market conditions, and other fac-
`tors. Additional detail relating to the planning data andits
`generation is provided below with reference to the descrip-
`tion of the back-end system 230.
`The planning-data transfer module 212 may generate a
`budgetor a set of budget buckets, or budget portions, based
`on the planning data received from the back-end system 230.
`The budget information generated can then be stored in a
`planned budget module 214. In other embodiments,
`the
`planning-data transfer module 212 mayreceive and transfer
`raw planning data, and the planned budget module 214 may
`generated the budget information. In still further embodi-
`
`5
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`6
`ments, the budget information may be generated within the
`back-end system 230 and forwarded to the planned budget
`module 214 through the planning data transfer module 212.
`When a purchase order is received or submitted for
`processing, the front-end system 210 applies a set of checks
`or rules to determine whetherthe order should be processed
`as submitted. In this regard, the front-end system 210 is
`provided with an order check module 218. The order check
`module 218 accesses budget information from the planned
`budget module 214 to perform the necessary checks.
`The order check module 218 may be configured to apply
`one or more open to buy rules to an electronic purchase
`order to determine whether the electronic purchase order
`should be accepted or rejected. A budget rule may be a type
`of open to buy rule. The order check module 218 may
`include a currency translation function configured to convert
`generic financial information to specific financial informa-
`tion relevant to the current user of front-end system 210.
`Status processing function 218 may be any function config-
`ured to determine whether no check was performed, a
`positive check result was received or a negative check result
`wasreceived.
`
`If the order check module 218 determines that the pur-
`chase order can be processed, the order is forwarded to a
`procurement module 220, which may communicate, directly
`or indirectly, over an interface with a user, such as a supplier
`or a vendor, to place the order. The procurement module 220
`may be configured to receive and process information
`related to the creation, modification, or cancellation of an
`electronic purchase order.
`If, on the other hand, the order check module 218 deter-
`mines that the rules do not allow the purchase order to be
`processed as submitted, the order, the rules, the budget or a
`combination thereof may be modified to allow the process-
`ing of the purchase order. In this regard, the procurement
`module 220 may be configured to procure necessary addi-
`tional budget(e.g., changing the value,delivery period, etc.)
`with the support of the purchasing documents creation
`module 222 or by requesting for a special release of addi-
`tional budget that allows to overbook the corresponding
`budget bucket. If enough budget can be obtained within the
`procurement moduel 220, the order check module 218 can
`determine that the order can be processed. The front-end
`system 210 maybe provided with a used budget module 216
`to store budget information that is exhausted by existing
`purchase orders which may have been updated or revised by
`the order check module 218.
`
`Once the order has been placed by the puchasing docu-
`ments creation module 222, a confirmation may be received
`from the supplier or vendor. The information relating to the
`placement of the order may be generated by a purchasing
`documents creation module 222. In this regard, the infor-
`mation may include any revisions to the purchase order
`required by the order check module 218. The information
`generated by the purchasing documents creation module 222
`may then be stored in a purchasing documents data store
`224. In certain embodiments, an actual data transfer module
`226 may be provided to supply the actual order and budget
`information to the back-end system for planning purposes.
`According to alternative embodiments, front-end system
`210 may include more, fewer, and/or different functions to
`provide a user interface and perform calculations related to
`purchase order processing. The described functions may be
`implemented using hardware, software, integrated circuits
`or any system configured to perform the functions described
`herein.
`
`PROVI-1018 - Page 15
`
`PROVI-1018 - Page 15
`
`

`

`US 7,343,315 B2
`
`7
`Back-end system 230 is configured to process data, store
`data,
`facilitate planning, provide reporting, and provide
`other functions associated with purchase order management
`using one or more functions and/or components. The back-
`end system 230 includes a planning data module 232
`adapted to generate a merchandise ordering plan including
`all planned data (e.g., planned sales, planned margin,
`planned inventory, planned receipts and planned budget
`buckets). The merchandise ordering plan may include infor-
`mation relevant to, for example, order scheduling and bud-
`geting. The planning data module 232 may be configured to
`receive information from atleast an order forecasting system
`and an actual inventory reporting system 234. The order
`forecasting system (not shown) may include information
`from various sources, such as industry outlook reports,
`relating to expected market conditions, for example, The
`actual inventory reporting system 234 provides information
`to the planning data module 232 relevant to the actual
`inventory currently available, which may include expected
`deliveries. In this regard,
`the actual
`inventory reporting
`system 234 may include information received from the
`front-end system 210, through the actual data transfer mod-
`ule 226, relating to purchase orders already placed.
`In certain embodiments, the planning data module 232
`maybe adapted to generate budget information. The budget
`information may be stored within the back-end system 230
`in a transferred budget module 236. The transferred budget
`module 236 may be used to store planned budget buckets
`that have been released and/or transferred to the planned
`budget module 214. This may be used to reduce data traffic
`by requiring transfer of only the changed and new buckets
`from the planning data module 232 and the transferred
`budge