| Info |
|---|
SummaryPayment Attributes allow administrators to add a fee or other payment to a Workflow Step. |
Overview
The Payment Data Type allows you to require a user to make a payment as part of completing a workflow step such as the following use cases:
As a provider, I must pay a fee to have my activity reviewed and approved so that practitioner can earn credit and the activity can be published in the public catalog.
As a practitioner, I must pay a fee to complete an activity and earn CE credit.
As a practitioner, I must pay a fee prior to submission of my Application/Learning Plan.
Configuration
To create a Payment data type:
Select "Payment" as the Data Type.
Enter a Data Field name.
Optionally Enter a Display Label
Select a source field for the Payment Title or enter static text.
When creating payment on the Complete Activity Workflow, you may want to use the Activity Title as the source field.
The Payment Title appears in the workflow when the user makes the payment. It then appears in the shopping cart to describe the item being purchased.
Once the payment is complete the Payment Title appears in the payment history, on the payment receipt email, and on the PDF invoice so that the payee knows what they paid for. When creating reports, this field is available as the Transaction Line Item Description.
Select a source field for the Payment Amount or enter a static amount.
When creating a payment on the Complete Activity Workflow, if each activity has a different price, you may want to use a numeric field from the Activity as the source field.
The Payment Amount appears in the workflow when the user makes the payment. It then appears in the shopping cart when the item being purchased.
Once the payment is complete the Payment Amount appears in the payment history, on the payment receipt email, and on the PDF invoice so that the payee knows how much they paid. When creating reports, this field is available as the Transaction Line Amount.
Optionally select a source field for the GL Code or enter a static code.
This is the General Ledger code for the transaction. The GL Code does not need to be a true GL Code. Some clients who have multiple programs use the GL Code to simply categorize the payment.
The Payment Amount does not appear in the workflow when the user makes the payment so it is not visible to the end-user. It also does not appear in the shopping cart.
Once the payment is complete the GL Code appears in the payment history only for admins, and, If the payment is processed through PayFlowPro, is passed into the comments field in PayFlowPro. When creating reports, this field is available as the Transaction Line GL Code.
Optionally select a source field for the Terms and Conditions or enter static terms and conditions.
The Terms and Conditions will be displayed in the shopping cart and the user will be required to check a box acknowledging they have read them.
Once the payment is complete, a copy of the text of the Terms and Conditions as they at the time of the payment, are stored with the payment. They are available when creating reports in the Transaction Line Terms and Conditions field.
Terms and conditions are NOT displayed or stored when an admin records a manual payment since the system cannot confirm they were read by the payee.
Optionally enter a Success Message.
The Success Message will be displayed on the payment confirmation page after the payment is complete.
Note: The Success Message can include HTML. If the HTML is malformed, it may cause errors on the Payment Success page.
| Note |
|---|
Note: When choosing a source field, there is a known issue/limitation if you choose an extrinsic field from the reference object or choose a template that references a field. The workaround is to default the field from the reference object into a field on the write-to object and use the field from the write-to object in the Payment Attribute. See FogBugz case 19337. |
When a Payment Data type is included on a workflow step, (and if the field is marked required or a validation rule is created that states that the Payment field must not be empty), the user will have to make a payment before completing the workflow step. The user is presented with a "Pay Fees" button, which, when clicked, takes them to the E-Commerce shopping cart page using the Payment Title, Amount, GL Code, and Terms and Conditions configured for the payment. When the payment is complete, the user is returned to the associated workflow step and is shown the completed payment and transaction ID. At this point, if all other requirements are met for the workflow step, the step can be submitted by the user.
To configure a workflow step action to be executed automatically after successfully making a payment on a workflow:
Navigate to the associated Workflow Step and Edit the Payment attribute
Locate the configuration option "On Success Execute Step:"
Select the Action that will be executed upon the user's making the payment (by default, 'No Action' is selected, which will return the User back to the workflow step after a payment is made)
Select a Save Action.
| Note | ||||||||
|---|---|---|---|---|---|---|---|---|
If Selected, the Save Action must be visible to the workflow owner with as a button or on the quick action. See
|
| Panel | ||
|---|---|---|
| ||
|
| Panel | ||
|---|---|---|
| ||
|
Data Storage
This attribute stores a reference to the TRANSACTION_HISTORY table, pointing to the Transaction that was made to satisfy the payment.
Additionally, a TRANSACTION_LINE_ITEM record will point back to this Attribute value using the PURCHASED_ITEM_ID column.
| Warning |
|---|
There are scenarios in which a Payment attribute can be associated with multiple Transactions:
In these cases, the Payment will only ever point to the most recent Transaction. There may exist multiple Linking those historical transactions to a Payment attribute can only be done by joining on the line item's Description, and only as long as the payment descriptions haven't changed. |
| Warning |
|---|
To make a Payment attribute eligible for payment again, you must delete the Simply setting the attribute value to empty will only partially work; the Attribute will be considered "unpaid", but the checkout process may block progress because a historical |
Know Issues / Limitations
Note | References | |||||||||
|---|---|---|---|---|---|---|---|---|---|---|
| 1 | If a Payment Attribute is used to grant a Role on the Grant Role Workflow, any Learning Plan set to automatically begin when eligible will not begin automatically. |
| ||||||||
| 2 | Unpaid payments render as not needing to be paid instead of the amount due on Next Generation Learning Plan (v2 display mode) Task Group Displays when any of the attribute definition fields for the Payment Attribute are directly referencing a Template Attribute. This issue does not occur in Legacy (v1 display mode) Learning Plans. |
|
Related articles
| Filter by label (Content by label) | ||
|---|---|---|
|
| Page Properties | ||
|---|---|---|
| ||
|