SO Transaction Type

The Inactive Line flag can be selected on Modification Draft SO transactions in CGI Advantage. The following general rules apply to this field on transactions of the SO Transaction Type. (Rules that apply only to specific components are listed with the component in the table below):

• The Inactive Line flag cannot be set to True on a new line.

• The Inactive Line flag cannot be selected unless the Solicitation Status is ”Open” (that is, the Solicitation Closing Date and Solicitation Closing Time have not passed, the Solicitation has not been awarded, or the Solicitation has not been cancelled).

• Inactive lines are not copied forward into a target transaction.

• If the Hide Inactive Procurement Lines flag is selected when printing the SO transaction, then only the active lines are printed. If the Hide Inactive Procurement Lines flag is not selected when printing the SO transaction, then the active and inactive lines are printed.

• If the Hide Inactive Procurement Lines flag is selected when assembling the SO transaction, then only the active lines are assembled. If the Hide Inactive Procurement Lines flag is not selected when assembling the SO transaction, then the active and inactive lines are assembled. (Refer to the "Understanding the Assembly Process” section in this user guide, for more information on the Assembly functionality.)

The Inactive Line flag is included on the following Solicitation tabs:

On the PRDOC table the Lock Order Specs indicates if vendors can bid with alternate Commodity Specifications than those specified on the RQ and SO Transaction Types. If this check box is selected then it defaults the value to Yes on the transactions and this indicates that the vendor cannot bid with alternate specifications. If the check box is unselected, it defaults the value of No on the transactions and alternate specifications can be submitted.

In the actual RQ types of transactions the PRDOC value can be overridden by selecting a different value on the Lock Order Specs CVL before submitting to final. Valid values are Blank, Yes, or No. If the SO transaction references a RQ Transaction Type then the value of the Lock Order Specs CVL is defaulted from the RQ Transaction Type, else the value is defaulted from the PRDOC table. Similar to the PRDOC, the default value can be overridden on the transaction.

On modified version of SO Transaction Type, the value of Lock Order Specs CVL cannot be changed from No to Yes on an existing commodity line. If a new commodity line is added on the modification version of the Solicitation transaction (that was not present on the previous version), then the Lock Order Specs CVL can be set to either Yes or No.

A buyer can make changes to the Solicitation transaction any time prior to the Solicitation being released. Once the Solicitation has been published, changes to the Solicitation are tracked in the form of amendments. Notification of amendments will automatically be sent to vendors on the vendor list (as previously described) and vendors that have responded but were not on the list. The Prohibit Online Responses flag can be modified in a Solicitation Amendment if the flag is being changed from true to false, allowing online bids to be submitted. However, the Prohibit Online Responses flag may not be modified in a Solicitation Amendment if the flag is being changed from false to true, prohibiting online bids to be submitted. In short, once a Solicitation has been finalized, the Buyer can allow online responses to that Solicitation if they were originally prohibited, but the Buyer cannot prohibit online responses to that Solicitation if they were originally allowed. This is because once the Solicitation has been finalized and the Let Date has passed, a vendor may have already responded to that Solicitation. A buyer cannot change the Restrict Multiple Responses per Vendor TIN flag during a modification of a submitted Solicitation transaction.

The following steps identify the amendment process of an open published Solicitation transaction in CGI Advantage Procurement:

1. Open Solicitation transaction, click Edit and make changes.

2. An Amendment Number will be automatically assigned.

3. The amended solicitation will be posted to the web after the modification is finalized. Amendment detail may also be posted to the web. This is controlled by a publishing option.

4. All vendors that were originally notified are notified of the amendment along with any vendors that have responded to the Solicitation.

A Solicitation transaction can reference all Requisition transactions. Information from a Requisition transaction can be copied forward to the Solicitation transaction, thereby eliminating the need for re-keying. You may also select individual RQ lines from multiple procurements. 

A Solicitation transaction can be referenced by the Solicitation Response transaction the Evaluation transaction, all PO transaction types, and the Master Agreement. Transaction references are defined on the Transaction Allowable References (DARF) table. 

Along with the ability to print the Solicitation, when a vendor has a Correspondence Type of Postal Service, you can generate a separate mailing label for the corresponding Solicitation. The mailing label includes the following fields:

• Vendor Name

• Solicitation Description (30 - characters)

• Street 1

• Street 2

• City, State Zip

The SO Transaction Type contains several delivered Transaction Codes. Each Transaction Code varies based on the functionality that is associated with them. Differences may also exist based on site specific setup on the Transaction Control (DCTRL) table and Procurement Transaction Control (PRDOC) table. The full list of delivered Transaction Codes is as follows: