US 20070205280 A1
A method and system for collecting, storing, and processing automatic identification code information includes receiving automatic identification code information and parsing it based on stored definitions for automatic identification codes and/or automatic identification code standards. Various data configurations may be used to store definitions and to facilitate parsing of raw automatic identification code data. For example, a first component may be used for generally defining one or more automatic identification code standards and a second component may be used for detailed information regarding code definitions, such as information relating to code segments. In addition, the system may facilitate further processing of parsed automatic identification code information, such as for cycle counting or parts movement of inventory.
1. A method for managing automatic identification of items using an executable computer-implemented framework for defining and administering standardized item identifiers, the method comprising:
providing a flexible data model for storing information defining one or more standardized identification schemes, wherein configured to define the one or more standardized identification schemes during execution of the computer-implemented framework by virtue of being configured to define a first data structure component,
the first data structure component is configured to define multiple automatic identification code standards, and
each instance of the first data structure component defines a distinct automatic identification code standard or a subset of a distinct automatic identification code standard; and
providing a second data model for storing information associated with items that are identifiable using the executable computer-implemented framework, wherein the second data model is configured to facilitate defining the one or more standardized identification schemes during execution of the computer-implemented framework by virtue of being configured to define a second data structure component,
the second data structure component is configured to define multiple automatic identification code segments,
each instance of the second data structure component is linked to an instance of the first component, and
each instance of the second data structure component defines at least one identifiable segment of an automatic identification code
2. In a computer system, a method for collecting, storing, and processing automatic identification code information, the method comprising:
providing a first data structure component configured to define multiple automatic identification code standards, wherein each instance of the first data structure component defines a distinct automatic identification code standard or a subset of a distinct automatic identification code standard; and
providing a second data structure component configured to define multiple automatic identification code segments, wherein each instance of the second data structure component is linked, at least virtually, to an instance of the first component, and wherein each instance of the second data structure component defines at least one identifiable segment of an automatic identification code.
3. The method of
4. The method of
5. The method of
6. The method of
7. The method of
8. A method of processing automatic identification codes, the method comprising:
receiving automatic identification code information via a device for inputting automatic identification codes, wherein the received automatic identification code information has a structure; and
parsing the received automatic identification code information, wherein the parsing is based on at least one stored automatic information code definition, and wherein the parsing comprises:
determining, based on the structure of the received identification code information, an automatic identification code definition associated with the automatic identification code;
isolating segments in the received automatic identification code; and
evaluating each of the isolated segments, comprising matching information associated with each of the isolated segments with attributes of the at least one stored automatic information code definition.
9. The method of
10. The method of
11. The method of
12. The method of
13. The method of
14. The method of
15. An automatic information code management system comprising:
an automatic information code input device for inputting raw data associated with automatic information codes; and
a service for processing the raw data, wherein the service performs actions comprising:
preparing the raw data for parsing;
parsing the raw data into identifiable segments, wherein the parsing of the raw data into identifiable segments comprises
evaluating whether one or more characters in the raw data corresponds to at least one character identified in an automatic information code management definition; and
creating an output set for the parsed data, wherein the output set is configurable for providing information related to the raw data to one or more applications for further processing.
16. The system of
17. The system of
18. The system of
19. The system of
20. The system of
21. The system of
22. A computer-readable medium comprising a data structure for use in a method for integrating automatic information into a data processing system, the method comprising:
receiving automatic identification code information via a device for inputting automatic identification codes; and
parsing the received automatic identification code information, wherein the parsing comprises:
determining, based on prefix data in the received identification code information, an automatic identification code definition associated with the automatic identification code; and
evaluating one or more segments of the received identification code based, at least in part, on the automatic identification code definition, wherein the evaluating comprises matching information associated with each of the segments of the received identification code with stored data for defining the automatic identification code.
23. The computer-readable medium of
24. The computer-readable medium of
25. The computer-readable medium of
26. A system for processing automatic identification codes, the system comprising:
means for receiving automatic identification code information;
means for parsing the received automatic identification code information, wherein the parsing comprises:
determining, based on the structure of the received automatic identification code information, an automatic identification code standard associated with the automatic identification code;
isolating segments in the received automatic identification code; and
evaluating each of the isolated segments, comprising matching information associated with each of the segments of the received automatic identification code with stored data for defining the automatic identification code; and
means for processing the parsed automatic identification code information, wherein the processing comprises integrating the automatic identification code information into a system for managing information.
27. The system of
28. The system of
29. A method in a computer for processing automatic identification code data information, the method comprising:
receiving information associated with a first identification code, wherein the first identification code information is associated with an item unit, wherein processing of the first identification code information is dependent on receiving information associated with one or more additional identification codes, and wherein the one or more additional identification codes are also associated with the item unit;
storing the received information;
receiving information associated with the one or more additional identification codes; and
processing the first identification code based, in part, on the information associated with the one or more additional identification codes.
30. The method of
This invention relates generally to the area of automatic identification technology and more specifically to the area of flexibly managing automatic identification information, such as bar codes.
Makers, distributors, sellers, and buyers of commercial goods often rely on bar codes or similar automatic identification techniques to identify products. In general, automatic identification techniques provide a way to quickly identify products, items, records, or other entities marked with tags or other identifying indicia using an input device (e.g., a bar code scanner). For example, the use of bar codes and other automatic identification techniques facilitates data entry. In such cases, an operator can use a scanning device to scan bar code symbols on products or product packaging into a computer system that recognizes each bar code as being linked to a specified product.
In some industries, identification tags (e.g., printed bar codes) and their associated structures are standardized to include specific information and formatting. For example, the health industry has developed a specialized Health Industry Bar Code (HIBC) standard. Details regarding health industry bar code standards can be found in an American National Standards Institute document entitled “The Health Industry Bar Code (HIBC) Supplier Labeling Standard” (1997).
Most known bar code standards are either location-based or code-based. With location-based bar codes, the order of the information presented in the bar code plays a role in how the bar code is interpreted. The data contained in the bar code and its sequence within the bar code are predetermined. With code-based bar codes, the order and presence (or absence) of the information presented in the bar code does not matter. In this type of design, special codes precede each data element to indicate the type, meaning, and format of data to follow. An example of a code-based bar code scheme is UCC/EAN (see, e.g., http://www.uc-council.org/ean_ucc_system/index.html).
With UCC/EAN, the bar code is divided into segments. Each segment is either fixed in length or variable in length. Segments with variable length either end with a separator or are, alternatively, located at the end of a data sequence.
Once scanned or otherwise inputted into temporary electronic storage, bar codes are typically processed or stored by a computer. To ensure that the data contained in the bar code is meaningful, the computer typically has some way of recognizing each bar code it receives as input. Enabling such recognition usually involves a user performing systematic data entry and data identification for a series of items read by the device. In most cases, a user conducts an initial scan of raw bar code data into the application and then provides matching product information for the raw bar code data. This type of solution is inflexible, as it does not allow for customization to handle new standards and requires excess data entry. Alternatively, a user may utilize a hard code system designed to interpret a specific bar code symbology. This solution, too, is inflexible, requiring separate solutions for each symbology as well as an inability to represent custom schemes or make changes in a runtime environment.
Bar code information can be used in many practical applications. Cycle counting is one example of a practical use for bar code data. In some industries, customers or purchasers of goods may store inventory owned by the manufacturer. This type of inventory is sometimes referred to as a “consignment inventory.” Manufacturers typically replenish consignment inventories on an as-needed basis. One way to track consignment inventories involves the use of cycle counts.
Cycle counting typically involves performing a series of steps that result in substantial administrative effort. In a typical cycle counting process, a user (e.g., sales representative, service engineer, or other operator) performs cycle counting on a customer's premises. To begin the process, an inventory manager creates lists of expected inventory on paper or using a word processing application and then mails, faxes, or otherwise transmits the lists to a user. The user counts the physical inventory on hand and manually updates the list with additions, corrections, and deletions. He or she manually identifies expired products and products nearing their expiration dates. The user then faxes the updated list back to the inventory manager who updates an electronic record. The revised inventory may be used to replenish inventory locations and generate invoices.
This technique for cycle counting often results in outdated and/or otherwise inaccurate inventory information. In the case of negotiated pricing benefits contingent on inventory stocking or usage levels, the process may also result in pricing benefits being delivered to customers without current inventory visibility. In addition, the manual data entry typically resorted to with this technique can be tedious, inaccurate, and inefficient. This is especially true in the case where a given product has multiple assets that each require unique identification codes. Alternatively, bar code information may be used in physical inventory counting, patient information, or any other application benefiting from either rapid data entry or increased data accuracy.
The invention will now be described with respect to various embodiments. The following description provides specific details for a thorough understanding of, and enabling description for, these embodiments of the invention. However, one skilled in the art will understand that the invention may be practiced without these details. In other instances, well-known structures and functions have not been shown or described in detail to avoid unnecessarily obscuring the description of the embodiments of the invention.
It is intended that the terminology used in the description presented be interpreted in its broadest reasonable manner, even though it is being used in conjunction with a detailed description of certain specific embodiments of the invention. Certain terms may even be emphasized below; however, any terminology intended to be interpreted in any restricted manner will be overtly and specifically defined as such in this Detailed Description section.
In one embodiment, automatic identification code information, such as bar code information, is defined, administered, and managed using a system recognizing a flexible and declarative data structure for storing automatic identification code definitions. The system and its associated data structures facilitate rapid parsing, validation, and insertion of data into applications for processing automatic identification code information. For example, once bar code data is scanned and parsed, it can be stored as records in table(s) and used in cycle counting and/or parts movement applications, as well as other inventory-related applications. In some cases, the system and associated applications can run, at least partially, on handheld devices. Because the system provides a flexible data structure, it becomes possible to easily define new automatic identification code schemes, even in a runtime environment (e.g., without recoding).
Because there are so many possible variations for automatic identification code information and there are multiple known bar code standards, the system provides an environment that allows administrative users to generically define one or more automatic identification codes. The system also supports various input/reader devices, including both “dumb” and “smart” devices.
Once automatic identification code information is inputted into the system (e.g., via a bar code reader), the system parses the automatic identification code information based on any available automatic identification code definitions. After it is parsed, the automatic identification code information can be used to provide general item or entity information (e.g., product information), as well as more specific information about an item or entity (such as the lot in which a product was manufactured or sterilized, the expiration data for a particular batch of products, etc.).
To provide an end user with information about inputted automatic identification code information, the system can provide various views or screens, including a view that shows information captured in a scanning/input event. Similarly, the results of an inventory or cycle count can be displayed on a screen showing counts for products, items, or entities. From the various views or screens, users can drill further into each product, obtaining additional information for a particular instance of a product, item, or entity, also called an asset.
Such views or screens can be customized for various product types and various industries. For example, a medical bar code view could be created that shows product and asset information specific to medical products, including both generic and specific information about assets. With respect to certain products, each asset may or may not be uniquely identifiable. However, using a combination of product bar code information and asset bar code information, a unique asset can be identified.
Automatic identification code information can be used to track the states of products. In this way, the system can provide real-time data validation capabilities. For example, instances of products (e.g., assets) can be associated with status information such as “good,” “expired,” and “short-dated” (i.e., about to expire). In some embodiments, audible alerts may be used to signal different states. For example, an identifiable audible alert may be generated when an expired object is scanned. This distinguishes it from an item that is “good.” In this way, audible alerts may be used to facilitate rapid data input by enabling audio as well as visual assessment of an asset's state. In addition, audible alerts may be used to identify errors, such as errors in scanning. In this way, the operator of the scanning device can take immediate action to correct an error. To provide for audible alerts and other alerts regarding scanned products, mappings between various events and audio files can be created.
In general, the system is automated and provides a rapid data entry mechanism for cycle counting and parts movement. The system may support automatic identification code standards, such as UCC/EAN and HIBC standards, “out of the box.” It may also enable easy and efficient representation of additional automatic identification code standards, including custom code schemes. The system may handle information relating to on-hand quantities, usage, variance, and contracted consignment levels of cross-product hierarchies. The system may provide comprehensive real-time results as well as insight into customer purchasing behaviors. The system may be wireless enabled, allowing for asynchronous wireless queries and wireless store and forward capabilities.
In these and other ways, the system facilitates inventory management, assists with contract compliance, and minimizes product loss and expiration. In addition, it collects product usage behavior. For example, it can be used to automatically assign cycle counts, count inventory, analyze and review results, review real-time inventory, process results, synchronize results, and move outdated inventory. It can be used to calculate variance between counted inventory and expected inventory. It can also be used to generate inventory transactions needed to reconcile inventory.
While the following illustrative embodiments provide many examples using bar codes and bar code scanners, one skilled in the art would understand that some embodiments of the invention may be practiced using other types of automatic identification data. For example, some embodiments may be implemented to manage radio frequency identification (RFID) tags.
II. System Architecture
A system in which the teachings of the present invention are implemented can be logically structured as a multi-layered architecture as shown in
The user interface layer 110 may provide the applets, views, charts and reports, etc., associated with one or more applications. Various types of clients can be supported via the user interface layer 110. These various types of clients may include traditional connected clients, remote clients, thin clients over an intranet, Java thin clients on non-Windows-based operating systems, HTML clients over the Internet, etc.
The object manager layer 120 is designed to manage one or more sets of business rules or business concepts associated with one or more applications and to provide the interface between the user interface layer 110 and the data manager layer 130. The business rules or concepts can be represented as business objects. The business objects may be designed as configurable software representations of the various business rules or concepts, such as accounts, contacts, opportunities, service requests, solutions, etc.
The data manager layer 130 is designed to maintain logical views of the underlying data and to allow the object manager layer 120 to function independently of underlying data structures or tables in which data are stored. The data manager layer 130 may also provide certain database query functions such as generation of structure query language (SQL) in real time to access the data. The data manager layer 130 may be designed to operate on object definitions in a repository file 160 that define the database schema. A data storage services 170 provide the data storage for the data model associated with one or more applications.
The data exchange layer 140 is designed to handle the interactions with one or more specific target databases and provide the interface between the data manager layer 130 and the underlying data sources.
The multi-layered architecture allows one or more software layers to reside on different machines. For example, in some embodiments, the user interface, the object manager, and the data manager can all reside on dedicated web clients 200. For other types of clients such as wireless clients 203, the object manager and data manager can reside on a system server. It should be appreciated and understood by one skilled in the art that the system configuration shown in
The system environment illustrated in
The database 290 is designed to store various types of data, including predefined data schema (e.g., table objects, index objects, etc.), repository objects (e.g., business objects and components, view definitions and visibility rules, etc.), and a user's or customer's data. The dedicated web clients 200 and server components, including those that operate in conjunction with the other types of clients, can connect directly to the database 290 and make changes in real time. The mobile web clients 210 can download a subset of the server's data to use locally, and periodically synchronize with the server database through the system server to update both the local and the server database. Various tables included in the database 290 may be logically organized into the following types: data tables, interface tables, repository tables, etc.
Data tables may be used to store user business data, administrative data, seed data, transaction data, etc. These data tables may be populated and updated through the various applications and processes. Data tables may include base tables and the intersection tables. The base tables may contain columns that are defined and used by the various applications. The base tables may be designed to provide the columns for a business component specified in the table property of that business component. The intersection tables are tables that may be used to implement a many-to-many relationship between two business components. They may also hold intersection data columns, which store information pertaining to each association. In some embodiments, intersection tables provide the data structures for association applets.
In some embodiments, interface tables are used to denormalize a group of base tables into a single table with which external programs can interface. In some embodiments, they may be used as a staging area for exporting and importing data.
Repository tables contain the object definitions that specify one or more applications regarding:
A file system 295 is a network-accessible directory that can be located on an application server. The file system 295 stores the physical files created by various applications, such as files created by third-party text editors, and other data that is not stored in the database 290. In some embodiments, physical files stored in the file system 295 can be compressed and stored under various naming conventions. The dedicated web clients 200 can read and write files directly to and from the file system 295. The mobile web clients 210 can have a local file system, which they periodically synchronize with the server-based file system 295. In some embodiments, other types of clients such as the wireless clients 203 and web clients 205 can access the file system 295 via the system server.
An enterprise server 250 consists of some logical grouping of system servers 255 that share a common table owner or database and point to a common gateway server. The system servers 255 can be administered as a group using a server manager 260. The connection to the gateway server can be established via TCP/IP. The enterprise server 250 can be scaled effectively by deploying multiple system servers 255 in the enterprise server 250, thus providing a high degree of scalability in the middle tier of applications.
Each of the system servers 255 runs one or multiple server programs and handles the incoming processing requests and monitors the state of processes. Server programs may be designed and configured to perform one or more specific functions or jobs, including importing and exporting data, configuring the database, executing workflow and process automation, processing to support mobile web clients 210 for data synchronization and replication, enforcing business rules, etc. In some embodiments, each of the system servers 255 can be an NT Service (under the Windows NT operating system) or a daemon (e.g., a background shell process) under the UNIX operating system. In some embodiments, each of the system servers 255 supports both multi-process and multi-threaded components and can operate components in batch, service, and interactive modes.
The server manager 260 is configured as a utility that allows common control, administration, and monitoring across disparate programs for the system servers 255 and the enterprise server 250. In some embodiments, the server manager 260 can be used to perform the following tasks: start, stop, pause and resume servers 255, components, and tasks; monitor status and collect statistics for multiple tasks, components, and servers within the enterprise server 250; and configure the enterprise server 250, individual servers, individual components and tasks, etc.
The gateway server can be configured as a logical entity that serves as a single entry point for accessing servers. It can be used to provide enhanced scalability, load balancing, and high availability across the enterprise server. In some embodiments, the gateway server may include a name server and a connection brokering component. In some embodiments, the name server is configured to keep track of the parameters associated with the servers. For example, the availability and connectivity information associated with the servers can be stored in the name server. The various components in the system can query the name server for various information regarding the servers' availability and connectivity. In a Windows NT environment, the name server can be run as an NT service. In a UNIX environment, the name server can run as a daemon process. In some embodiments, the connection brokering component is used to perform load balancing functions such as directing client connection requests to an appropriate server (e.g., the least-busy server).
As illustrated in
Dedicated web clients 200 (also called connected clients) are connected directly to a database server for data access via a LAN or WAN connection. In some embodiments, these connected or dedicated web clients 200 do not store data locally. These dedicated web clients 200 can also access the file system directly. In some embodiments, the user interface layer 110, the object manager layer 120, and the data manager layer 130 of the multi-layered architecture reside on the dedicated web client 200.
The mobile web clients 210 are designed and configured for local data access and thus can have their own local database and/or local file system. Mobile web clients 210 can interact with other components within the system via the gateway server. Through synchronization, the modifications from the local database and the server database can be exchanged. Mobile web clients 210 are described in more detail below.
The wireless clients 203 are essentially thin clients enabled on wireless devices. The wireless clients 203 can use a wireless application protocol (WAP) based user interface to communicate and exchange information/data with the system server.
The system configuration illustrated in
The presentation services 315 may be designed and configured to support various types of clients and may provide them with user interface applets, views, charts and reports, etc. As described above, a large variety of clients may be supported (e.g., wireless clients, handheld clients, web clients, mobile web clients, dedicated (connected) clients, etc.).
The application services 325 may include business logic services and database interaction services. The business logic services provide the class and behaviors of business objects and business components. Database interaction services may be designed and configured to take a user interface request for data from a business component and generate the database commands (e.g., SQL queries, etc.) necessary to satisfy the request. For example, the data interaction services may be used to translate a call for data into DBMS-specific SQL statements.
Data services 345 may be designed and configured to provide the data storage for the underlying data model that serves as the basis of the various applications. For example, the data model may be designed and configured to support various software products and applications including call center, sales, services and marketing, as well as various industry vertical products and applications, such as eFinance, eInsurance, eCommunications, and eHealthcare.
The core services are designed and configured to provide the framework in which the applications execute. In some embodiments, the core services may include the following:
Application integration services may be designed and configured to allow the various applications built in accordance with this framework to communicate with the external world. In some embodiments, the various types of services in this logical grouping may be designed and configured to provide for real-time, near-real-time, and batch integration with external applications. For example, these integration services may be used to enable communications between external applications and internal applications using available methods, technologies, and software products. Application integration services allow the systems or applications to share and replicate data with other external enterprise applications. Accordingly, these services allow a particular application or system to be both a client requesting information and a server having information requested from it.
Business processes services are designed and configured to allow the client to automate business processes through the application. In some embodiments, these various business process services may include the following:
Creation of these business processes can be done through run-time tools such as Personalization Designer, Workflow Designer, SmartScript Designer, Assignment Administration Views, and Model Builder.
Integration services may be designed and configured to provide the client with user interface and thin client support. In some embodiments, these may include capabilities for building and maintaining web-based applications and for providing web support facilities such as user profile management, collaboration services, email and fax services, advanced smart Scripting, etc.
Design time tools may be designed and configured to provide the services to customize, design, provide integration points, and maintain the application. These various tools provide one common place to define the application.
Administrative services are designed and configured to provide one place to monitor and administer the application environment. These types of services allow the user to administer the application either through a graphical user interface (GUI) or from a command line, etc.
III. Administrative Setup and Repository Objects/Components
An administrative user may provide the system with initial bar code definition information via an administrative display user interface. This initial information will define structures of bar codes complying with one or more standards. Once configured with this initial bar code information, the system has adequate information to parse bar codes complying with such known standards and to generate a mapping of name and value pairs, sometimes referred to as a property set of various bar code components.
Attributes of the bar code component 500 include a name attribute 501, a sequence attribute 502, a buscomp attribute 503, a type attribute 504, a min length attribute 505, a max length attribute 506, a prefix attribute 507, a suffix attribute 508, an ASCII separator attribute 509, and a description attribute 510.
The name attribute 501 of the bar code component 500 identifies a bar code standard name (e.g., HIBC). The sequence attribute 502 provides precedence information that enables bar code component records in the system to be evaluated in an organized sequence. The buscomp attribute 503 identifies the business component to which the bar code standard applies. The type attribute 504 identifies a category for the bar code standard (e.g., whether the bar code standard is location-based or code-based) and indicates how to parse data in a bar code using child records. The min length attribute 505 stores information relating to the minimum length of the bar code. The max length attribute 506 identifies the maximum length of the bar code. The prefix attribute 507 identifies specific characters or symbols at the beginning of the bar code. Such prefixes may be used to differentiate the standard from other bar code standards. The suffix attribute 508 identifies the end of a bar code as defined by the standard. The ASCII separator attribute 509 identifies the ASCII character used to identify the end of variable length segments in a bar code or the end of code segments that contain variable length subsections, as each bar code may contain multiple variable length segments. The description attribute 510 identifies a description of the symbology for the bar code standard.
To represent some bar code standards, including the HIBC standard (illustrated in part in
Wild cards can be used to differentiate between different bar codes satisfying a particular standard. For example, with HIBC each instance of a product can have two separate bar codes, such as a primary bar code and a secondary bar code. Primary bar codes may provide unique product information and secondary bar codes may provide unique asset information. When scanning a product having multiple bar codes, each code is scanned separately. In turn, each scan provides different levels of information.
The name attribute 551 of the segment component 550 identifies a representative segment name. For example, in the HIBC Primary record example 1411 of
The sequence attribute 552 of the segment component 550 identifies the order in which to parse a location-type bar code. It can also identify the order to parse a subsection of a code-type bar code. The code attribute 553, which applies only to code-based bar codes, identifies a code value at the beginning of the code section or segment. For location-type codes, this attribute is not used. The min length attribute 554 identifies the minimum length of a section of the bar code. Likewise, the max length attribute 555 identifies the maximum length of a segment of the bar code. Each segment having a min length that is not equal to the max length is identified as a variable length segment. The description attribute 556 identifies a description of a bar code segment. The data description attribute 557 identifies a name for the described bar code segment. This value is the name in the property set. The data format attribute 558 identifies the format of the associated data element and the action attribute 559 facilitates providing an application with instructions for using the segment of bar code data. The bar code ID attribute 560 identifies the identification of a parent record in the bar code table. In other words, this is the link to the bar code component.
IV. Representative Flows
The system provides support for notifying a bar code service of a bar code reader (e.g., bar code scanner) hardware event. In an object-oriented implementation, functionality for providing notification of bar code hardware events may be encapsulated in a set of bar code classes, with each class supporting specific bar code readers using proprietary schemes. Such classes may use an abstract interface that does not require other system applications to be aware of what kind of bar code reader is being used (e.g., dumb vs. smart). The specific bar code class to be used may be dynamically determined upon application startup or an initial scanning event.
Dumb bar code readers behave somewhat like keyboards. However, dumb readers distinguish themselves from keyboard actions by preceding their data with a character prefix, which is usually programmable. In contrast, smart readers typically lack hardware support for a programmable prefix. Where smart bar code readers are used, the developer communicates with them through a proprietary SDK (software development kit) provided by the manufacturer.
For smart bar code readers, the system parses bar code data according to tables in a web client administration screen that defines bar code standards. By default, this service sets fields to the appropriate parsed bar code data as defined in one or more administrative screens. However, application-specific logic can override this behavior and process the property set data differently. When a smart bar code reader is used, the system delivers data returned by the smart reader to a bar code service.
With either smart or dumb device processing, the same services that parse the code may also be configured to pass results to another function or application for further processing. The results may be passed in two arguments. The first argument may be raw data from the scan. This first argument has a value when the scan is valid. The second argument is the property set of the parsed data (805 from
In some embodiments, where data from multiple bar codes is used to identify an appropriate product and asset, the data from the first scanned bar code may be cached until sufficient data is collected to create product and asset records. Caching may be done in a manner to provide for independence between the operation of the application and scanning sequences.
After scanning, the routine performs various actions to parse the inputted bar code, as shown in blocks 902-929. At block 902, the routine verifies that the active view and applet are enabled for scanning. At block 903, the routine does a prefix/suffix lookup. In the illustrated embodiment, the prefix/suffix values and code values are exact strings to compare, with the following “wild card” exceptions: a “#” denotes a digit from 0-9; a “&” denotes a letter from A-Z (or a-z); and a “!” denotes the ASCII character specified by a separator value or the end of a bar code in a particular code segment. For example, in a variable length bar code segment, positioned at the end of a bar code, there is no group separator. In such a case, the end of the bar code is implied to match the “!” symbol within a code value. Similarly, a “*” will denote any character. If the separator appears as the first character in the bar code, the routine will ignore it when parsing the bar code.
Once the correct bar code record is identified based on the prefix/suffix and length, at block 904, the routine verifies whether the scanned-in bar code satisfies the min/max requirements of the record. At block 905, the routine matches the business component. At decision block 906, the routine performs a type lookup. For example, the type can be a location-based bar code or a code-based bar code. If at decision block 906 the routine identifies the bar code as a location-based bar code, the routine continues at block 907 of
At block 908, the routine retrieves a next segment of the location-based code. At decision block 909, starting from the beginning of the bar code data, the min length and max length fields for the next segment to be processed are examined to see how much data should be associated with a data description value. If at decision block 909 the min/max length fields match the min/max fields for the appropriate bar code definition, the routine proceeds to block 910, where the segment is evaluated as a fixed-length segment. If at decision block 909 the min/max fields do not match the bar code definition, the routine proceeds to decision block 911, where the routine checks for whether a separator has been included in the bar code definition. In some embodiments, the separator indicates where a bar code segment terminates.
If at decision block 911 a separator has not been defined, the routine proceeds at block 912, where the segment is evaluated as a variable length segment. The variable segment can be anywhere in the bar code. The variable-length segment is isolated by reading up to the group separator, the maximum length of the section, or the end of the bar code, whichever is encountered first. In this way, the group separator enables the parsing of bar codes with multiple variable length segments. If, at decision block 911, a separator has not been defined, the routine continues at decision block 913, where the routine checks to see if the bar code has already been evaluated from its tail end. If at decision block 913 the bar code has already been evaluated from its tail end, the parsing is complete and the routine ends. Otherwise, if at decision block 913 the bar code has not already been evaluated from its tail end, the routine continues at block 914, where the routine evaluates the bar code from its tail end to identify the variable length string based on the known fixed length strings in the bar code. Following block 914, the routine returns to block 908 to retrieve a next segment of the location-based code.
Alternatively, following blocks 910 and 912, the routine proceeds to decision block 915, where it checks to see if the bar code has remaining segments to process. If, at decision block 915, there are no remaining segments to process, the routine ends. Otherwise, the routine loops back to block 908, where the next segment is evaluated.
From decision block 905 of
At decision block 920, if a search using the search string turns up a matching record for the bar code, the routine proceeds to block 921. Otherwise, if there is no match at decision block 920, the routine loops back to decision block 918.
At block 921 the routine retrieves the next code segment from the bar code. At decision block 922, if the code segment does not match the min/max requirements of the definition, the routine continues at decision block 924. If, however, at decision block 922 the code segment does match the min/max requirements, the routine continues at block 923, where the routine evaluates the fixed length code segment.
At decision block 924 the routine is dealing with a variable length code segment. Accordingly, if at decision block 924 a separator is not defined for the code segment, the routine continues at decision block 926. If, however, at decision block 924 a separator is defined, the routine continues at block 925 where the routine evaluates the variable length segment knowing the variable length string ends at the separator.
At decision block 926, the routine checks to see if the code segment has already been evaluated from its tail end. If at decision block 926 the code segment has been evaluated from its tail end, the routine proceeds to block 928 where the routine is finished parsing the current code segment. If, however, at decision block 926 the routine has not been evaluated the code segment from its tail end, the routine continues at block 927 where the routine evaluates the code segment from its tail end working backwards to identify the variable length string based on the known fixed length string.
Following blocks 923, 925, and 927 the routine proceeds to decision block 929, where the routine checks to see if there are code segments remaining in the bar code. If at decision block 929 there are remaining code segments, the routine loops back to block 921 to retrieve the next code segment. If, however, at decision block 929, there are no code segments remaining, the routine proceeds to block 928, where the routine is finished parsing the current code segment. Following block 928, the routine loops back to decision block 918 where the routine checks to see if the end of the bar code has been reached.
V. User Interface
In some embodiments, the user can navigate to the scan bar code view by using a scan button on a cycle count detail view. The scan bar code view enables a user to view product and asset information obtained from the product. The user can keep pressing a button on the side of the device for repeated scans. The user can clear a bar code input using a clear button. The user can create a transaction to move a product out of an inventory using a move button. The user can adjust a current bar code and return to a cycle count detailed view using a stop button.
To further illustrated the parsing of defined code-based bar codes, the following steps describe parsing the code “ˆ1704060106654355ˆ2111202ˆ3050.” For this bar code, the parent definition record is located in a process similar to the previous example described above (i.e., the algorithm drops the first separator and looks for a match in prefix/suffix/length according to record sequence). For this particular bar code, the first match of prefix/suffix and min/max length is also parent record 1511.
The record also indicates the combination and sequence of data elements required to uniquely identify an asset for the product (e.g., using an expression field). Based on the expression field, data elements are concatenated and used to find the associated asset record where the asset's unique ID is equal to the value formed based on the expression.
From the foregoing, it will be appreciated that specific embodiments of the invention have been described herein for purposes of illustration, but that various modifications may be made without deviating from the spirit and scope of the invention. Accordingly, the invention is not limited except as by the appended claims.