WO2018201199A1

WO2018201199A1 - Tender management system

Info

Publication number: WO2018201199A1
Application number: PCT/AU2018/050411
Authority: WO
Inventors: William Joseph BLINCO
Original assignee: Bizcaps Pty Ltd
Priority date: 2017-05-05
Filing date: 2018-05-04
Publication date: 2018-11-08

Abstract

A tender management server comprising a buyer interface configured to receive a buyer input request to create a tender requirement specification; a processor arranged to create a tender requirement specification in response to the buyer request, the tender requirement specification identifying at least one product required by the buyer; a storage repository configured to store the tender requirement specification; a network interface, configured to connect the tender management server to a product database across a communications network; seller interface, configured to receive seller request to populate the product required by the buyer in the tender requirement specification using data retrieved from the product database across the communications network; the storage repository being configured to store the retrieved data in the tender requirement specification, and being further configured to store a record of a location within the product data base from which the data was retrieved.

Description

Tender Management System

The present invention relates to a tender management system and, in particular, to a line item tender

management system.

Background

Presently, the conduct of tender preparation and award is effort-intensive for both buyer and seller, particularly where the tender involves product line information.

Generally, buyer sourcing teams prepare and distribute worksheet-based response forms that are completed by sellers and on return are manually collated and assessed prior to being awarded.

The awarded items are then collated into worksheet based pricing schedules (AKA 'User Guides' at Healthshare) for distribution to procurement departments within the buyer organisations. The process is cumbersome and time- consuming and abounds with opportunities for error on both seller and buyer side.

Tender response worksheets are prepared by individuals and while there are genuine efforts to standardise the way this is carried out, the ability to implement system- enforced standards using commercially available

spreadsheet software is limited. As a result,

inconsistency in process and content will always be present depending on the individuals who prepare them.

In dealing with tenders from multiple buyer organisations, sellers find themselves having to contend with differences in procedure between jurisdictions as well as

inconsistency in language and nomenclature between buyer organisations, between contracts and even between contract transitions from one contract period to the next. This makes it extremely difficult to implement useful

automation of the response process on their side.

Of course, all this reduces the efficiency, consistency, accuracy and timeliness of tender preparation, assessment and award processes.

Summary of the Invention In a first embodiment, the invention provides a tender management server comprising: buyer interface configured to receive a buyer input request to create a tender requirement

specification; a processor arranged to create a tender requirement specification in response to the buyer request, the tender requirement specification identifying at least one product required by the buyer,

storage repository configured to store the tender requirement specification;

network interface, configured to connect the tender management server to a product database across a communications network;

seller interface, configured to receive seller request to populate the product required by the buyer in the tender requirement specification using data retrieved from the product database across the communications network;

the storage repository being configured to store the retrieved data in the tender requirement

specification, and being further configured to store a record of a location within the product data base from which the data was retrieved.

Embodiment comprise a data comparison module, the data comparison module comprising a processor for retrieving data from the recorded location within the product database and comparing the retrieved data with the stored data, the processor creating an alert in dependence on the retrieved data being different from the stored data. In embodiments the data comparison module performs the comparison periodically.

In embodiments the data comparison module performs the comparison on receiving a comparison request from the buyer.

In embodiments the buyer interface is configured to receive a buyer input request including seller

identification data associated with the tender requirement specification identifying sellers authorized to access the tender requirement specification, the tender management server further comprising an authorization module, the authorization module configured to authorize a seller requesting access to the tender management server, and further configured to limit access to tender requirement specifications to which the seller is authorized.

In embodiments the buyer interface is configured to receive a buyer input request including input access period data, input access period data comprising at least one of an opening time, a closing time and an opening duration, during which authorized sellers may access the tender requirement specification. In embodiments the buyer interface is configured to receive a buyer input request including seller input requirements including mandatory category information response requirements . In embodiments the seller interface is configured to receive a seller request to access the tender requirement specification and, on receipt of the seller request, the customer interface provides access to the tender

requirement specification in dependence on the seller being authorized to access the tender requirement

specification.

In embodiments the seller interface provides access to the tender requirement specification in dependence on the seller request being received at a time during which authorized sellers may access the tender requirement specification.

In embodiments the seller interface is configured to establish a connection to the product database in response to receiving seller request data.

In embodiments the seller interface is configured to receive a seller request to retrieve selected seller data stored in the product database associated with buyer selected product category information.

In embodiments the tender management server is configured to retrieve seller data stored in product database when the seller interface provides access to the tender requirement specification; and, display the retrieved seller data to the seller.

