In Chapter 11, we discuss a Business-to-Employee (B2E) solution, the employee portal, which uses a business registry to function. It is also possible to use registries in Business-to-Business (B2B) and Business-to-Consumer (B2C) scenarios. In the chapter, we discuss applications of registries in these two areas. Some of the issues faced by solutions using registries are the same irrespective of the application area. Thus, the issues or design principles discussed previously have been omitted in these case studies. However, they must all be addressed when deploying a real-world solution.
As we discussed in Chapter 2, during their product generation processes, companies need several types of raw materials and parts. Generally, required raw materials and parts for manufacturing a certain product are well known in a manufacturing process. This includes specifics such as:
Quantity required per unit
Quality level
Substitute material
When a manufacturing run (either forecasted or customer-specific) is planned, the raw materials and parts are procured. Companies usually stock up on these parts based on product generation requirements, using market forecasts. These parts must be available (on hand or readily obtainable) so that the manufacturing processes can flow smoothly. Typically, manufacturers manage relationships with several vendors to supply these. Usually, just-in-time manufacturing procedures dictate that when inventory of raw materials or parts goes below a certain level, the procurement procedures determine the inventory requirements for the raw materials and parts. A procurement order to restock the inventory to support the manufacturing plan is then placed with an appropriate vendor.
These requests are directed toward the set of suppliers that the company has established relationships with. The suppliers can then respond with their bid (quote) for supplying the desired quantity. A quote usually minimally includes the price for the quantity and the terms related to supplying at that price. An example term that could be associated with a quote could be its expiry date. Because the market price for many raw materials fluctuates, the expiry date protects the supplier from vast differences between the quoted price and the market price.
Optimizing procurement processes has long been recognized as a valuable tool to provide a competitive advantage to companies. The optimization, in this case, involves several factors. It is not always the cheapest supplier that wins orders. The quality, credit rating of the vendor, other references, and recommendations, as well as the company-vendor relationship history, all play a role in the awarding of a contract to a specific vendor. Something as fleeting as the procurement manager’s bad vibe around a particular vendor might also throw a few vendors off the playing field. Similar criteria come into play when a supplier makes a decision to respond to a manufacturer’s need for raw materials and parts. For example, even if a supplier has a good relationship with a manufacturer, it may decide not to respond to a particular request because the order is perhaps too small or too large for the supplier to handle. Optimizing the chain of events from the point in time when a inventory need is recognized to the time it is received (i.e., the procurement cycle) is a complex undertaking, mainly because so many nontechnical factors affect the final decisions made.
The process by which a buyer and a seller come to an agreement to engage in a trade is called the RFQ process. An RFQ (request for quote) is a very commonly used procurement process for obtaining goods, raw materials, supplies, labor for contract work, and other services from vendors. This is also called direct procurement because, in this case, the customer buys the goods directly from the vendor. It is interesting to note that the RFQ is a generic process that is useful whenever someone has a need for service to be performed or goods to be obtained outside the scope of their entity and needs to locate the appropriately skilled entity to fulfill that need. A state government desiring to widen a major freeway may develop an extensive RFQ to put forth in the civil engineering industry.
The most generic process of direct procurement involves the following steps:
The buyer posts a list of required items to appropriate suppliers.
The RFQ document includes specification, configurations, and other raw materials or parts criteria.
The RFQ is reviewed by one or more suppliers.
The suppliers then submit a bid or quote in response to the RFQ.
The buyer reviews and awards the contract to one or more of the responding suppliers.
The goods and money exchange hands.
The RFQ process can be classified into the following categories:
Single-Step RFQ: In this case, the buyer knows exactly what it wants (especially true in the case of tangible products). This is the process defined above. Industries that typically use single-step RFQ are the electrical, mechanical, semiconductor, medical equipment, aviation, metals, and customized parts industries.
Two-Step RFQ: In the two-step RFQ process, the buyer asks for a proposal based on a generic requirement (consisting of a description of the desired product or service) in the first step. This is generally used when the exact requirements, specifications, and desired result are not easily described. The document distributed by the buyer is called a Request for Proposal (RFP). The selected RFPs go into the second step, in which companies negotiate on the requirements and the price associated with those. Industries such as software services and civil construction employ a two-step RFQ process. In general, an RFQ is used for needs that can be described in a very specific manner. An RFP is used either when the products are complex or requirements are not very well understood. In such a case, the first step helps in solidifying the requirements, so that the supplier can quote a price based on these.
Multistep RFQ: In this type of procurement, there may be several steps before the actual bidding begins. Government contracts, typically, follow a multistep RFQ. The first rounds are related to supplier selection. For example, a certain contract may require that the supplier company have certain certificates of standardization or it must employ environment- and animal-friendly procedures in its manufacturing. Some companies are selected based on their abilities to satisfy the early step requirements. These chosen companies then can participate in RFQ processes similar to the single-step or two-step RFQ processes.
Another important factor is the process by which the buyer chooses to announce the RFQ. In general, a buyer can announce two types of RFQs:
Private RFQ: In this case, the buyer creates the RFQ and sends it to pre-selected suppliers; these suppliers could be a subset of the entire supplier list. These are the only ones eligible to bid on the particular RFQ. The list of suppliers is subject to the buyer’s selection criteria and may vary from time to time. Usually, companies use private RFQs if they have a special trust and confidence in the suppliers’ ability to deliver on the RFQ. A private RFQ is easy to administer. However, it limits the participation of the suppliers. The received quote is best only among the group of chosen suppliers.
Public RFQ: In a public RFQ, in contrast to the private RFQ methods, the buyer creates the RFQ and announces it to the public for bidding. All or any suppliers are free to bid on such an RFQ. The public RFQ ensures that all the interested suppliers get a chance to bid, but it is also difficult to administer.
In general, an RFQ goes through several stages during its processing cycle. Below, we define a very general description of the business process associated with RFQ processing. There are several variations in practice that are specific to each industry. Also, in most real-world implementations, there is a uniqueness associated with each company’s business flows. Figure 12.1 depicts this process flow.
Buyer identifies needs for purchase of direct procurement material and creates the RFQ, which typically includes a list of items, specifications, diagrams and pictures, terms and conditions, quality requirements, and delivery schedule for the material that needs to be purchased.
Buyer chooses an RFQ methodology. This determines the steps involved in the RFQ process and the potential set of suppliers who are eligible to respond.
After complete review of RFQ data, buyer posts the RFQ.
Appropriate suppliers determined by buyer’s RFQ methodology get an invitation to participate in the RFQ process.
Interested suppliers review the RFQ and decide whether to send a response to the RFQ.
Each interested supplier prepares the bid for the RFQ, which typically contains information about prices for the items requested by the buyer, delivery schedule, and the supplier’s terms and conditions.
Supplier, after review, submits the bid to the buyer.
After a certain prespecified date, the RFQ is closed.
Buyer reviews all the submitted bids.
Buyer then rewards the bid to one of the suppliers. The selection of a specific supplier is based not only on the quoted price but also on other crucial factors, such as quality and availability of material (or some other deciding criteria appropriate to the situation).
Buyer will send the appropriate bid award and rejection notification to participating suppliers.
Consider a car manufacturer, AmCAR, Inc. AmCAR is a leader in the car industry and is known for its innovative car designs. AmCAR has manufacturing plants around the world to optimize the cost of manufacturing. These plants manufacture several different car models, based on the local market preferences and demands.
Manufacturing cars requires AmCAR to have several raw materials and parts on hand. Everything from the tires to the sunroof glass, to the metal for doors is procured from various suppliers. AmCAR has been in the car industry for several years and has developed an extensive list of suppliers. Its suppliers are categorized under several categories such as components they provide, geographic location, and the tier they belong to. Ideally, all procurement would happen from the top-tier suppliers, but as we noted before, suppliers also have a choice to respond to a company’s material needs, and hence, managing a host of suppliers (multiple ones for any part in particular) is a very important part of the procurement process.
In most cases, AmCAR floats an RFQ to its list of suppliers. This list must be managed in an efficient manner and kept updated. The supplier that submits the most optimal bid is awarded the contract for that particular part list. Recall that the optimal bid is a combination of price, circumstance, and general confidence about the situation and the suppliers involved — especially when AmCAR’s top-tier vendors choose not to respond to an RFQ. In some cases, AmCAR decides to award partial contracts to two or more suppliers to complete the desired quantities. The requirements for the platform that enables this interaction between AmCAR and its suppliers can be summarized as follows:
Support for private RFQ
Support for targeted RFQ delivery
Support for anonymous contract announcements
Support for easily discoverable RFQs
Support for easily discoverable bids
Support for real-time notification of new RFQs and bids
AmCAR’s procurement department and the participating suppliers must work together to create a solution that will enable AmCAR to float and process the RFQs effectively. Essentially, all the participants form an ecosystem that caters to a specific need — i.e., the exchange of RFQ information between AmCAR and its suppliers.
Since the RFQs are private in nature — being floated to only very specific vendors — the ecosystem is also private in nature. It exists to serve the car manufacturing needs of only AmCAR corporation. The access to this ecosystem is controlled by AmCAR, and AmCAR also makes business and technical policy decisions to operate this ecosystem. It is not unusual for big companies to create such private ecosystems that cater to their needs and the needs of their partners. Note that AmCAR could have also decided to participate in some existing public ecosystem. However, deploying a private ecosystem is desired for confidentiality reasons.
Note
There are several advantages to a private ecosystem. For the ecosystem host, which is usually the ultimate beneficiary of the ecosystem as well, a private ecosystem gives a high degree of control over the functioning of the ecosystem. The business and technology policy decisions can be made by the host swiftly and to the extent that they benefit the host itself. A private ecosystem is also a good alternative in absence of a (competent) public ecosystem. In such a case, the private ecosystem, if successful, can be transformed into a public ecosystem. The SABRE system developed by American Airlines is a good example of such a transition.
Because AmCAR is designing, developing, and implementing the platform to en-able the interaction between the ecosystem members and itself, it acts as the ecosystem host. It is also the governing body for this ecosystem because it makes the policy decisions for this private ecosystem.
Recall that the governing body is responsible for the operating framework in the ecosystem — i.e., the tModels, interaction specifications, and other operating procedures. Of course, some of these require active participation from the suppliers themselves. For example, it is essential that the major suppliers are involved in defining the RFQ process flow. The set of tModels and specifications defined for the ecosystem would be binding to all the members, and adherence to them is essential for smooth functioning of the ecosystem.
As part of defining the functioning of this ecosystem, several interaction patterns and specifications must be defined. The RFQ process defined in Section 12.3 can define the overall process and may be registered with the registry as a tModel. In addition, several other candidate tModels could be those defining various terms or subprocesses. Table 12.1 depicts an example of terms used within an RFQ. This specification is represented by the corresponding tModel.
Table 12.1. RFQ Terminology tModel
|
Attribute |
Description |
|---|---|
|
RFQ number |
15 character alphanumeric reference number used for RFQ. |
|
RFQ description |
Description of the RFQ in free-flow text. |
|
Start date |
Date (mm/dd/yy) on which the RFQ is posted onto the RFQ system and is available for bidding |
|
End date |
Date after (mm/dd/yy) which no bids are accepted: i.e., the RFQ is closed |
|
Category list |
The category to which the RFQ belongs |
|
Billing details |
Billing address |
|
Shipping details |
Shipping address |
|
Payment details |
Credit card, escrow, demand drafts, or otherwise |
|
Vendor information |
UUID of the business entity registered in the designated UDDI registry |
|
Note |
Free-formatted text for comments from the buyer (up to 1000 characters) |
|
Terms and conditions |
The different terms and conditions include payment terms, transportation terms, conditions for sale, and other terms (up to 1000 characters) |
|
Item code |
A unique item code (up to 16 characters) |
|
Item name |
Name of the item (up to 100 characters) |
|
Item description |
Description of the item (up to 100 characters) |
|
Unit of measurement |
The basic unit by which the quantity of the item is measured |
|
Quantity |
Quantity of the item |
|
Expected delivery schedule |
Expected delivery date for the item |
|
Quality |
Quality requirements for the item |
|
Attachments |
These might be specs or drawings related to items |
|
Dimensions |
Dimensions of the item |
|
Unit of dimension |
Unit of measure of the dimension; valid values are CM, METER, FT |
|
Weight |
Weight of the item |
|
Unit of weight |
Unit in which the weight is specified; valid values are KG, LB, OZ |
In a complex ecosystem, such as this, a single set of interaction specifications may not be sufficient to include all the parties involved. Typically, various members will be already abiding by certain known standards and the ecosystem will need to incorporate some or all of them in order to minimize the impact on individual members. Failure to do this could result in significant design and development efforts, as the members strive to comply by the new standard, or withdrawal by members who are not interested in investing into the effort.
In such a case, the role of registry is even more important as it contains information about specific tModel-compliance by any registered service.
Figure 12.2 depicts the AmCAR Parts Procurement ecosystem. As shown, the UDDI registry plays a central role in this ecosystem.
All the concerned business entities, AmCAR and the suppliers, are listed in the registry. The information included for these entities includes the usual set of fields such as contact name and contact address. Note that the purpose of the registry is limited to the private ecosystem it serves. Thus, the information contained here could be very specific to this ecosystem. For example, the contact name for AmCAR would be the operational manager responsible for day-to-day operations of the ecosystem. When a contact name is required for AmCAR home page registration within Universal Business Registry (UBR), it will perhaps be the official spokesperson for the public relations firm.
The registry also includes information on services deployed by these entities. A Procurement service that belongs to the AmCAR procurement department manages the RFQ process. This service is responsible for creating an RFQ and pub-lishing it to the suppliers through the AmCAR Procurement ecosystem. The Procurement service will interact with the registry to find all the suppliers and their bidding services. The designed architecture and interaction patterns among participants of the AmCAR Procurement ecosystem are shown in Figure 12.3.
With the selection of the deployment platform, the services (Procurement and Supplier) need to be described, registered, and discovered in a similar fashion to those discussed in the examples of this book. The AmCAR Procurement service is responsible for floating new RFQs, using information extracted from a system that contains the product information and the bill of materials (BOM). Each RFQ could be an UDDI-registered service, that is described and registered with the ecosystem. The supplier services respond to the RFQ positively by generating a quote or negatively by rejecting the RFQ. Like the RFQs, individual bids could also be UDDI-registered services in the ecosystem.
The services follow a defined set of specifications, represented by tModels in the registry, to participate in the ecosystem. The services describe themselves, register themselves, and finally, interact with others. As discussed in Chapter 3, these services could be implemented as Web services. In such a case, the operational interfaces of the Web services must be agreed upon and represented via corresponding tModels. The Web Service Description Language (WSDL) corresponding to this interface is provided as part of the overview documentation section of the tModel.
It is easy to imagine that the solution described above could be extended beyond just one pair of interacting nodes in the supply chain. After all, AmCAR will be supplier to its dealers and AmCAR’s suppliers will also have their own raw material providers. The kind of interactions involved across this supply chain will be similar. Hence, a broader ecosystem could be perceived where many more roles could come together.
In such an extended supply chain, it may not be practical to have a single participating entity, like AmCAR, be the governing body and ecosystem host. The solution is likely to be more in public or jointly-owned environment. If such a setup exists, the AmCAR Procurement Ecosystem becomes only a piece of the bigger puzzle. Accordingly, respective registries for the bigger solution and the AmCAR ecosystem will carry different sets of data with some common sets of information shared. The registries themselves can be thought to be part of a “network of registries.” This concept is explored further in Chapter 14.
While in the software industry Web services are making waves, in the hardware world, mobile devices seem to be in fashion. Literally millions of these smart devices have been sold worldwide. There are several different types of such devices available today, including pagers, cell phones, and Personal Digital Assistants (PDAs). Several other new information appliances are being designed and will be available soon. There are two noticeable trends in the mobile industry today: integrated devices that have dual (or multiple) functionality and services on top of the device. Both of these dimensions are enhancing the usability of these devices and making them more indispensable. The integration trend has resulted in devices such as Sony Clié (integrates an MP3 player with a PDA) and HP iPaq (integrates a cell phone with a PDA).
The value-added services, on the other hand, use an existing device and build a functionality stack on top. Services such as corporate email and mobile information systems for the sales force of a company are examples of such services. These mobile services are the intersection between the mobile space, and Web services. One important class of mobile services is location-based services.
Location-based services, as the name suggests, provide location-savvy functionality. As the user’s location changes, service invocation results in a different outcome. Some examples of location-based services are: finding the nearest point of interest, dating services, and on-the-spot product promotions. In this section, we discuss a special case of point-of-interest, location-based services.
Consider Ron Danforth, a salesman with CoolSoft, Inc. — a company that makes accounting and financial software products for small and medium-size businesses. As part of his responsibilities, Ron is required to travel all over North America — his sales region — to talk to business owners and explore sales opportunities.
Being in the software industry, it is imperative for Ron to stay abreast with the latest happenings in the software industry, as well as in the financial services world — his clientele. In addition, he also needs access to customer-specific documents required during customer visits. These include product data sheets, customer information, such as buying history, and details of any contracts with the customers. Before mobile devices became popular, Ron used to take his laptop computer everywhere so that he would be able to connect to the Internet from his hotels and get the information he wanted. These days, however, Ron prefers to take his handheld device, Corona, on shorter trips. Corona is a top-of-the-line mobile device that has aPDA integrated with a cell phone. The PDA part of the device is also equipped with a wireless communication subsystem. Using the wireless subsystem, the device can connect to the Internet through a wireless Internet Service Provider (ISP). Corona can store contact information, limited customer data, and limited product information. Corona can satisfy most of Ron’s information needs; however, it does not provide access to everything because of its limitations.
First, storage space limits the amount of data it can carry. Second, the current wireless protocols supported on it provide a very low bandwidth. This prevents downloading large documents through the communication link. Finally, because it is a handheld device, it has a very small form factor (screen size). This limits the amount of information that can be displayed on its screen. To optimize available storage space on the device, Ron takes only the company private data he needs on the device. He uses the Internet connection, albeit slow, to download any public information. These limitations make it difficult for Ron to have the information he needs — especially on important sales visits. According to him, it would be great to have a summary of the information (for example, news headlines) on the device, then get elaborate information on a specific item (for example, the article associated with a news headline) in print format when desired.
There are two problems that prevent Ron from making this scenario a reality. Due to bandwidth limitations, it is difficult to download detailed information. Even if he manages to download the information, he does not always have access to a printer. A mobile printing solution can help Ron stay informed, even if he is on the road. To understand the solution, it is useful to know more about the world of mobile devices.
Although wireless communication technologies have been around for several years, they did not intersect with computing technologies. This is because wireless technologies were primarily focused on voice communication. Devices such as walkie-talkies and cell phones are examples of early versions of the devices that used wireless technologies. Recently, however, a number of more intelligent devices utilize wireless technologies for different purposes. These include handheld and pocket computers that extend the PDA functionality on the device, pagers, and Wireless Access Protocol (WAP)-enabled cell phones. This new breed of devices is much more intelligent, compared with earlier devices. They usually include a processor and an Operating System (OS) kernel that brings them closer to a computer. In fact, Microsoft-enabled devices are called handheld and pocket PCs!
The features of the mobile devices are defined by three dimensions — platform, protocols, and services. The platform provides the core of hardware and software functionality. The protocols are part of the communication subsystem that help the device connect to the rest of the digital world, and the services enhance the value of the device by adding more features. Figure 12.4 depicts the mobile space. The connectivity options available on a device play a crucial role in the effectiveness of any service offered on it.
To connect to the public network, a handheld device needs to communicate with a gateway that is connected to the Internet. The connection protocols vary from device to device. For cell phones, the WAP has been available for some time.
ForPDA-type devices, protocols such as CDPD (Cellular Digital Packet Data) and GPRS (General Packet Radio Services) are gaining popularity. Both of these technologies fall under the Wireless Wide Area Network (WAN) technology class. These protocols provide public network connectivity through a wireless service provider. Another class of wireless access protocols is also emerging, called Wireless Local Area Network (LAN) protocols. The protocol 802.11b is a good example of such a protocol. Wireless LAN protocols, as the name suggests, provide access to a local area network. A wireless LAN infrastructure is typically deployed within a corporate network boundary. Wireless LANs are characterized by bandwidth that is much higher, compared with wireless WAN bandwidth. However, a wireless WAN is more pervasive, compared with a wireless LAN. The wireless LAN technologies offer connectivity for a device within a close proximity from the LAN access point. Compared with that, wireless WAN connectivity is possible virtually anywhere.
A hot spot is a location from where high-bandwidth connectivity (typically through wireless or wire-line LAN technology) is available. Examples of hot spots are corporate offices, airports, and coffee shops. Usually, these locations are equipped with high-speed Internet connectivity. A device that is connected to the network from a hot spot can transact more effectively, due to the availability of high bandwidth. Whenever possible, a user would prefer to have device connectivity established from a hot spot. However, when it is not possible to do so, the wireless WAN technology is another option. Together, the wireless LAN and WAN technology can provide close to an “always connected” experience from a mobile device. The mobile ecosystem that facilitates mobile printing on demand consists of such devices and a backend connectivity infrastructure.
Many Web sites are mobile-device savvy and can filter the content before it is sent to such a device. This filtering is called repurposing. A repurposed site appears, potentially, much different from the original Web site. Several features (for example, graphics and navigation icons) not supported on the device are omitted for a better user experience. Repurposing can also limit the amount of information sent to the device, and thus, only a subset of the information, that which is deemed vital, may be sent to the mobile device. Repurposing is a very effective and bandwidth-friendly way to get the gist of the information to a mobile user.
A solution to Ron’s problem requires alliances between various entities, such as print service providers and location-savvy components in the mobile marketplace. It would be easy to think of this new set of interactions in terms of an ecosystem that serves a specific need — namely, mobile printing. The Mobile Printing ecosystem can bring necessary services together and define the interaction among them to facilitate mobile printing needs similar to Ron’s. Figure 12.5 depicts one such ecosystem.
The user of the ecosystem services in this case is a mobile professional who would like to stay connected with the Internet while on the road and would like to get as much information as he or she needs by circumventing the limits of the mobile device used. The service-user uses the mobile device to connect to the Internet through one of the connectivity options described previously and gets to the desired information. The general activity of web surfing is not necessarily visible to the ecosystem in this case. Presumably, the Web sites providing the information of interest to the user are repurposed for the device. When a user is interested in receiving detailed information, the interaction with the mobile printing ecosystem begins.
At the center of the mobile printing ecosystem is the ecosystem host. The ecosystem host brings together the mobile device users and the print service providers. From that aspect, its role is similar to the procurement ecosystem host, discussed previously in this chapter. A request from a service user typically includes the Uniform Resource Locator (URL) of the information that needs to be printed and the location of the user. The request also specifies certain print-quality instructions, such as color or black-and-white copies or two-sided and photo-quality printing.
Several methods and technologies to specify locations are available in the market today. UDDI Version 3 specification enhances the location capabilities further compared to the Version 2 specification. A location service that effectively determines the exact location of the service-user is an important part of the mobile printing ecosystem. Once the location of the service-user is determined, a suitable Print Service Provider (PSP) must be located that can fulfill the user’s print request. This search, based on location information registered for the PSPs in the registry, can take into account several predefined and user-specified parameters to find a printing provider. To enable this discovery, each PSP must register a service representing itself (or each of its stores, if it is a chain) with the ecosystem and describe its capabilities. The tModels required in the ecosystem can be defined by an independent consortium or the ecosystem governing body.
Using the service descriptions and the location of the user, the Mobile Printing service can locate the most optimal PSP that can fulfill the user’s request. Once a suitable PSP (or PSPs) is found, the service notifies the user about the PSP locations and other attributes, such as the price and rating associated with that PSP. The user then decides whether to respond to any offer and communicates his or her decision to the Mobile Printing service. The service then submits the request to the appropriate PSP. Once a PSP receives a print request, it is submitted in the print queue. When printing is completed, the PSP can notify the user so the user can pick up the document at a designated time.
The interaction sequence, agreed upon by the major players and represented in the registry as a tModel in the Mobile Printing ecosystem can be as follows:
The Mobile Printing ecosystem host creates the necessary platform for its functioning.
The ecosystem host invites appropriate entities to populate the ecosystem. These entities include the governing body, foundation and extended services, and potential service users.
The PSPs that wish to participate in the ecosystem register their print capabilities with the ecosystem.
The user submits a mobile printing request to the Mobile Printing service. The request includes the user’s location, the URL of the document(s) to be printed, print-quality, and pickup instructions.
The location service determines the list of potential PSPs that can fulfill the user request.
Using the user parameters, the Mobile Printing service selects the best PSP that can fulfill the user request.
The Mobile Printing service communicates the list of PSPs and pertinent data for the user’s consideration.
The user determines whether he or she wishes to submit the print request to one of the PSPs.
The user submits electronic payment (digital wallet-based or credit card) to the PSP.
The PSP receives the print request and determines the best printer from its printer farm to queue the print job.
Once the document is printed, the PSP notifies the user that the document is complete and provides directions from the current location or a specified location to the PSP.
The user retrieves the document from the PSP at the designated time.