CA2193582A1 - Order processing method - Google Patents
Order processing methodInfo
- Publication number
- CA2193582A1 CA2193582A1 CA002193582A CA2193582A CA2193582A1 CA 2193582 A1 CA2193582 A1 CA 2193582A1 CA 002193582 A CA002193582 A CA 002193582A CA 2193582 A CA2193582 A CA 2193582A CA 2193582 A1 CA2193582 A1 CA 2193582A1
- Authority
- CA
- Canada
- Prior art keywords
- order
- request
- slip
- router
- data
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q30/00—Commerce
- G06Q30/06—Buying, selling or leasing transactions
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/08—Payment architectures
- G06Q20/20—Point-of-sale [POS] network systems
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/08—Payment architectures
- G06Q20/20—Point-of-sale [POS] network systems
- G06Q20/202—Interconnection or interaction of plural electronic cash registers [ECR] or to host computer, e.g. network details, transfer of information from host to ECR or from ECR to ECR
Abstract
An order processing method for implementation in a distributed computer system is described. An order create request is received from a user at a local station, validated locally and routed to a remote station for authorization. Connection between local and remote stations may be of any type. Progress of an order is tracked by a configuration matrix, and communication is tracked and controlled by a router slip appended to an order message and which is in turn governed by the matrix. The matrix allows selection of a current control register which governs applicability of validation routines to data entities of the request or order. Paper handling is reduced or eliminated and sufficient control for decentralised purchasing is achieved.
Description
2 1 935~2 ~An order ~roces-~inq method~
INT~ODU~TION
~ield of the Inven~ion The present invention relates to an order processing method in a di~tributed computer s~stem.
P~ior Art Discus~ion A number of order proces~ing methods ~re known for handling customer orders. Example~ of various order proce~sing method~ are described in European Patent Nos.
EP 0 425 405 ~2 and EP 0 585 932 A2 and United ~ingdom Patent No. GB 2 265 032. While these methods address the pro~lems a~sociated with inYentOry tracking and stock control management, validation of the order is ll~ited to ensuring correct receipt of the order. EP 0 5~5 932 deccribe~ a system for performing order validation and generating shipping labels requiring minimal operator input. Additionally, it is known to provide a Gystem to facilitate electronic processing of customer orders, as described in WO 94/28497.
While such ~yste~s accurately track orders and ensure that ~ub~itted orders are correctly formatted, they do not adequately address the need to verify an operators authority to place such an orter. Further, the prior art systems do not adequately address the problems of managing orders in a distri~uted system used by per~onnel at mutually remote location~. A~ a re~ult, in larger organisations excessive re~our~es are committed to ~alidating and authorising purchase order~ prior to submission to ~uppliers This involves a large degree of paper handling. ThiR can cause processing delay~ and failure to deliver ordered items in good time.
It is an o~ect of the invention to provide an order processing method which significan~l~ reduces the level of paper handling for distributed environments. Another object is to provide more co~prehensive validation control for decentralised purchasing.
2 1 ~3582 According to the invention there i8 provided an order pro~esslng method carried out in a distributed data processing system and comprising the ~teps of:-a local station of the system receiving an order create reque~t, identifying a rele~ant order type, retrieving a prompt file associated with said order type, and prompting user input of order request data according to said prompt file;
generatlng a conf~guration matrix storing order request parameter values including the order type, required action data, and Yalidation data;
validating the request according to ~alidation rou~ines with at least some of the request data en~ities;
writing da~a of valid reque~ts to a message file and appending a router slip comprising a source identifier and a ~et of tasks derived from the configuration matrix, said tasks indicating users from which authorization is required; and transmitting the message file and the router ~lip to nodes of the distributed ~ystem until the slip records satisfactory performance of all of said tasks.
The inputting validation using the prompt file, followed by use of the configuration matrix for initial validation in the abo~e manner ensure data integrity from an early ~tage before much user time i~ required The matrix ens~res that the request i~ dynamically tracked so that it may ~e efficiently handled. Inter-relation~hip of the matrix and the ro~ter slip ensure that validation, order processing and ~ommunication are correctly and efficiently implemented. The important a~pect of the matrix is the data stored to allow tracking, not the layout - it may be in grid or simple linear formats.
In one embodi~ent, a node of the system which receives the message file and router slip:-retrieve~ from the router slip a required authorization code to allow user authorization at the node;
regenerates the order request fro~ the message file;
writes user authori~ation data to the ro~ter slip using said codes; and re-valid~te~ the o~der request according to validation routines associated with at least some of the data entities.
Thi~ en~ures control of the order authorization across remote sites. Preferably, said node performs the further step of appending a node address to the router 1~ slip, writing the order request data to a messa~e file and trans~itting said message file and router slip ~o a remote node.
In one embodiment, ~aid router slip is generated by instantiation of task objects from a template according to the configuration matrix. This allows co~prehensive control of the filips. Preferably, the task ob~ects are instantiated by applying rules using matrix data to determine if a ta~k object of the template applie~ to the particular order request. This provides for very simple and uniform slip creation.
Ideally, the rules are stored with the instantiate~ task object~, and the method comprises the further steps of dynamically determining applicability of the task ob~ects at subsequent order stages by applying the rules with current matrix da~a. This feature allows constant, dynamic, and uniform control of the slip in real time.
In one embodiment, the router slip stores task~ ~hich cause transmission of notification signals to nodes of the system. This is very advantageous for distributed 21 93~82 p~rchasing as it allows very simple and comprehensive dissemination of information.
In another e~bodiment the request is validated by:-generating a control register for the order request hy selectively comparing dat~ entitLes of the inputted order reque~t ~ith a reference register, the control register indicating r~lative importance of the entities by storing an entry indicating for each data entity that validation i~ not applicable, could result in a ~arning, or could stop the request;
validating the order reque~t by retrieving a set of validation routine8 and running each routine with respect to an order request data entity, an~
identi~ying as invalid an entity if both the routine output is false and the a~sociated control register entry indicates a warning or a request stop;
outputting an error message if the control regi~ter indicates a warning for an invalid entity; and halting t~e req~est if the control register indicates a stop for an invalid entity.
The control register thus allo~s relatively standard validation routine~ which are associated with data entities to be used throughout the distributed system.
It effectively masks them for ~ustomisation at the appropriate request stage.
In one embodiment the method comprises the further step of accessing a lookup table of relevant data to input to the order request when creating the order request. This allo~s a large degree of ~entrali~ed control in a di~tributed environment.
In one e~bodiment, the lookup table is generated ~y:-an admlnistration proce~sor of the systemparsing selected text portions of an inputted administration me~sage by iteratively identifying ~ 1 q358~
space characters in the selected text portions to isolate each word;
comparing each isolated word against a predefined list of noise word~;
ignoring isolated ~ords found in the list;
generating a keyword file ~ith isolated words and as~ociated words;
generating a lookup file from th~3 keyword file by indexing and writing non duplicate entries of the keyword f ile .
This is a very ef ~ective tool for technically capturing user '5 knowledge for dissemination throughou~ the system .
Ideally, the step of directing the me8~age file and attached router 81ip to a remote station includes the 8 tep~ of:-identifying a transport protocol for a connection between the local and remo~e stations; and encoding the me~Rage file and attached router slip in re~ponse to the identified transport protocol with a predefined encoding table.
In one embodiment, the step of decoding the me~sage file and attached rOuter slip includes the ~tep~ of:-identifying a transport protocol ~or a connection hetween the local and remote stations; and aligning bytes associated with ~he mes~age file and associated router slip in re~pon~e to the identified tr~nsport protocol.
D~TAILED DEScRIpTIoN QF TH~ INVENTIO~
~rief De3cription of ~he Drawinqs The invention will be ~ore clearly understood from the following description thereof, given ~y way of example only with reference to the acco~panying drawing in which:-Fig. l(a) and l(b) are together a flo~ diagram of anorder processing method of the invention, Fig. 2(a) and 2(b) are illustrations of data input screen~ displayed by a system carrying out t~e method, and Fig. 3 is a table showing relationships between va1idation routine~ a control register and validation actions.
Pescription o~ ~he P~eferred Em~odi~e~ts Referring to Figs. l~a) and l(b) there i~ illu~trated an order processing method according to the invention carried out in a di~tri~uted computer system. The system may be of any suitable distributed type having interconnected node~ or stations. Conventional microprocessors and LAN links have suffL~ient processing and com~unication~ capabilities. Typical syste~s include Intranet and Internet systems using such languages as Java~ and Java~ virtual machines running on ~uch platforms a~ Hindows '95~, Solarus~, HPUX~ with browser-baset front ends. The method ma~ also be run on a Lh~ or WAN with any de6ired number of machines, subject to capacity. In this specification ~nodes" or "statiOnS" may be physical or logical. For example, a node may be the current location of a u~er, in~tead of a physical machine.
An order create ~equest is received from a user at a local station in step l. ~he order request type associated ~ith the order create request of step l is ~5 identified in ~tep 2 by comparing the order request type with a number of predefined, permitted order reque~t types. ~hi~ order re~uest type might typically be an order request for office ~tationary requiring little aut~orization, or a ma~or capieal expenditure request necessitating many layers of authorization. A sample of a displayed list of order types is ~hown in Fig.
2(a).
A prompt file associated with the order request type identified in stage 2 i~ retrieved in stage 3 and used to prompt the user in stage 4. These prompts are therefore specific to the identified order request type, penmitting the user eo input only necess~ry order request data without having to filter out unnecessary detail. A screen for a prompt file is shown in Fig~
2~b).
When all of the request data has been entered, the order re~est is submitted in step 5 by activating a validation controller. The local station then generates a control register in ~tep 6 for the order reque~t. The control regi~ter is generated by selecting each data entity of the inputted order re~uest in turn and comparing it with the appropriate section of a reference register retrie~ed in seep 7. Portions of the request which are validated may include validation of suppliers, credit card or spend lLmits among cthers. The ~alidation is achieved by generating a configuration matri~ for the order ~equest. ~he matrix has a set of parameter values for the order request including an order stage identifier, the order type, and action lists, including user li~t~. Thus, the matrix dynamically tracks progress of an order request at all times and allows selection of appropriate routines and data in real time according to busine~s policy and rules. This is very important a~ it allows real time control in a distributed environment The current ~atr~x is used to automatically ~elect the reference register which i8 appropriate, the matrix itself being retrieYed using relational database links with the order request identifier.
8 21 q3~82 The control register is a set of control flag , one per data entity. The possible flag value~ are:-- Not applicable - Warning - Stop - Stop and display error message Additional control flags co~ld also be ~ed.
Becau~e multiple levels of validation are used, the method allows a large degree of flexibility to help ensure the order is processed ~o the maximum extent throuqh the distributed system without sacrificing data integrity. The control register ifi linked by a relational database link to the configuration matrix in step ~ and an order &tage identifier is added in step 9 This data structure is indexed by a dynamic pointer array po~n~ing to parent~child tags, each having an off~et value and a length. The data it~elf comprises ASCII characters, encoded wit~ a ~imple algorithm such as one applying a constant character offset. The 2~ parent/child relationship allows a hierarchial linkage.
The order stage identifier is u~ed in subsequent validation to determine the i~portance of validation failures. For example if a supplier is not found for a low co~t, low risk item then the reque~t may be allowed to proceed however in validation of greater value items the absence of an approved supplier may cause rejection of the request.
At this stage, it is timely to describe a general administrati~e tool for ef fecti~e dissemination of processing control throughou~ the ~y~tem. An ad~inistrator input~ a text message relating to a ~eneral data entity such as "supplier". This text reflects the administrator's knowledge of the entity.
The workstation i5 typically, but not necessarily, a file ~erver or other host. Selected portion~ of the text are parsed in step 1~0 by iterati~ely identifying sp~ce characters in the ~elected text portions to isolate each word. Isolated words are compared again~t a predeined list of noi~e w~rds ~n step 101 dnd words ~ 1 935~
matched to entries on the list are ignored. A keyword file with isolated word~ not found in the l~t is genera~ed in step 102. Each word i~ linked with a data value, such a~ a particular supplier being linked with a produ~t. A lookup file i~ generated from the keyword file in step 103 by indexing and writing non duplicate entries of the keyword file. The lookup file is then stored for ~earching by users to allow effecti~e distributed control. The lookup files may be addre~sed according to data entity in a dynamic manner to allow bro~sing and selection of data value5.
Validation of the order request i~ continued in step 10 by retrie~ing the control register. The configuration matrix is retrieved in step 11 and ~he order stage identifier of the control register i~ isolated in step 12. The configuration matrix i~ addres~ed with the order ~tage identifier in s~ep 13. The order stage identifier is then incremented in ~tep 14.
This allows retrieval of the relevant control regi~ter and a set of validstion routines. These routines were initially written according to the requirements ~pecified by the prompt file.
There is.a validation routine for every data entity and they are loaded dynamically according to the entitie~ in a particular order request.
The routines are then run in step 15 and the output is stored a~ a set of True~False flags For each False flag the corresponding entry in the control register is read. A STOP v~lue cau~es the method to halt. A
WARNING value causes an error message to be di~played.
The error message is in practice queued for later display to allow both continuity and comprehensive output of all errors occurring in the system. This validation stage is illustrated in Fig. 3, in whi~h th~
relationships between routines, routine outputs, control regi~ter entries, and actions are shown.
The conf iguration ~atr~x is updated in step 16 by writing a next action value, in this case a next user.
2 1 935~32 The matrix allo~ the request to be monitored by manually updating it or ~y automatic updating according to a pre-set action sequences, the current action being indicated by a counter. This signtficantly reduces the work required and allows a greater degree of flexibility while maintaining full control. Similarly a change to the matrix may cause an error handling routine to be executed where previously another operation wa~
performed.
The method has now reached an important stage, namely initial validation of the request to prevent routing around the distributed system if invalid. The ~alidation up to this stage pro~ide~ a very effective screening fllter for decentralised purchasing.
~hen the order request has been validated it is transmitted to an order request router in step 20 and the order request rbuter receives the validated order request in step 21. The next action entry of the matrix associated with the o~der reque~t i~ retrieved in step 22 and addressed in step 23. A transmit code is identified in step 24 ~y ~election from a predefined list of a~tion codes in step 25.
An order request destination addres~ 1~ identified in step 26 by reading the nex~ action entry for destinations. Each line of the order request is then read in turn in step 27 and ~ritten to a message file in step 2~. A source identifier from the local station is read in stage 29 and written to a router slip in step 30. The router ~lip i8 attached to the message file in step 31. The use of the router slip in this way provides a full audit trail for the order request, further enhancing the level of control achieved in a distributed sy~tem.
The router slip is generated from a fixed templa~e, which is modified according to the configuration matrix and the order request. The template has a 8et of ta~ks, programmed AS o~jects. Each task has a set of rules which are run u5ing the actual ~atrix data to determine if the task applies to this order request. ~f so, the 11 ~ I `~358~
task obiect is instantiaeed. Once instantiated, each task ob~ect incorporate~ in the router slip rules ~h~ch dynamically indicate it8 active~redundant status, if ~he current user can perform it, and if not, which u~er can.
~hese rules therefore mirror those used for initial instantiation of the task objects.
The message flle and attached router slip are then di~ected to a remote station. This ls done by f irst identifying a transport protocol for a connection bet~een the local and remote stations in step 35, using operating system settings. This transport protocol may be any one of a num~er of types ~ch a~ SNA, TCP~IP or E-mail. The messa~e file and attached router slip are then encoded in step 36 according to the identified lS transpor~ protocol w~th a predefined encoding table.
This allows the order request to be easily trans~itted across any type and between a ~ariety of hardYare platforms. The message file and attached slip ~ile are receiYed in the remote ~tation in step 31. The transport protocol used for the connection between the local and remote station~ is again identified in step 38. Indlvidual bytes associated with the message file and associated router slip in are aligned in response to the tran~port protocol in step 39. ~his allows Z5 different hardware platforms using different massaging systems such a8 VIM or MAPI to be interfaced without user interven~ion.
When received by the re~ote station the me~sage file and the router slip are processed in the router of that station by retrieving appropriate action entries in the matrix in step 40. ~he entry is addressed in step 4l and an authorization code is identif ied in step 42 by comparing the addressed contents of the next action entry with the predefined list of action code~
~5 p~evio~ly used in step 25. The a~thorization code may be the conventional user password, po~ibly ~upplemented by more robust coding including key encryption.
By communication and proce~cing of the order request in thi~ way the request moves through the system very effectively, allo~ing all necessary personnel to review and approve.
An authorised order reque~t is generated in step 43 by adding an authorization code entered by an authorising S user to the order request. The order ~age identifier i~ then incremented in step 44 to indicate compliance with the validation criteria available from the matrix retrie~ed in step 11.
~ he control register for the authorised order request is regenerated in step 45 by 5electi~ely comparing portions of ~he authorised order request ~ith the reference register retrie~ed in step 7. The authorised ord~r re~uest is then validated in step 46 by retrieving the regenera~ed control register and validation routines from step 45 and retrieving the configurat~on matrix, i~olating the incremented order stage identifier produced in step 44 and addressing the configuration matrix with the isolated ~rder stage identifi~r.
Validation then takes place a~ de~cri~ed above with 2~ reference to Fig. 3 and the next action entry associated with the orter request is updated in step 48 based on the re~ult~ of the comparison.
An authorised message file is generated in step SO and a station address is appended to the attached ro~ter slip in step 51. The authorised mes~age file and ~ttached router slip are then directed to a remote station in step 52. It will be noted that the remote station ~o ~hich the files are directed in step 52 may be the station of the order supplier, a prlnter for printing an order docket or alternatlvely another station for further authorization if requiret. In this way, orders may be efficiently processed ~ithout using excessive resources. Control is also guaranteed by specifying which orders require which level of authorization u~ing the level identifier. Any station address which is appended can receive notification/reminders through the life-cycle of the order. This can occur automatically as configured initially from the fixed template.
13 ~ 7 ~
It will be appreciated that the method controls flow of order requests in a distributed system in an effective and efficient manner, irrespective of ho~ complex the system is with little or no paper handling. The configuration matrix dynamically tracks progress, particularly in relation to current and nex~ user approvals and other actions, and request/order stage.
~his provides at all times the necessary link to validate us ing the associated control register and set of validatlon routine~. The control regi~ter allow~
mask~ ng of general entity-related routines for ~pecific request~, thus allowing use of common rout~nes to a large extent and avoiding complexity and associated processor delays.
The router slip allow~ communication control after initial validation in a si~ple and effective ~anner.
Each slip is generated in a simple way ~sing the template and object instantiation rules selected by the ma~rix. These rules are then applied at all locations Z0 in the system to which the order message is directed in order to dynamically maintain control in real time.
It ~i11 also he appreciated that the text processing administrative tool allows effective dissemination of kno~ledge throughout the system. In practice, it ma~
25 for example allow knowledge held ~y a purchasing manager relating to products and suppliers to be available to u~ers at geographically remote locations.
INT~ODU~TION
~ield of the Inven~ion The present invention relates to an order processing method in a di~tributed computer s~stem.
P~ior Art Discus~ion A number of order proces~ing methods ~re known for handling customer orders. Example~ of various order proce~sing method~ are described in European Patent Nos.
EP 0 425 405 ~2 and EP 0 585 932 A2 and United ~ingdom Patent No. GB 2 265 032. While these methods address the pro~lems a~sociated with inYentOry tracking and stock control management, validation of the order is ll~ited to ensuring correct receipt of the order. EP 0 5~5 932 deccribe~ a system for performing order validation and generating shipping labels requiring minimal operator input. Additionally, it is known to provide a Gystem to facilitate electronic processing of customer orders, as described in WO 94/28497.
While such ~yste~s accurately track orders and ensure that ~ub~itted orders are correctly formatted, they do not adequately address the need to verify an operators authority to place such an orter. Further, the prior art systems do not adequately address the problems of managing orders in a distri~uted system used by per~onnel at mutually remote location~. A~ a re~ult, in larger organisations excessive re~our~es are committed to ~alidating and authorising purchase order~ prior to submission to ~uppliers This involves a large degree of paper handling. ThiR can cause processing delay~ and failure to deliver ordered items in good time.
It is an o~ect of the invention to provide an order processing method which significan~l~ reduces the level of paper handling for distributed environments. Another object is to provide more co~prehensive validation control for decentralised purchasing.
2 1 ~3582 According to the invention there i8 provided an order pro~esslng method carried out in a distributed data processing system and comprising the ~teps of:-a local station of the system receiving an order create reque~t, identifying a rele~ant order type, retrieving a prompt file associated with said order type, and prompting user input of order request data according to said prompt file;
generatlng a conf~guration matrix storing order request parameter values including the order type, required action data, and Yalidation data;
validating the request according to ~alidation rou~ines with at least some of the request data en~ities;
writing da~a of valid reque~ts to a message file and appending a router slip comprising a source identifier and a ~et of tasks derived from the configuration matrix, said tasks indicating users from which authorization is required; and transmitting the message file and the router ~lip to nodes of the distributed ~ystem until the slip records satisfactory performance of all of said tasks.
The inputting validation using the prompt file, followed by use of the configuration matrix for initial validation in the abo~e manner ensure data integrity from an early ~tage before much user time i~ required The matrix ens~res that the request i~ dynamically tracked so that it may ~e efficiently handled. Inter-relation~hip of the matrix and the ro~ter slip ensure that validation, order processing and ~ommunication are correctly and efficiently implemented. The important a~pect of the matrix is the data stored to allow tracking, not the layout - it may be in grid or simple linear formats.
In one embodi~ent, a node of the system which receives the message file and router slip:-retrieve~ from the router slip a required authorization code to allow user authorization at the node;
regenerates the order request fro~ the message file;
writes user authori~ation data to the ro~ter slip using said codes; and re-valid~te~ the o~der request according to validation routines associated with at least some of the data entities.
Thi~ en~ures control of the order authorization across remote sites. Preferably, said node performs the further step of appending a node address to the router 1~ slip, writing the order request data to a messa~e file and trans~itting said message file and router slip ~o a remote node.
In one embodiment, ~aid router slip is generated by instantiation of task objects from a template according to the configuration matrix. This allows co~prehensive control of the filips. Preferably, the task ob~ects are instantiated by applying rules using matrix data to determine if a ta~k object of the template applie~ to the particular order request. This provides for very simple and uniform slip creation.
Ideally, the rules are stored with the instantiate~ task object~, and the method comprises the further steps of dynamically determining applicability of the task ob~ects at subsequent order stages by applying the rules with current matrix da~a. This feature allows constant, dynamic, and uniform control of the slip in real time.
In one embodiment, the router slip stores task~ ~hich cause transmission of notification signals to nodes of the system. This is very advantageous for distributed 21 93~82 p~rchasing as it allows very simple and comprehensive dissemination of information.
In another e~bodiment the request is validated by:-generating a control register for the order request hy selectively comparing dat~ entitLes of the inputted order reque~t ~ith a reference register, the control register indicating r~lative importance of the entities by storing an entry indicating for each data entity that validation i~ not applicable, could result in a ~arning, or could stop the request;
validating the order reque~t by retrieving a set of validation routine8 and running each routine with respect to an order request data entity, an~
identi~ying as invalid an entity if both the routine output is false and the a~sociated control register entry indicates a warning or a request stop;
outputting an error message if the control regi~ter indicates a warning for an invalid entity; and halting t~e req~est if the control register indicates a stop for an invalid entity.
The control register thus allo~s relatively standard validation routine~ which are associated with data entities to be used throughout the distributed system.
It effectively masks them for ~ustomisation at the appropriate request stage.
In one embodiment the method comprises the further step of accessing a lookup table of relevant data to input to the order request when creating the order request. This allo~s a large degree of ~entrali~ed control in a di~tributed environment.
In one e~bodiment, the lookup table is generated ~y:-an admlnistration proce~sor of the systemparsing selected text portions of an inputted administration me~sage by iteratively identifying ~ 1 q358~
space characters in the selected text portions to isolate each word;
comparing each isolated word against a predefined list of noise word~;
ignoring isolated ~ords found in the list;
generating a keyword file ~ith isolated words and as~ociated words;
generating a lookup file from th~3 keyword file by indexing and writing non duplicate entries of the keyword f ile .
This is a very ef ~ective tool for technically capturing user '5 knowledge for dissemination throughou~ the system .
Ideally, the step of directing the me8~age file and attached router 81ip to a remote station includes the 8 tep~ of:-identifying a transport protocol for a connection between the local and remo~e stations; and encoding the me~Rage file and attached router slip in re~ponse to the identified transport protocol with a predefined encoding table.
In one embodiment, the step of decoding the me~sage file and attached rOuter slip includes the ~tep~ of:-identifying a transport protocol ~or a connection hetween the local and remote stations; and aligning bytes associated with ~he mes~age file and associated router slip in re~pon~e to the identified tr~nsport protocol.
D~TAILED DEScRIpTIoN QF TH~ INVENTIO~
~rief De3cription of ~he Drawinqs The invention will be ~ore clearly understood from the following description thereof, given ~y way of example only with reference to the acco~panying drawing in which:-Fig. l(a) and l(b) are together a flo~ diagram of anorder processing method of the invention, Fig. 2(a) and 2(b) are illustrations of data input screen~ displayed by a system carrying out t~e method, and Fig. 3 is a table showing relationships between va1idation routine~ a control register and validation actions.
Pescription o~ ~he P~eferred Em~odi~e~ts Referring to Figs. l~a) and l(b) there i~ illu~trated an order processing method according to the invention carried out in a di~tri~uted computer system. The system may be of any suitable distributed type having interconnected node~ or stations. Conventional microprocessors and LAN links have suffL~ient processing and com~unication~ capabilities. Typical syste~s include Intranet and Internet systems using such languages as Java~ and Java~ virtual machines running on ~uch platforms a~ Hindows '95~, Solarus~, HPUX~ with browser-baset front ends. The method ma~ also be run on a Lh~ or WAN with any de6ired number of machines, subject to capacity. In this specification ~nodes" or "statiOnS" may be physical or logical. For example, a node may be the current location of a u~er, in~tead of a physical machine.
An order create ~equest is received from a user at a local station in step l. ~he order request type associated ~ith the order create request of step l is ~5 identified in ~tep 2 by comparing the order request type with a number of predefined, permitted order reque~t types. ~hi~ order re~uest type might typically be an order request for office ~tationary requiring little aut~orization, or a ma~or capieal expenditure request necessitating many layers of authorization. A sample of a displayed list of order types is ~hown in Fig.
2(a).
A prompt file associated with the order request type identified in stage 2 i~ retrieved in stage 3 and used to prompt the user in stage 4. These prompts are therefore specific to the identified order request type, penmitting the user eo input only necess~ry order request data without having to filter out unnecessary detail. A screen for a prompt file is shown in Fig~
2~b).
When all of the request data has been entered, the order re~est is submitted in step 5 by activating a validation controller. The local station then generates a control register in ~tep 6 for the order reque~t. The control regi~ter is generated by selecting each data entity of the inputted order re~uest in turn and comparing it with the appropriate section of a reference register retrie~ed in seep 7. Portions of the request which are validated may include validation of suppliers, credit card or spend lLmits among cthers. The ~alidation is achieved by generating a configuration matri~ for the order ~equest. ~he matrix has a set of parameter values for the order request including an order stage identifier, the order type, and action lists, including user li~t~. Thus, the matrix dynamically tracks progress of an order request at all times and allows selection of appropriate routines and data in real time according to busine~s policy and rules. This is very important a~ it allows real time control in a distributed environment The current ~atr~x is used to automatically ~elect the reference register which i8 appropriate, the matrix itself being retrieYed using relational database links with the order request identifier.
8 21 q3~82 The control register is a set of control flag , one per data entity. The possible flag value~ are:-- Not applicable - Warning - Stop - Stop and display error message Additional control flags co~ld also be ~ed.
Becau~e multiple levels of validation are used, the method allows a large degree of flexibility to help ensure the order is processed ~o the maximum extent throuqh the distributed system without sacrificing data integrity. The control register ifi linked by a relational database link to the configuration matrix in step ~ and an order &tage identifier is added in step 9 This data structure is indexed by a dynamic pointer array po~n~ing to parent~child tags, each having an off~et value and a length. The data it~elf comprises ASCII characters, encoded wit~ a ~imple algorithm such as one applying a constant character offset. The 2~ parent/child relationship allows a hierarchial linkage.
The order stage identifier is u~ed in subsequent validation to determine the i~portance of validation failures. For example if a supplier is not found for a low co~t, low risk item then the reque~t may be allowed to proceed however in validation of greater value items the absence of an approved supplier may cause rejection of the request.
At this stage, it is timely to describe a general administrati~e tool for ef fecti~e dissemination of processing control throughou~ the ~y~tem. An ad~inistrator input~ a text message relating to a ~eneral data entity such as "supplier". This text reflects the administrator's knowledge of the entity.
The workstation i5 typically, but not necessarily, a file ~erver or other host. Selected portion~ of the text are parsed in step 1~0 by iterati~ely identifying sp~ce characters in the ~elected text portions to isolate each word. Isolated words are compared again~t a predeined list of noi~e w~rds ~n step 101 dnd words ~ 1 935~
matched to entries on the list are ignored. A keyword file with isolated word~ not found in the l~t is genera~ed in step 102. Each word i~ linked with a data value, such a~ a particular supplier being linked with a produ~t. A lookup file i~ generated from the keyword file in step 103 by indexing and writing non duplicate entries of the keyword file. The lookup file is then stored for ~earching by users to allow effecti~e distributed control. The lookup files may be addre~sed according to data entity in a dynamic manner to allow bro~sing and selection of data value5.
Validation of the order request i~ continued in step 10 by retrie~ing the control register. The configuration matrix is retrieved in step 11 and ~he order stage identifier of the control register i~ isolated in step 12. The configuration matrix i~ addres~ed with the order ~tage identifier in s~ep 13. The order stage identifier is then incremented in ~tep 14.
This allows retrieval of the relevant control regi~ter and a set of validstion routines. These routines were initially written according to the requirements ~pecified by the prompt file.
There is.a validation routine for every data entity and they are loaded dynamically according to the entitie~ in a particular order request.
The routines are then run in step 15 and the output is stored a~ a set of True~False flags For each False flag the corresponding entry in the control register is read. A STOP v~lue cau~es the method to halt. A
WARNING value causes an error message to be di~played.
The error message is in practice queued for later display to allow both continuity and comprehensive output of all errors occurring in the system. This validation stage is illustrated in Fig. 3, in whi~h th~
relationships between routines, routine outputs, control regi~ter entries, and actions are shown.
The conf iguration ~atr~x is updated in step 16 by writing a next action value, in this case a next user.
2 1 935~32 The matrix allo~ the request to be monitored by manually updating it or ~y automatic updating according to a pre-set action sequences, the current action being indicated by a counter. This signtficantly reduces the work required and allows a greater degree of flexibility while maintaining full control. Similarly a change to the matrix may cause an error handling routine to be executed where previously another operation wa~
performed.
The method has now reached an important stage, namely initial validation of the request to prevent routing around the distributed system if invalid. The ~alidation up to this stage pro~ide~ a very effective screening fllter for decentralised purchasing.
~hen the order request has been validated it is transmitted to an order request router in step 20 and the order request rbuter receives the validated order request in step 21. The next action entry of the matrix associated with the o~der reque~t i~ retrieved in step 22 and addressed in step 23. A transmit code is identified in step 24 ~y ~election from a predefined list of a~tion codes in step 25.
An order request destination addres~ 1~ identified in step 26 by reading the nex~ action entry for destinations. Each line of the order request is then read in turn in step 27 and ~ritten to a message file in step 2~. A source identifier from the local station is read in stage 29 and written to a router slip in step 30. The router ~lip i8 attached to the message file in step 31. The use of the router slip in this way provides a full audit trail for the order request, further enhancing the level of control achieved in a distributed sy~tem.
The router slip is generated from a fixed templa~e, which is modified according to the configuration matrix and the order request. The template has a 8et of ta~ks, programmed AS o~jects. Each task has a set of rules which are run u5ing the actual ~atrix data to determine if the task applies to this order request. ~f so, the 11 ~ I `~358~
task obiect is instantiaeed. Once instantiated, each task ob~ect incorporate~ in the router slip rules ~h~ch dynamically indicate it8 active~redundant status, if ~he current user can perform it, and if not, which u~er can.
~hese rules therefore mirror those used for initial instantiation of the task objects.
The message flle and attached router slip are then di~ected to a remote station. This ls done by f irst identifying a transport protocol for a connection bet~een the local and remote stations in step 35, using operating system settings. This transport protocol may be any one of a num~er of types ~ch a~ SNA, TCP~IP or E-mail. The messa~e file and attached router slip are then encoded in step 36 according to the identified lS transpor~ protocol w~th a predefined encoding table.
This allows the order request to be easily trans~itted across any type and between a ~ariety of hardYare platforms. The message file and attached slip ~ile are receiYed in the remote ~tation in step 31. The transport protocol used for the connection between the local and remote station~ is again identified in step 38. Indlvidual bytes associated with the message file and associated router slip in are aligned in response to the tran~port protocol in step 39. ~his allows Z5 different hardware platforms using different massaging systems such a8 VIM or MAPI to be interfaced without user interven~ion.
When received by the re~ote station the me~sage file and the router slip are processed in the router of that station by retrieving appropriate action entries in the matrix in step 40. ~he entry is addressed in step 4l and an authorization code is identif ied in step 42 by comparing the addressed contents of the next action entry with the predefined list of action code~
~5 p~evio~ly used in step 25. The a~thorization code may be the conventional user password, po~ibly ~upplemented by more robust coding including key encryption.
By communication and proce~cing of the order request in thi~ way the request moves through the system very effectively, allo~ing all necessary personnel to review and approve.
An authorised order reque~t is generated in step 43 by adding an authorization code entered by an authorising S user to the order request. The order ~age identifier i~ then incremented in step 44 to indicate compliance with the validation criteria available from the matrix retrie~ed in step 11.
~ he control register for the authorised order request is regenerated in step 45 by 5electi~ely comparing portions of ~he authorised order request ~ith the reference register retrie~ed in step 7. The authorised ord~r re~uest is then validated in step 46 by retrieving the regenera~ed control register and validation routines from step 45 and retrieving the configurat~on matrix, i~olating the incremented order stage identifier produced in step 44 and addressing the configuration matrix with the isolated ~rder stage identifi~r.
Validation then takes place a~ de~cri~ed above with 2~ reference to Fig. 3 and the next action entry associated with the orter request is updated in step 48 based on the re~ult~ of the comparison.
An authorised message file is generated in step SO and a station address is appended to the attached ro~ter slip in step 51. The authorised mes~age file and ~ttached router slip are then directed to a remote station in step 52. It will be noted that the remote station ~o ~hich the files are directed in step 52 may be the station of the order supplier, a prlnter for printing an order docket or alternatlvely another station for further authorization if requiret. In this way, orders may be efficiently processed ~ithout using excessive resources. Control is also guaranteed by specifying which orders require which level of authorization u~ing the level identifier. Any station address which is appended can receive notification/reminders through the life-cycle of the order. This can occur automatically as configured initially from the fixed template.
13 ~ 7 ~
It will be appreciated that the method controls flow of order requests in a distributed system in an effective and efficient manner, irrespective of ho~ complex the system is with little or no paper handling. The configuration matrix dynamically tracks progress, particularly in relation to current and nex~ user approvals and other actions, and request/order stage.
~his provides at all times the necessary link to validate us ing the associated control register and set of validatlon routine~. The control regi~ter allow~
mask~ ng of general entity-related routines for ~pecific request~, thus allowing use of common rout~nes to a large extent and avoiding complexity and associated processor delays.
The router slip allow~ communication control after initial validation in a si~ple and effective ~anner.
Each slip is generated in a simple way ~sing the template and object instantiation rules selected by the ma~rix. These rules are then applied at all locations Z0 in the system to which the order message is directed in order to dynamically maintain control in real time.
It ~i11 also he appreciated that the text processing administrative tool allows effective dissemination of kno~ledge throughout the system. In practice, it ma~
25 for example allow knowledge held ~y a purchasing manager relating to products and suppliers to be available to u~ers at geographically remote locations.
Claims (12)
1. An order processing method carried out in a distributed data processing system and comprising the steps of:-a local station of the system receiving an order create request, identifying a relevant order type, retrieving a prompt file associated with said order type, and prompting user input of order request data according to said prompt file;
generating a configuration matrix storing order request parameter values including the order type, required action data, and validation data;
validating the request according to validation routines with at least some of the request data entities;
writing data of valid requests to a message file and appending a router slip comprising a source identifier and a set of tasks derived from the configuration matrix, said tasks indicating users from which authorization is required; and transmitting the message file and the router slip to nodes of the distributed system until the slip records satisfactory performance of all of said tasks.
generating a configuration matrix storing order request parameter values including the order type, required action data, and validation data;
validating the request according to validation routines with at least some of the request data entities;
writing data of valid requests to a message file and appending a router slip comprising a source identifier and a set of tasks derived from the configuration matrix, said tasks indicating users from which authorization is required; and transmitting the message file and the router slip to nodes of the distributed system until the slip records satisfactory performance of all of said tasks.
2. An order processing method as claimed in claim 1, wherein a node of the system which receives the message file and router slip:-retrieves from the router slip a required authorization code to allow user authorization at the node;
regenerates the order request from the message file;
writes user authorization data to the router slip using said codes: and re-validates the order request according to validation routines associated with at least some of the data entities.
regenerates the order request from the message file;
writes user authorization data to the router slip using said codes: and re-validates the order request according to validation routines associated with at least some of the data entities.
3. An order processing method as claimed in claim 2, wherein said node performs the further step of appending a node address to the router slip, writing the order request data to a message file and transmitting said message file and router slip to a remote node.
4. An order processing method as claimed in claim 1, wherein said router slip is generated by instantiation of task objects from a template according to the configuration matrix.
5. An order processing method as claimed in claim 1, wherein said router slip is generated by instantiation of task objects from a template according to the configuration matrix, and wherein the task objects are instantiated by applying rules using matrix data to determine if a task object of the template applies to the particular order request.
6. An order processing method as claimed in claim 5, wherein the rules are stored with the instantiated task objects, and the method comprises the further steps of dynamically determining applicability of the task objects at subsequent order stages by applying the rules with current matrix data.
7. An order processing method as claimed in claim 1, wherein the router slip stores tasks which cause transmission of notification signals to nodes of the system.
8. An order processing method as claimed in claim 1, wherein the request is validated by:-generating a control register for the order request by selectively comparing data entities of the inputted order request with a reference register, the control register indicating relative importance of the entities by storing an entry indicating for each data entity that validation is not applicable, could result in a warning, or could stop the request;
validating the order request by retrieving a set of validation routines and running each routine with respect to an order request data entity, and identifying as invalid an entity if both the routine output is false and the associated control register entry indicates a warning or a request stop;
outputting an error message if the control register indicates a warning for an invalid entity; and halting the request if the control register indicates a stop for an invalid entity.
validating the order request by retrieving a set of validation routines and running each routine with respect to an order request data entity, and identifying as invalid an entity if both the routine output is false and the associated control register entry indicates a warning or a request stop;
outputting an error message if the control register indicates a warning for an invalid entity; and halting the request if the control register indicates a stop for an invalid entity.
9. An order processing method as claimed in claim 1, comprising the further step of accessing a lookup table of relevant data to input to the order request when creating the order request.
10. An order processing method as claimed in claim 9 wherein the lookup table is generated by:-an administration processor of the system parsing selected text portions of an inputted administration message by iteratively identifying space characters in the selected text portions to isolate each word;
comparing each isolated word against a predefined list of noise words;
ignoring isolated words found in the list;
generating a keyword file with isolated words and associated words;
generating a lookup file from the keyword file by indexing and writing non duplicate entries of the keyword file.
comparing each isolated word against a predefined list of noise words;
ignoring isolated words found in the list;
generating a keyword file with isolated words and associated words;
generating a lookup file from the keyword file by indexing and writing non duplicate entries of the keyword file.
11. An order processing method as claimed in claim 1 wherein the step of directing the message file and attached router slip to a remote station includes the steps of:-identifying a transport protocol for a connection between the local and remote stations; and encoding the message file and attached router slip in response to the identified transport protocol with a predefined encoding table.
12. An order processing method as claimed in claim 1 wherein the step of decoding the message file and attached router slip includes the steps of:-identifying a transport protocol for a connection between the local and remote stations; and aligning bytes associated with the message file and associated router slip in response to the identified transport protocol.
Applications Claiming Priority (4)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| IE950977A IE79445B1 (en) | 1995-12-21 | 1995-12-21 | An order processing method |
| IE950977 | 1995-12-21 | ||
| IE960040 | 1996-01-18 | ||
| IES960040 | 1996-01-18 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CA2193582A1 true CA2193582A1 (en) | 1997-06-22 |
Family
ID=26319869
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA002193582A Abandoned CA2193582A1 (en) | 1995-12-21 | 1996-12-20 | Order processing method |
Country Status (2)
| Country | Link |
|---|---|
| US (1) | US5937393A (en) |
| CA (1) | CA2193582A1 (en) |
Families Citing this family (31)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH1166428A (en) * | 1997-08-25 | 1999-03-09 | Sharp Corp | Vending managing device |
| US6363358B1 (en) * | 1998-08-12 | 2002-03-26 | Aw Printing | Integrated hangtag production system |
| US6704749B2 (en) | 1998-08-12 | 2004-03-09 | Aw Printing, Inc. | Integrated hangtag production system |
| US7353194B1 (en) | 1999-03-02 | 2008-04-01 | Alticor Investments, Inc. | System and method for managing recurring orders in a computer network |
| AU769742B2 (en) | 1999-03-02 | 2004-02-05 | Amway Corp. | Electronic commerce transactions within a marketing system that may contain a membership buying opportunity |
| AU6780200A (en) * | 1999-08-20 | 2001-03-19 | Eproductivity.Com, Inc. | Business method and processing system |
| US6876991B1 (en) | 1999-11-08 | 2005-04-05 | Collaborative Decision Platforms, Llc. | System, method and computer program product for a collaborative decision platform |
| US7318047B1 (en) * | 1999-12-29 | 2008-01-08 | Pitney Bowes Inc. | Method and apparatus for providing electronic refunds in an online payment system |
| US7818285B1 (en) | 2000-01-10 | 2010-10-19 | Fedex Office And Print Services, Inc. | System and method of using a sales management system to generate printed products |
| US7113959B1 (en) | 2000-01-10 | 2006-09-26 | Imagex, Inc. | System and method of using human resources data to generate printed products |
| US7110975B2 (en) * | 2000-01-27 | 2006-09-19 | Marks De Chabris Gloriana | Order matching system |
| JP2001216391A (en) * | 2000-02-02 | 2001-08-10 | Seiko Epson Corp | Method and system for managing reception of order |
| US20010056381A1 (en) * | 2000-06-14 | 2001-12-27 | Boeke David A. | Cooperative medical shopping system |
| US7043457B1 (en) | 2000-06-28 | 2006-05-09 | Probuild, Inc. | System and method for managing and evaluating network commodities purchasing |
| US20050049937A1 (en) * | 2000-08-16 | 2005-03-03 | Aaron Sanders | Business method and processing system |
| US20030074377A1 (en) * | 2000-12-22 | 2003-04-17 | Aman Gupta | Method and apparatus for reporting the status of work in progress |
| AU2002239916A1 (en) * | 2001-01-15 | 2002-07-24 | Ipower Logistics, Llc | Buyer managed order transmitting system and method |
| US7039604B1 (en) * | 2001-02-15 | 2006-05-02 | Cisco Technology, Inc. | Multi-vendor integration process for internet commerce |
| US20020116241A1 (en) * | 2001-02-21 | 2002-08-22 | Virender Sandhu | Enterprise resource planning system for ordering, tracking and shipping goods from a seller to a buyer |
| JP2002288444A (en) * | 2001-03-26 | 2002-10-04 | Toshiba Corp | Method and system for mask transaction |
| US7054901B2 (en) * | 2001-05-31 | 2006-05-30 | Juniper Networks, Inc. | Network management interface with selective rendering of output |
| US7072946B2 (en) | 2001-05-31 | 2006-07-04 | Juniper Networks, Inc. | Network router management interface with API invoked via login stream |
| AUPR727101A0 (en) * | 2001-08-28 | 2001-09-20 | Conrick, Patrick Michael | Process analysis tool |
| US7111206B1 (en) | 2001-09-19 | 2006-09-19 | Juniper Networks, Inc. | Diagnosis of network fault conditions |
| US7991386B2 (en) * | 2003-11-14 | 2011-08-02 | E2Interactive, Inc. | System and method for authorizing the activation of a communication device |
| US20050108176A1 (en) * | 2003-04-30 | 2005-05-19 | Jarol Scott B. | Configurable rules based content item consumption |
| US20070094129A1 (en) * | 2003-12-19 | 2007-04-26 | E2Interactive, Inc. D/B/A E2Interactive, Inc. | System and method for adding value to a stored-value account using provider specific pin |
| US8959516B2 (en) | 2007-07-30 | 2015-02-17 | International Business Machines Corporation | Methods and systems for coordinated financial transactions in distributed and parallel environments |
| US8898669B2 (en) * | 2007-07-30 | 2014-11-25 | International Business Machines Corporation | Methods and systems for coordinated transactions |
| US8370206B2 (en) | 2007-09-14 | 2013-02-05 | Keefe Commissary Network, L.L.C. | Method, medium, and system for an inmate privilege kiosk |
| US10062075B2 (en) | 2013-11-04 | 2018-08-28 | E2Interactive, Inc. | Systems and methods for using a dual function medical benefits card |
Family Cites Families (23)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US4016405A (en) * | 1975-06-09 | 1977-04-05 | Diebold, Incorporated | Card validation, method and system |
| US4386266A (en) * | 1980-02-11 | 1983-05-31 | International Business Machines Corporation | Method for operating a transaction execution system having improved verification of personal identification |
| JPH0642244B2 (en) * | 1982-07-09 | 1994-06-01 | オムロン株式会社 | Margin transaction processing device |
| GB2146814A (en) * | 1983-09-17 | 1985-04-24 | Ibm | Electronic fund transfer systems |
| JPH0789394B2 (en) * | 1986-11-14 | 1995-09-27 | オムロン株式会社 | POS terminal device |
| US4891503A (en) * | 1988-03-29 | 1990-01-02 | Gascard, Inc. | Distributed authorization system |
| US4947028A (en) * | 1988-07-19 | 1990-08-07 | Arbor International, Inc. | Automated order and payment system |
| EP0425405A3 (en) * | 1989-10-23 | 1992-01-22 | International Business Machines Corporation | An automated customer order promising and confirming method |
| US5231570A (en) * | 1990-12-11 | 1993-07-27 | Lee Gerritt S K | Credit verification system |
| CA2059078C (en) * | 1991-02-27 | 1995-10-03 | Alexander G. Fraser | Mediation of transactions by a communications system |
| US5490251A (en) * | 1991-08-09 | 1996-02-06 | First Data Resources Inc. | Method and apparatus for transmitting data over a signalling channel in a digital telecommunications network |
| CA2091640A1 (en) * | 1991-09-19 | 1994-09-16 | Jerry R. Martinez | Method and apparatus for validating credit information during home delivery of order |
| US5255182A (en) * | 1992-01-31 | 1993-10-19 | Visa International Service Association | Payment card point-of-sale service quality monitoring system, apparatus, and method |
| US5315508A (en) * | 1992-09-03 | 1994-05-24 | Monarch Marking System | Label generating and data tracking system for processing purchase orders |
| US5289371A (en) * | 1992-09-11 | 1994-02-22 | Memorylink, Inc. | System and method for routing data and communications |
| US5598462A (en) * | 1992-09-25 | 1997-01-28 | Truemner; Michael A. | Telecommunications network routing |
| JPH08500201A (en) * | 1993-05-20 | 1996-01-09 | ムーア．ビジネス．フォームス．インコーポレイテッド | An integrated computer network that guides customer orders to various suppliers through a centralized computer |
| US5666493A (en) * | 1993-08-24 | 1997-09-09 | Lykes Bros., Inc. | System for managing customer orders and method of implementation |
| US5570291A (en) * | 1994-08-24 | 1996-10-29 | Wallace Computer Services, Inc. | Custom product estimating and order processing system |
| US5808894A (en) * | 1994-10-26 | 1998-09-15 | Optipat, Inc. | Automated ordering method |
| US5678010A (en) * | 1995-06-07 | 1997-10-14 | Compuserve Incorporated | Automated routing of messages over a network |
| US5758327A (en) * | 1995-11-01 | 1998-05-26 | Ben D. Gardner | Electronic requisition and authorization process |
| US5793028A (en) * | 1996-06-24 | 1998-08-11 | Fred N. Gratzon | Electronic transaction security system |
-
1996
- 1996-12-20 CA CA002193582A patent/CA2193582A1/en not_active Abandoned
- 1996-12-23 US US08/779,951 patent/US5937393A/en not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| US5937393A (en) | 1999-08-10 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CA2193582A1 (en) | Order processing method | |
| US5410646A (en) | System and method for creating, processing, and storing forms electronically | |
| US7933860B2 (en) | Method and system for electronic archival and retrieval of electronic communications | |
| US5557780A (en) | Electronic data interchange system for managing non-standard data | |
| US6817008B2 (en) | System and method for enterprise-wide business process management | |
| US7133882B1 (en) | Method and apparatus for creating and using a master catalog | |
| US20070055586A1 (en) | Computer program product, system and methods for tracking supply chain items | |
| US20050120061A1 (en) | Updating and maintaining data in a multi-system network using asynchronous message transfer | |
| KR20040096613A (en) | System and method for web-based processing of customs information | |
| US20020143862A1 (en) | Method and apparatus for transferring information between a source and a destination on a network | |
| US8190494B2 (en) | Order processing analysis tool | |
| CN101124578A (en) | Sharable multi-tenant reference data utility and repository, including value enhancement and on-demand data delivery and methods of operation | |
| CN1166216A (en) | Computer system for data management and method for operating said system | |
| US20020073057A1 (en) | Software distribution system and method | |
| CN110032544A (en) | The right management method and its cloud data-storage system of cloud service | |
| CA3154602A1 (en) | A system and a method for generating and managing machine executable digital contracts | |
| US20100299272A1 (en) | Workflow status tracking and reporting | |
| US20040088222A1 (en) | Member management server system and member management method | |
| US20050120355A1 (en) | Updating data in a multi-system network that utilizes asynchronous message transfer | |
| US20050071246A1 (en) | Apparatus for exchanging compliance information | |
| US20220365912A1 (en) | Data Quality Management System | |
| WO1999033007A1 (en) | System and method for collaborative data sharing | |
| JP2008250519A (en) | Business negotiation support system and business negotiation support server | |
| CN1574758A (en) | Method and apparatus for performing batch updates on records | |
| CA2324732C (en) | Web-based application for inbound message synchronization |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| EEER | Examination request | ||
| FZDE | Dead |