In embodiments the contributor request data comprises a tender requirement specification complete request, the tender management server configured to: identify any uncompleted mandatory category information response requirements; and, raise an alert in dependence on identifying any uncompleted mandatory category information response requirements . In embodiments the tender management server is configured to alert authorized sellers when they may access the tender requirement specification. Embodiments comprise a comparison engine configured to compare seller data entered into the tender requirement specification, when data is received from multiple sellers, seller data being compared in accordance with predefined comparison criteria .

In embodiments the buyer interface is configured to receive a buyer input request including the predefined comparison criteria.

Further embodiments comprise a database monitoring engine, the database monitoring engine identifying updates in the product database, and generating an alert to the tender management server in response to an update m tne product database .

In a second aspect, the invention provides a method for generating a tender document comprising the steps of:

receiving a buyer input request to create a tender requirement specification; creating a tender requirement specification in response to the buyer request, the tender requirement specification identifying at least one product required by the buyer,

storing the tender requirement specification; connecting the tender management server to a product database across a communications network;

receiving seller request to populate the product required by the buyer in the tender requirement

specification using data retrieved from the product database across the communications network;

storing the retrieved data in the tender requirement specification, and storing a record of a location within the product data base from which the data was retrieved. Embodiments comprise the step of retrieving data from the recorded location within the product database and

comparing the retrieved data with the stored data, the processor creating an alert in dependence on the retrieved data being different from the stored data.

In embodiments the comparison is performed periodically.

In embodiments the comparison is performed on receiving a comparison request from the buyer.

Embodiments comprise the step of receiving a buyer input request including seller identification data associated with the tender requirement specification identifying sellers authorized to access the tender requirement specification, authorizing a seller requesting access to the tender management server, and limiting access to tender requirement specifications to which the seller is authorized .

Embodiments comprise the step of receiving a buyer input request including at least one of an input access period data, input access period data comprising at least one of an opening time, a closing time and an opening duration, during which authorized sellers may access the tender requirement specification.

Embodiments comprise receiving a buyer input request including seller input requirements including mandatory category information response requirements.

Embodiments comprise receiving a seller request to access the tender requirement specification and, on receipt of the seller request, providing access to the tender requirement specification in dependence on the seller being authorized to access the tender requirement

specification. Embodiments comprise providing access to the tender requirement specification in dependence on the seller request being received at a time during which authorized sellers may access the tender requirement specification.

Embodiments comprise receiving a seller request to retrieve selected seller data stored in the product database associated with buyer selected product category information . rise retrieving seller

when the seller interf

quirement specification

ller data to the seller

Embodiments comprise the steps of identifying any

uncompleted mandatory category information response requirements; and, raising an alert in dependence on identifying any uncompleted mandatory category information response requirements.

Embodiments comprise alerting authorized sellers when they may access the tender requirement specification. Embodiments comprise comparing seller data entered into the tender requirement specification, when data is received from multiple sellers, seller data being compared in accordance with predefined comparison criteria. Embodiments comprise receiving a buyer input request including the predefined comparison criteria. Embodiments comprise identifying updates in the product database , and generating an alert to the tender management server in response to an update in the product database. Embodiments of the invention provide an online tender management portal which leverages datapools in the existing Global Data Synchronisation Network which stores product and pricing data, for example in Australia, the National Product Catalogue (NPC) and Master Catalogue Information System (MCIS) technology infrastructure.

Embodiments provide at least some of the following benefits : · Streamline the preparation of tender documentation by sourcing teams .

• Streamline the completion of tender responses by

sellers .

• Streamline the process of collating responses and selecting awards.

• Utilise published NPC data, monitor and support NPC compliance .

• Allow controlled definition and collection of

response information not held on the NPC

Embodiments of the invention do not require existing e- Tendering portals to be replaced. Instead, embodiments of the present invention provide a complimentary online service to deal with the particular complexities and difficulties of managing the large number of specialised line items across many product categories, typical in health care sector procurement, as well as procurement in other industries and sectors . Brief Description of the Figures

Examples of embodiments of the present invention will now be described, by way of example, with references to the accompanying drawings in which:

Figure 1 shows the architecture of an embodiment of a tender management system;

Figure 2 is a high level flow diagram showing the interactions between buyers, Sellers and the tender management server at different stages during the tender process in an embodiment of the invention.

Figure 3 is a flow chart showing steps taken during the creation of a category scaffold in an embodiment of the invention.

Figure 4 is a flow chart showing steps taken during completion by a Seller.

Figure 5 shows examples of status updates provided to the buyer during the tender process.

Figure 6 illustrates status values as indicated to buyers and Sellers in embodiments of the invention.

