PO_EMAILPO_EX | Services

Services |  PO_EMAILPO_EX.wdl

1. Start

• The workflow begins either automatically on PO Send event or when certain table conditions are met.

2. Get Creator

• Retrieves the email address of the user who created the PO, placing it in the variable CreatorEmail.

3. Check Attachments

• Looks for associated document attachments for the PO.

• Decides if a template for attachments should be used (AttachTemplate) based on search results.

4. Check Vendor

• Checks if the vendor has a valid email address and flags if emails should or should not be sent.

• If special codes (like 'DM' for "Do Not Mail") are set, then it disables email sending.

• Sets up email content and recipients for the vendor notification.

5. Run CDD (Report)

• Executes a report (OSPO5000) based on the PO info. Prompts for PO number and requisition number.

• Preparation for archiving or sending the report.

6. Report Archive

• Archives a report as an attachment for the PO by running a specific report and associating it with the PO record.

7. Email to Vendor

• Sends the PO (PDF or other attachment) to the vendor's email address with appropriate CC to the purchasing department.

8. Email to Someone Else

• If the PO was not emailed to the vendor (no valid email), sends a notification to the creator and purchasing instead.

9. Clear Req Code

• Clears a status/request code on the PO in the database, likely to reset workflow status for the PO.

10. Hold

• A timed, manual or automated hold for approvals or reviews, typically for a few minutes.

11. Attach PO

• Triggers the attachment of documents to the PO (XML/database update), such as scanned or electronic versions.

12. Reprint

• If a reprint is triggered, increments a counter in the PO record and logs the activity.

13. Punchout Email/cXML

• Supports punchout workflows (integration with supplier catalogs via cXML). Sends cXML documents for specific POs.

14. Error Handler

• In case of workflow failure at any step, sends an error notification to administrative users.

15. End

• Final "end" step to mark workflow completion.

Workflow Logic / Conditional Branching

• The workflow is governed by a set of transitions, moving from one activity to another based on:

  • Values of request codes (ReqCodes10 ...), status fields, or XML attributes

  • Results of attachment or email lookups

  • Whether it's a "regular PO", a "punchout" PO, or a "reprint"

  • If a vendor email is available, and "DoNotMail" is not set, it proceeds with the vendor email step

  • If not, the creator or purchasing department is notified

• The model also supports repeated attempts and can retry certain steps on timeout or error.

Error Handling

• If any exception or error occurs, the model notifies workflow administrators and moves to the End activity.