Management of tender process facilities

Offer statuses is a register from which offers are given an internal status code and a name localized to the store's data language. One status is the default for new offers, and the other statuses are used to record the progress of the offer.

The status register itself does not define allowed transitions or an automatic offer pipeline. The user can select any status in the register for an offer.

Offer statuses: define the stages of the offer process

Offer statuses define the stages of the offer process using code, localized names, and default notation. For example, the codes request_received , proposal_sent , accepted , and rejected can describe your own process, but the system does not enforce this vocabulary or order. Plan your codes and names before deployment so that reporting, integrations, messaging, and status history use the same meaning.

The Status page displays the columns ID , Code , Name , Default , and Actions . The status name comes from the localized row corresponding to the administrator's data language. When creating a new status, a name is required for each active data language in the store.

Quote statuses are located at /quotes/statuses . Status is different from quote submission, acceptance, conversion to order, or CRM transaction status.

Design codes and names

Plan the codes and names for the bidding process before creating the first space.

• Use the code as a technical, language-invariant identifier.
• Use vocabulary that is understandable to the customer and the team.
• Keep the code and each name to 32 characters or less.
• Give each active data language a name.
• Avoid two different states with the same meaning.
• Decide on one safe default for new offers.

The UI and service allow you to edit the code later, so the code is not technically locked in. However, treat it as a permanent contract, as integrations and UI color schemes can identify certain codes.

The current service does not check the uniqueness of the code. Do not create two spaces with the same code, as code-based identification may become ambiguous.

Create a new quote status

Create a new quote status for all data languages with one form.

1. Open RFQ > Quote Statuses .
2. Select New Mode .
3. Enter Code , maximum 32 characters.
4. Enter a name in each data language displayed, up to 32 characters per name.
5. Enable Make this the default status for offers only if the new status applies to all new offers.
6. Select Create a space .

The creation adds one localized row for each active data language for the same status ID. An empty or too long name will prevent saving.

If the new state is set as the default, the default ID in the settings will change to the new state. The old state will remain in the registry and for existing offers, but it will no longer be the default.

Choose a safe default mode

Choose a safe default mode depending on when a new offer is created.

The default is displayed in the Default column of the list. One status corresponds to the DEFAULT_QUOTES_STATUS_ID setting, so only one status is the active default at a time.

The switch for the current default mode is locked in the edit form. You cannot remove the default by disabling the switch; open another mode, enable its default switch, and save.

Changing the default does not change the status of existing quotes. It affects new workflows that use the default quote status setting.

Edit offer status

Edit the quote status using the Edit function on the row.

1. Open editing.
2. Update the necessary language-specific names.
3. Do not change code without impact analysis.
4. Enable the default switch if you want to move the default to this state.
5. Select Save status .

Changing the name will update the display name for that language row. It will not change the status ID or remove references to offers or status history.

The code change is updated to all language lines in the status. Status history refers to the status ID, but other integrations that use the code or UI tone definitions may not follow the new meaning.

Remove unused space

Only remove unused space after checking usage and defaults.

1. Select Delete from the row.
2. Wait for the usage amounts to load.
3. Check Offers , History Lines , and Default .
4. Select Remove Status only if all blocking conditions are gone.

Deletion is prevented if the status is default, if at least one offer uses it, or if it appears in the offer's status history. A usage load error also prevents deletion.

The deletion window displays the status ID and name, as well as a separate confirmation function. The server checks the same conditions again within the transaction before deleting the language rows.

If the status is used by offers, change their status first. The presence of the status in history prevents deletion even if no current offers are using it anymore.

Change the status of an individual offer

Change the status of an individual offer using the status function on the offer details page.

1. Open the offer.
2. Open mode switching.
3. Select a new state from the register.
4. Add a comment if necessary.
5. Decide separately whether to enable Notify Customer .
6. Confirm the change.

The change saves the offer's new status ID, writes the change to the audit trail, and adds a status history line to the offer. The comment belongs in this history line.

The client is not automatically notified of every change. Notify client is disabled by default. When enabled, Symfony will ask the MVC email service to send a status message; the sending may still fail after saving the status.

Plan customer communication

Plan customer communications based on the localized space names that are passed to the email service.

The status change email request includes the name of the selected status, a comment, the customer ID, and the email. The status must therefore be understandable in the recipient's language, and the offer must include the correct customer email.

Don't promise based on the status register that the customer can always open or accept the offer from the email link. This depends on the separate submission and checkout workflow of the offer, not just the status change.

If the email service fails, the state change remains in effect and the failure is returned as a separate notification result. Check the delivery of the message before assuming the customer has received the notification.

Impact on online shopping

The effect of an offer's status on the online store depends on the separate services of the offer. Editing the status register does not in itself change the price, balance, availability or checkout of the products.

The status name visible to the customer can be passed to an optional status change email. Opening, accepting, and converting a quote to an order use their own functions and agreements.

Changing the status name or code does not change the quote lines or prices. Changing the default status does not update old quotes.

Good to know

Good to know about the Offer facilities:

• The code and language-specific name are mandatory and can be up to 32 characters long.
• A name is required for each active data language during creation.
• The code can technically be modified, although it is best to treat it as a permanent contract.
• The uniqueness of the code is currently not validated.
• Only one mode is default at a time.
• You cannot delete a space that is in default, promotional, or historical use.
• Status change does not send an email unless Notify Customer is enabled.
• Failure of the email does not cancel the saved state change.