Detailed Description An example of an embodiment of a tender management system is shown in figure 1. At the centre of the architecture is tender management server 100. Tender management server 100 includes a memory 110 for storing tender management specifications 112 created by Buyers and populated by Sellers. Tender management server 100 also includes processor 120. The processor performs a number of operations related to the tender management server including creation of tender requirement specifications, authentication and identification of users (Buyers,

Sellers and administrators), validation of tender response information, collation of tender responses for evaluation, supervision of message exchanges, monitoring and synchronisation between tender management server and NPC/GDSN.

Tender management server 100 is accessible by Buyers 140 and Sellers 150. Tender management server 100 includes interface 130 to manage data communications in and out of tender management server 110. In the example of figure 1, the tender management server 100 includes Buyer interface 130 (A) dedicated to communications between tender

management server 100 and Buyers 140 and Seller interface 130(B) dedicated to communications between tender

management server 100 and Sellers 150. In embodiments Buyer interface 130(A) and Seller interface 130(B) may be a single interface. Interface 130 is connected to communication networks. Communications network may be a fixed wired network, or a mobile communication network 140. Buyer devices 140(A) and Seller devices 150(A) are connected to communication network 160 in order to communicate with tender management server 100.

National Product Catalogue (NPC) is an electronic database containing details of Sellers' product lists and is mandated by the National e-Health Transition Authority (NeHTA) as delegated by the Council of Australian

Governments (COAG) . As discussed above, the NPC is one of many GDSN-compliant data pools around the world that comply with a global standard administered by GS1. The database includes details of product classifications, product detail, for example in a pharmaceutical product catalogue, a form of drug, for example liquid or a tablet, weight of product and price. The NPC is regularly updated by Sellers as Sellers make changes to their product line, for example, change of price, change of characteristics of the product or withdraw or enter a new product altogether. NPC is stored within catalogue server 180. Typically, catalogue server 180 is managed and maintained by, for example, a government organisation, and provides a central database of available products for different industries . Different catalogues are created and maintained for different industries.

Tender management server includes a network connection to catalogue server 180 via catalogue server interface

130(C). Tender management server 100 accesses data from catalogue server 180 via catalogue server interface

130 (C) .

In an example of figure 1 a tender management server manages tenders in the pharmaceutical industry. In this example, the Buyers may include government agencies buying on behalf of hospitals and health centres, health centres or other companies requiring healthcare products. Sellers 150 can include any company providing healthcare products listed in NPC and, typically, include pharmaceutical companies and other companies operating in the healthcare industry.

Figure 2 provides a high level overview of steps taken during the tender process. Many of the steps described briefly in relation to figure 2 are described in further detail below.

Figure 2 illustrates the steps executed within the tende management server and various user input data streams an actions of a Buyer and a Seller within the tender

management server.

At 205 a Buyer creates a category scaffold within the tender management server. The process for creating a category scaffold is provided in greater detail below. The category scaffold identifies product requirements and other specific requirements of the Buyer. Typically the category scaffold identifies the products a Buyer wishes to purchase and requirements around those products, for example volume, pricing, delivery times, contract period. During the process for creating category scaffold the Buyer may specify time periods during which Sellers can enter responses to the Buyer' s purchase requests by populating the category scaffold.

At 210 the tender is opened to receive responses from Sellers. At 215 Sellers can respond to the Buyer

requests. Sellers provide product information to the category scaffold via the tender manager server. The tender management server also manages any Seller queries raised in relation to the category scaffold at 215. At 220 the category scaffold is closed to Sellers. At this point, further responses and submissions by Sellers are no longer permitted.

At 225 and 230 the Buyer assesses the submissions by various Sellers. The assessment is performed within the tender management server and can be executed based on prioritisation criteria associated with the category scaffold. The final selection of Sellers is made at 230. At 235 a tender management server notifies Sellers of whether or not they have been awarded line items within the tender.

The final stage of the tender management process executed by a tender management server is the ongoing management of the tender. At 240 a Seller issues an amendment request for the category scaffold. The amendment request is made via a Seller interface or as an update from NPC stored within category server 180. The amendment request may be created proactively by the Seller or may be as a result of tender management server polling category server 180 for updates in Seller catalogue lists. At 245 the Buyer is alerted to the amendment request by tender management server and may approve or reject the amendment request. Tender management server manages amendment requests and the approval or rejection of those requests, logs the amendments and updates the category scaffold within the tender management server. At 255 the contract period terminates. The expired contracts and category scaffolds may be stored within tender management server memory for later retrieval or to serve as a template for future tenders .

Creating Category Scaffold

Referring to step 205 of figure 2, a Buyer accesses the tender management server 110 to create a category

scaffold. The Buyer is provided access to the tender management server via Buyer interface 130 (A) . Typically, on requesting access to the tender management server the Buyer is required to provide authorisation data, for example user name and password. Once the Buyer has accessed the tender management server he is provided with access to his account. Within the tender management server the Buyer is presented with a user interface window showing any active tenders . The tender management server also provides access to any closed tenders previously created by the Buyer. In the event the Buyer has also supplied products or services to third party tenders the tender management server will also present active or closed tenders for which the Buyer has acted as a Seller.

All active and terminated tenders are stored within memory 112 of tender management server.

Tender management server may also store templates for tenders which may be generic or which may be specific for the particular Buyer account. Referring now to figure 3, once the Buyer has gained access to his account within the tender management server the Buyer selects a category scaffold at 310. As mentioned above the tender management system may store template category scaffold which may be, for example industry specific, Buyer specific, or has specific terms and conditions attached. Alternatively, the Buyer may select a blank category scaffold. Alternatively, the Buyer may select an existing category scaffold from a previously created tender which may be edited within the tender management server.

Once the scope of a new contract has been determined, the tender preparation process begins with the Buyer Sourcing Team (BST) member creating a list of Categories for which Sellers can propose candidate products at 320. The Category Scaffold

For each Category in a Category Scaffold, one or more Queries are defined to request information about the product being offered. Queries can be selected from a palette of Queries stored in memory 110 including all current NPC attributes in the NPC Data Model and non-NPC Queries that have been used in other contracts (even for other Buyers) . Queries can also be assigned for a

particular sub-category within a Category, for all

Categories within a contract or for all Categories in all Contracts .

Buyer users will have visibility of Category Scaffolds, including Queries but NOT response information, from other contracts and also from other Buyers, and can copy all or part of them to insert into newly created scaffolds .

Each Category will allow entry of free text descriptions and attachment of material useful for Sellers. Attachments will be marked 'private' by default, meaning that they are not visible to other Buyers when browsing Category

Scaffolds . Conversely, if the Buyer changes the setting to 'public' it will allow them to be viewed and copied by other users when creating new scaffolds.

Once the request information has been added to the category scaffold the Buyer may enter further tender related information at 330. Buyers can assign opening and closing date and time values for the tender. This identifies the period during which Sellers may input information into the tender document. The Buyer may also identify Sellers authorised to complete the tender request form. Such Sellers may be identified within a library of registered Sellers or participants within the tender management server. Such a library would be stored within memory 110 of tender management server. The Buyer may also include specific terms and conditions associated with the tender including duration for the tender contract.

The tender management server allows a Buyer to store the tender document in a draft or final state within memory 110. Once the document is identified as being in the final state, tender management server extracts invited Seller information and opening date and time in order to manage the Seller tendering process. Tender Responses by Sellers

Once the category scaffold is completed and finalised by the Buyer the tender management server notifies invited Sellers that a new tender scaffold has been created and that the Seller is invited to reply to the tender.

Typically, the Seller may be notified via an email, SMS notification or other electronic notification means .

Details of the tender scaffold will also be made available within the Seller's account. Information in relation to the Buyer and the opening date and time are made available to the Seller within the notification. The embodiments of the invention enable Sellers and Buyers to configure their account to identify preferred means of notification within their profiles .

When the opening date and time arrive, the tender scaffold becomes visible to all registered Seller users who are alerted and who, again, are alerted with email or SMS notifications or any other requested notification within their profile. Tender management server includes a notification engine 170 connected to the processor and memory. Notification engine is configured to send notifications to Sellers and Buyers throughout the tender process depending on user profiles and tender information associated with the tender scaffold. Sellers access tender management server 100 via interface 130. In the same way as the Buyer, a Seller is required to provide authorisation and criteria to access tender management server 100. After the opening date and time have passed, the tender scaffold becomes visible to registered Sellers within their account held within the tender management server.

When logged in to the portal, Seller users will have visibility of open tenders from all Buyers for which th< have been authorised. Seller users can be authorised by the Buyer to act on any tender or only within selected Contract Scopes.

To participate in a tender, the Seller selects and opens the tender and is presented with the Category Scaffold in one window and their items list in another. The items list will contain all items currently published to the NPC and also any non-NPC items they have used in previous tender responses .

The Items list can be filtered by response values for any Query including NPC attribute values . They can nominate items from their items list for the tender by dragging the item onto a Category within the scaffold. This will associate responses to queries

according to the following rules:

1. Responses that can be satisfied from NPC assigned attributes will be completed using that attribute's value if the item has been published to the NPC. 2. Where an item has not been published to the NPC, or where Query has no assigned NPC attribute and a response exists in the Response Master that has been reviewed within the Buyer-defined time period, it will be completed using that response.

3. Responses described in 2 that have NOT been

reviewed within the Buyer-defined time period will be completed pending Review by an authorised reviewer . Where a Seller has identified an NPC item in the response a link is created between the tender scaffold and the NPC. Specifically, the specific location of the data in the NPC is recorded within the tender scaffold. This link

