Payment Attributes
Summary
Payment 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: 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.
If Selected, the Save Action must be visible to the workflow owner with as a button or on the quick action. See https://heuristicsolutions.atlassian.net/browse/LB-2796. The same is NOT required of the Action selected as the “On Success Execute Step” action.
Application Fees for initial or re-certification applications
Course Publishing Fees for Provider-managed Activity content
A fully refunded Payment becomes available for payment again;
A partially refunded Payment does NOT become available for payment again.
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.
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. |