provides information that allows the tender management server 100 to poll the NPC within catalogue server 180 in order to check at different times whether the particular product entered in the category scaffold has been updated within the NPC. This link enables the tender management server to ensure that pricing and product information entered within the tender scaffold remains up to date through the tender process and the ongoing contract. The address of the product information within NPC is stored within the tender scaffold.

Once al 1 automatic responses have been assigned, there may be Queries that remain un-responded to, for instance if a new Query has been created for the tender by the buyer. The Tender Manager can respond to these or assign a

Reviewer for the new Query.

Tender management server 100 also includes Validation Engine 125. Validation engine 125 stores rules created by the Buyer and relating to the category scaffold.

Validation engine 125 compares Seller responses with rules set by the Buyer to identify whether responses comply with the rules within the category scaffold. In the event that responses do not comply with the rules, for example a required line item is not completed, validation engine triggers an alert to identify the missing information or error .

The Category Scaffold will facilitate a communication channel between Buyers and Sellers while the tender is open, allowing tender-related questions to be asked by Sellers that the Portal will then distribute along with their answers to all tenderers.

As items are nominated and Queries are satisfied by responses, the Portal will detect:

The latest version of GS1 rules the item was validated to .

If the item complies with the current GS1 rules. Any responses that do not comply with the current GS1 rules.

Any Buyer mandatory queries that have not been responded to.

The Portal will display the number of days (if greater than one day) , hours (if greater than one hour) or minutes (if less than 1 hour) remaining to the Tender close date/time. Profile will allow definition of reminder email or SMS alerts for approaching tender deadlines . When the Seller is satisfied that all queries have been satisfactorily responded to, they will commit their tender responses through an online submission process. Again, validation engine 125 will validate that responses meet the Buyer rules. In embodiments, validation engine prevents submission of a Seller response if the responses to not meet the Buyer rules.

Responses will not be made available to the Buyer at tender close unless they have been submitted by the

Seller, but the Portal will allow changes to responses after submission up until closing time.

Seller' s Tender Managers will be allowed to revoke

Submissions prior to tender close if they choose not to participate in the tender.

Tender or Closure of Tender When the tender close date and time passes, tender management server limits editing access to the tender scaffold by Sellers . Product details and links to NPC may no longer be edited. In certain cases editing access to the entire tender scaffold will be terminated and any other updates managed through the Seller's profile. In embodiments, the Sellers will be able to view the tender scaffold and their response within their account.

However, will be able to unable to edit responses to their tender submission.

At this point, notification engine 170 notifies the Buyer that the tender application process is complete and that the tender responses are available to view within the Buyer account of the tender management server. Buyer Access to Collated Responses

After the tender close date and time has passed, all Seller responses are available to be viewed by the Buyer within the tender management server. The Buyer can select to retrieve the category scaffold from memory 110.

Responses from Sellers are collated into the categories for comparison by the Buyer. Tender management server stores the Buyer selection criteria along with the category scaffold. Processor 120 can filter and sort the Seller responses using criteria originally provided by the Buyer in order to assist assessment of Sellers' products and responses. The Seller data is compared in accordance with the predefined comparison criteria.

A Buyer is able to select Sellers to provide particular line items within the category or the tender scaffold. The Buyer moves the tender to a final "Awarded" status by choosing the successful Sellers line item or line items for each category in the Category Scaffold.

Typically, Sellers who are unsuccessful against a

particular line item and response will be notified automatically using email, SMS or any other preferred communication channel by tender management server

notification engine 170 when the tender status moves from closed to awarded. Sellers who are successful against particular line items will be notified, again by the notification engine 170. For successful Sellers, the tender management server enables communications to be exchanged between the Buyer and Seller via the tender management server. Preferably, all private e-messages exchanged via the tender management server are recorded by the server. Ongoing Monitoring of NPC

After finalising the tender scaffold and Seller selection, the tender scaffold contains links to the Seller' s NPC catalogue as discussed above. Processor 120 of tender management server interrogates the NPC to retrieve up to date catalogue information for those line items appearing within the tender scaffold. Processor 120 prompts retrieval of Seller product data from the address

identified within the tender scaffold. The processor provides the retrieved data to product comparison engine 190 along with the product data from the tender scaffold. In the event that the retrieved data from the NPC does not match the product data within the tender scaffold the product comparison engine can generate a notification.

Typically, the notification may identify that there is an inconsistency between the NPC and the tender scaffold. Alternatively, the notification may include additional detail about the differences between the NPC and the tender scaffold. Notification engine 170 may then send notification to the Buyer of the inconsistency.

In further embodiments, The NPC/GDSN will automatically forward updates of discrete products from the supplier' s catalogue to the tender management server 100. When the updates arrive, the updates will be filtered for

information that relate to currently monitored tenders. If the update causes any relevant piece of information to change, the Buyer will receive a notification to this effect.

These embodiments enable updates to the suppliers' NPC catalogues to be pushed to tender management server 100 or pulled to tender management server. Some embodiments of the system include push and pull functionality for catalogue updates. Notification engine may also send notification to the Seller that any consistency has been identified. In some embodiments the NPC data may include the time and data which the catalogue was updated by the Seller. The tender management server may be configured to trigger an alert only if the inconsistency is identified a predefined time period after the catalogue has been updated. This time period is provided to give Sellers the opportunity to update the tender scaffold after updating the catalogue at the NPC.

In some embodiments in the system the data is retrieved from the NPC periodically, for example each day or week. In other embodiments the tender management server provides a facility for the Buyer to prompt a comparison of data between the Seller catalogue stored in the catalogue server 180 with the products and pricing of the tender scaffold . The tender management server 100 will monitor the stream of updates from Sellers to ensure that the awarded prices are published to the NPC. The Buyer will be notified of prices not published or updated by the Seller within the prescribed time limit.

The server will continue to monitor NPC updates relating to awarded products, with any amendments to price or other NPC assigned queries notified to the Buyer for approval before updating the master copy in the Buyer' s MCIS instance.

End of Contract

At End of Contract, amendments will no longer be allowed and monitoring will cease. Contract information wil1 remain visible in the portal (and in the Buyer's MC IS instance) until the Buyer chooses to remove and archive it .

Referring now to figure 5, during the life cycle of the tender, the status is identified to the buyer within the buyer' s user account accessible through the tender management server 100.

Different statuses are identified as the tender

progresses.

At 510 the tender scaffold has been created and is in a draft form being populated by the Buyer. During this stage, the Buyer is assigning categories and queries within the tender scaffold. Also, during this period any specific requirements of the tender including

identification of Sellers who will be authorized to access and respond to the tenders are being assigned. The timing for opening and closing the tender is also entered during the tender scaffold preparation stage.

At 520 the Buyer has finalized the tender scaffold. All categories and queries are complete and the tender opening and closing dates and times have been assigned.

Typically, during this period the document is finalized and may not be edited by the Buyer.

At 530 the tender scaffold is open for Sellers to make submissions. Depending on the Buyer profile or selected Buyer criteria, the Buyer may or may not be able to view intermediate submissions by the Sellers. Typically, a Buyer is not permitted access to a Seller' s response until the Seller has finalized that response.

At 540 the tender is closed to Seller submissions. After this time the responses of all Sellers are made available to the Buyer in order that the Buyer can undertake the assessment process.

550 identifies the stage at which all awarded products have been selected and notified to successful Sellers. During this period, amendments and NPC compliance are monitored as discussed above and changes are logged and notified to the Buyer as discussed above. Once the contract end date and time has passed, the contract is no longer in effect and the tender scaffold is illustrated to the Buyer as indicated in 560. During this period the tender scaffold is still available to the Buyer for viewing purposes also for editing or use with further or future tending scaffolds.

Figure 6 shows the status values indicated to Buyers (as previously shown in figure 5) and Sellers. Certain statuses are only visible by the Buyer or Seller and others are visible by both, as now explained in relation to figure 6.

As discussed above in relation to figure 5 the creation and preparation of the tender scaffold are visible to the Buyer at 610 and 620. The statuses are not visible to the Seller since, at this stage, the Seller has not been invited to participate in the tender process .

The Seller is provided with a more detailed update status confirmation during the response period at 630. When the tender is open for Sellers to make submissions the status at 631 is identified to the Seller within the Seller account in the tender management server. During the period at which the Seller is preparing the response error messages 632 and attention messages 633 are alerted to the Seller if responses are incomplete or include errors. The error messages are raised by validation engine 125 during comparison between responses and response rules, typically specified by the Buyer or as part of the GDSN standards . For example, the error message 632 may be identified if at least one mandatory response query is incomplete or invalid. In this case, the submission would be blocked until the error is corrected. Further attention icons may be flagged if, for example all mandatory response queries are complete and valid but at least one non-mandatory response query is not complete. The attention icon identifies a secondary error which does not prevent submission of the response but is advised to be completed.

Once all response queries are complete and valid, the status is updated to ready as identified at 634. After the response has been submitted, a submitted icon is identified to the Seller at 635. In embodiments,

amendments may still be allowed until the tender close date. Once the Seller response has been submitted, the Seller will be issued with a notification, for example an email, SMS or other type of electronic notification, for their submission by notification engine 170.

Once the tender close date and time has passed, the Sell status is updated to closed. After this time the tender is closed to further service submissions and amendments.

Depending on the outcome of the tender process, the Sells is alerted to whether the items have been awarded or not awarded after the assessment of the tender has been completed by the Buyer. In the event the Seller is awarded various line items the Seller can request

amendments until the end of the contract. In the event that the Seller is not awarded any line items at 652 the Seller can delete the tender from the account.

After the contract end date and time has passed, the contract is no longer in effect and the Seller is alerted at 661. At this stage, the Seller can delete the tender scaffold from the account, Alternatively, the Seller may prefer to retain the tender scaffold for future reference.

The NPC discussed above is one example of a data pool with which embodiments of the present invention can interact. It will be clear to those skilled in the art that

embodiments of the invention can work with any GDSN compliant data pool.

In the embodiments described above, Sellers provide product information and links to the NPC within the category scaffold document. In further embodiments, responses from Sellers are not stored within the category scaffold but, instead, are stored within a separate tender response document. The tender response document includes details of the Seller and the category scaffold to which it is associated. Tender response documents are completed by the Seller in the same way as described above in relation to the category scaffold, including links to NPC and other information added by the Seller. Tender response documents are provided to the Buyer either when the document is completed and approved by the Seller or when the time period for the tender is closed.

As discussed above in relation to a Seller response completed within a category scaffold, responses within the tender response document that can be satisfied from NPC assigned attributes will be completed using that

attribute's value if the item has been published to the

NPC. Where an item has not been published to the NPC, or where Query has no assigned NPC attribute and a response exists in the Response Master that has been reviewed within the Buyer-defined time period, it will be completed using that response. Responses described above that have NOT been reviewed within the Buyer-defined time period will be completed pending Review by an authorised

reviewer .

Where a Seller has identified an NPC item in the response a link is created between Seller response document and the NPC. Specifically, the specific location of the data in the NPC is recorded within the Seller response document. In preferred embodiments this includes both GTIN and attribute reference. This link provides information that allows the tender management server 100 to poll the NPC within catalogue server 180 in order to check at different times whether the particular product entered in the Seller response document has been updated within the NPC. This link enables the tender management server to ensure that pricing and product information entered within the buyer response document remains up to date through the tender process and the ongoing contract. The address of the product information within NPC is stored within the Seller response document.

Once all automatlc responses have been assigned, there may be Queries that remain un-responded to, for instance if a new Query has been created for the tender by the Buyer, The Tender Manager can respond to these or assign a

Reviewer for the new Query,

Seller response documents are stored in memory 110.

Definitions Seller

Typically a manufacturer or primary provider of goods or services consumed by buyer organisations. Buyer

Entity receiving product and pricing information published via the NPC and who prepares and issues tenders in which Sellers can participate. This includes State Health

Jurisdictions and other Healthcare consumer organisations.

Contract Scope Contract Scope describes the types of products that are being requested in the tender and usually form part of the contract name. E.g. "Medical and Industrial Gases",

"Enteral Nutrition Support and Services" and "Wound Care Products" are all Contract Scope names.

While there are scope names that are identical or are worded differently by jurisdictions but represent the same scope, there are also product groups that are scoped differently between jurisdictions. The portal must allow differently scoped contracts to exist while offering the opportunity for organisations to gradually move to a unified scope structure over time.

Claims

1. A tender management server comprising:

buyer interface configured to receive a buyer input request to create a tender requirement specification;

a processor arranged to create a tender requirement specification in response to the buyer request, the tender requirement specification identifying at least one product required by the buyer,

storage repository configured to store the tender requirement specification;

network interface, configured to connect the tender management server to a product database across a

communications network;

the storage repository being configured to store the retrieved data in the tender requirement specification, and being further configured to store a record of a location within the product data base from which the data was retrieved.

2. The tender management server of claim 1 further comprising a data comparison module, the data comparison module comprising a processor for retrieving data from the recorded location within the product database and

3. The tender management server of claim 2 wherein the data comparison module performs the comparison

periodically .

4. The tender management server of claim 2 or 3 wherein the data comparison module performs the comparison on receiving a comparison request from the buyer.

5. The tender management server of any of claims 1 to 4 wherein the buyer interface is configured to receive a buyer input request including seller identification data associated with the tender requirement specification identifying sellers authorized to access the tender requirement specification, the tender management server further comprising an authorization module, the

authorization module configured to authorize a seller requesting access to the tender management server, and further configured to limit access to tender requirement specifications to which the seller is authorized.

6. A tender management server according to any of claims 1 to 5, wherein the buyer interface is configured to receive a buyer input request including input access period data, input access period data comprising at least one of an opening time, a closing time and an opening duration, during which authorized sellers may access the tender requirement specification.

7. A tender management server according to any of claims 1 to 6, the buyer interface is configured to receive a buyer input request including seller input requirements including mandatory category information response

requirements .

8. A tender management server according to claim 1 wherein the seller interface is configured to receive a seller request to access the tender requirement

specification and, on receipt of the seller request, the customer interface provides access to the tender

specification.

9. A tender management server according to claim 8, wherein the seller interface provides access to the tender requirement specification in dependence on the seller request being received at a time during which authorized sellers may access the tender requirement specification.

10. A tender management server according to any of claims 8 to 9, wherein the seller interface is configured to establish a connection to the product database in response to receiving seller request data.

11. A tender management server according to claim 10 wherein the seller interface is configured to receive a seller request to retrieve selected seller data stored in the product database associated with buyer selected product category information.

12. A tender management server according to any of claims 8 to 10, wherein the tender management server is

configured: to retrieve seller data stored in product database when the seller interface provides access to the tender requirement specification; and, display the retrieved seller data to the seller.

13. A tender management system according to any of claim 5 to 11 wherein the contributor request data comprises a tender requirement specification complete request, the tender management server configured to: identify any uncompleted mandatory category information response requirements; and, raise an alert in dependence on identifying any uncompleted mandatory category information response requirements .

14. A tender management system according to any of claims 3 to 12 wherein the tender management server is configured to alert authorized sellers when they may access the tender requirement specification.

15. A tender management server according to any preceding claim further comprising a comparison engine configured to compare seller data entered into the tender requirement specification, when data is received from multiple sellers, seller data being compared in accordance with predefined comparison criteria.

16. A tender management server according to claim 15 wherein the buyer interface is configured to receive a buyer input request including the predefined comparison criteria .

17. A tender management system comprising the tender management server of any of claims 1 to 16 further comprising a database monitoring engine, the database monitoring engine identifying updates in the product database, and generating an alert to the tender management server in response to an update in the product database.

18. A method for generating a tender document comprising the steps of:

receiving a buyer input request to create a tender requirement specification; creating a tender

requirement specification in response to the buyer request, the tender requirement specification identifying at least one product required by the buyer,

storing the tender requirement specification;

connecting the tender management server to a product database across a communications network;

receiving seller request to populate the product required by the buyer in the tender requirement specification using data retrieved from the product database across the communications network;

storing the retrieved data in the tender requirement specification, and storing a record of a location within the product data base from which the data was retrieved.

19. The method of claim 18 further comprising the step of retrieving data from the recorded location within the product database and comparing the retrieved data with the stored data, the processor creating an alert in dependence on the retrieved data being different from the stored data .

20. The method of claim 19 wherein the comparison is performed periodically.

21. The method of claim 18 or 19 wherein the comparison is performed on receiving a comparison request from the buyer .

22. The method of claims 18 to 21 comprising receiving a buyer input request including seller identification data associated with the tender requirement specification identifying sellers authorized to access the tender requirement specification, authorizing a seller requesting access to the tender management server, and limiting access to tender requirement specifications to which the seller is authorized.

23. The method of claims 18 to 22, comprising receiving a buyer input request including at least one of an input access period data , input access period data comprising at least one of an opening time, a closing time and an opening duration, during which authorized sellers may access the tender requirement specification.

24. A method according to claim 18 to 23, comprising receiving a buyer input request including seller input requirements including mandatory category information response requirements .

25. A method according to claim 18 comprising receiving a seller request to access the tender requirement

specification and, on receipt of the seller request, providing access to the tender requirement specification in dependence on the seller being authorized to access the tender requirement specification.

26. A method according to claim 25, comprising providing access to the tender requirement specification in

dependence on the seller request being received at a time during which authorized sellers may access the tender requirement specification.

27. A method according to claim 25 or 26, wherein the seller interface is configured to establish a connection to the product database in response to receiving seller request data.

28 to claim 27

eve selected

sociated with

product category information.

29. A method according to claim 25 to 28, comprising retrieving seller data stored in product database when the seller interface provides access to the tender requirement specification; and, displaying the retrieved seller data to the seller.

30. A method according to claim 25 to 29 comprising the steps of identifying any uncompleted mandatory category information response requirements ; and, raising an alert in dependence on identifying any uncompleted mandatory category information response requirements.

31. A method according to claim 20 to 30 comprising alerting authorized sellers when they may access the tender requirement specification.

32. A method according to any of claims 18 to 31

comprising comparing seller data entered into the tender requirement specification, when data is received from multiple sellers, seller data being compared in accordance with predefined comparison criteria.

33. A method according to claim 32 comprising receiving buyer input request including the predefined comparison criteria .

34. A method according to claim 18 to 33 comprising identifying updates in the product database, and

generating an alert to the tender management server in response to an update in the product database.