The following sections list the configuration tasks needed to implement the online payment functionality.
When the one-time payment service task processes the payments it relies on standard payment logic in the product. Refer to the payment configuration documentation for configuration options required for general payment processing as well as configuration options for automatic payment processing.
The base product payment distribution rule algorithms that create payments support the ability to direct excess credit to a special obligation rather than crediting the obligation used to levy the taxes. If your implementation uses the base product algorithms, define an obligation type to use when directing excess credit to a special obligation for the account.
In some cases when an account cannot be found for directing a payment, a payment is created in suspense, meaning that it is created for a suspense obligation. If your implementation does not already have a suspense obligation set up, create one.
Define a match type for Obligation. This is used by the Pay a Pay Plan distribution rule.
Create a Distribution Rule - Create Payment algorithm for each supported payment destination.
Pay a Filing Period. If your implementation supports the ability to direct a payment to a filing period, define an algorithm for the algorithm type C1-PAYFRM. In the parameters define the division / obligation type for the excess credit obligation along with the suspense obligation. Finally, define characteristic types for each of the payment details that are required by the algorithm. Note that the product supplies characteristic types that may be used for each one.
C1-DLN for document locator number. Note that this is not expected to be supplied by a taxpayer for web self service payments, but the parameter is required for the algorithm.
C1-TXPID for taxpayer ID
C1-TAXTY for tax type
C1-FLNGP for filing period
Pay a Collection Notice. If your implementation supports the ability to direct a payment to a collection notice, define an algorithm for the algorithm type C1-DR-PAYCC. In the parameters define the division / obligation type for the excess credit obligation. In addition, define the characteristic type that the overdue process uses to log the creation of the customer contact. This allows the algorithm to determine the related overdue process to find the covered obligations.
Pay a Pay Plan. If your implementation supports the ability to direct a payment to a pay plan, define an algorithm for the algorithm type C1-DR-PAYPP. In the parameters define the division / obligation type for the excess credit obligation. In addition, define the match type for referencing the pay plan's obligation.
Pay a Tax Role Balance. If your implementation supports the ability to direct a payment to a tax role balance, define an algorithm for the algorithm type C1-DR-PAYTXR. In the parameters define the division / obligation type for the excess credit obligation.
Pay an Obligation. If your implementation supports the ability to direct a payment to an obligation, you may use an algorithm C1-DR-PAYOBL delivered with the product.
Create a distribution rule for each supported payment destination.
Pay a Filing Period. If your implementation supports the ability to direct a payment to a filing period, multiple distribution rules must be created, one for Taxpayer ID, one for Tax Type and one for Filing Period. Each should reference the appropriate characteristic type. Refer to the create payment algorithm above for details of the characteristic types to use. Note the following points related to configuring these distribution rules:
The payment distribution processing expects that the create payment algorithm is only linked to the last distribution rule.
The payment distribution processing expects that the Determine Tender Account is linked to all the distribution rules.
The payment details processor business service used by the payment service task may expect the definition of the distribution rules to be in a certain order. Refer to the business service description for C1-PaymentDestinationTxTyFilPd for more information.
Pay a Collection Notice. If your implementation supports the ability to direct a payment to a collection notice, create a distribution rule referencing the characteristic type C1-CUSCN Customer Contact. It should also reference the Create Payment algorithm created above for paying a collection notice.
Pay a Pay Plan. If your implementation supports the ability to direct a payment to a pay plan, create a distribution rule referencing the characteristic type C1-PAYPL Pay Plan. It should also reference the Create Payment algorithm created above for paying a pay plan.
Pay a Form (DLN Only). If your implementation supports the ability to direct a payment to a form using DLN only, create a distribution rule referencing the characteristic type C1-DLN GDocument Locator. It should also reference the Create Payment Algorithm created above for paying a filing period.
Pay an Obligation. If your implementation supports the ability to direct a payment to an obligation, create a distribution rule referencing the characteristic type C1-OBLIG GObligation. It should also reference the Create Payment algorithm created above for paying an obligation.
Pay a Tax Role Balance. If your implementation supports the ability to direct a payment to a tax role balance, create a distribution rule referencing the characteristic type C1-TAXRL Tax Role. It should also reference the Create Payment Algorithm created above for paying a tax role balance.
Decide whether or not an email confirmation should be sent to the taxpayer once the payment is processed. If so, add an Enter plug-in to the In Progress state after the payment creation algorithm or perhaps the Complete state to generate the confirmation email.
Taxpayer Identification Task Type
Define a task type to use for taxpayer identification with the business object Taxpayer Service Request Self Service Task Type.
The Related Transaction BO should be set to C1-TaxpayerIdentifySSTask.
Service Task Class should be set to Taxpayer Identification.
To Do Type should be set to a standard error To Do type to use when transitioning to error. The base product To Do Type Self Service Task Issues (C1-SSTTD) is provided for this purpose. Note that the algorithm plugged in on the error state for the base business object checks that there is not already a To Do for the record before creating one of this type. This allows algorithms that detect an error to also create a To Do with a specific type if desired.
To Do Role should be configured to an appropriate default To Do role for the above To Do type. This is optional. If no value is provided the default role for the To Do type is used.
Configure the Confirmation Header Message Category and Message Number and the Error Header Message Category and Message Number to use for communication to the self service user.
The service request fields mapping is used when creating the target service task to correctly populate the requestField list from the list of fields passed in on the web service request XML. For the base transaction business object, the following fields are expected:
Sequence | Transaction BO XPath |
1 | requestData/legalName |
2 | requestData/idType |
3 | requestData/personIdNumber |
4 | requestData/emailAdd |
5 | requestData/addressLine1 |
6 | requestData/addressLine2 |
7 | requestData/city |
8 | requestData/county |
9 | requestData/state |
10 | requestData/postal |
11 | requestData/onBehalfOfFlag |
12 | requestData/secondaryLegalName |
13 | requestData/secondaryIdType |
14 | requestData/secondaryPersonIdNumber |
15 | requestData/secondaryEmailAdd |
Payment Destination Task Types
Create a service task type for each payment destination with the business object One-Time Payment Self Service Task Type. Each service task configured should include the following common configuration.
The Related Transaction BO should be set to C1-StandardOneTimePaySSTask.
Service Task Class should be set to Self Service Payment.
To Do Type should be set to a standard error To Do type to use when transitioning to error. The base product To Do Type Self Service Task Issues (C1-SSTTD) is provided for this purpose. Note that the algorithm plugged in on the error state for the base business object checks that there is not already a To Do for the record before creating one of this type. This allows algorithms that detect an error to also create a To Do with a specific type if desired.
To Do Role should be configured to an appropriate default To Do role for the above To Do type. This is optional. If no value is provided the default role for the To Do type is used.
Configure the Confirmation Header Message Category and Message Number and the Error Header Message Category and Message Number to use for communication to the self service user.
The following configuration differs based on the payment destination:
Payment Distribution Rules. Link the appropriate distribution rule(s) created above for the payment destination represented by this service task type.
Link an appropriate Processor business service or service script that knows how to receive the detail related to the payment destination and create the payment event distribution details correctly. The base product provides one Processor business service for each supported payment destination. Using the search look for business services that begin with C1-PaymentDestination%.
Specify if taxpayer should exist in the system in order to process the payment. Typically this should be set to Yes ("Y") as the taxpayer record is necessary for account and other payment details verification. An example of the exception from this rule is a payment for a form by DLN. When payment is submitted immediately following online form filing the system should be able to accept payment from the self-service user who is a first-time filer. In this scenario the taxpayer record is created during form posting and that may actually happen after payment submission.
Field mappings. For each payment destination detail captured on the service task, indicate the target XPath value in the above processor.
Configure the appropriate Processors for access type-specific logic. For each access type:
Account Verification. This processor verifies whether account determined based on payment destination details is valid for the service request access information. This verification is optional and should be performed according to the business requirements. Account verification is needed if the payment has to be made within the context of the current access entity.
Consider the following example: a self-service user is currently browsing a tax role and attempts to pay a collection notice. Configure account verification for access type Tax Role if you want user to be able to pay only for those collection notices associated with the tax role in context. Using the search look for business services or service scripts that begin with C1-OTPVAc%.
Payments Due. This processor retrieves all pending items belonging to a payment destination within the context of the current access entity. For example, for payment destination Pay an Obligation and access type Tax Role it may retrieve all obligations with an outstanding balance. Using the search, look up business services or service scripts that begin with C1-RetPaymentsDue%.
The examples of payments due retrievers provided out of the box:
Finally, if external vendors are supported, indicate whether or not fees are appropriate based on the taxpayer type.
The product supports two distinct methods of paying a form by DLN:
The self service master configuration record includes several settings required for payment related processing.
Char Type for Overdue Process Log. If your implementation supports the Pay a Collection Notice payment destination, define the characteristic type that is used to link the customer contact to the overdue process. The base product provides a value that may be used.
Refer to the ACH Agreement Validation section below for information about the Char Type for ACH Agreement Verification.
Tender Types. Indicate the tender types that are valid for paying online.
Supported Payment Destinations. For each supported payment destination (as defined in the C1_PAYMENT_TARGET_FLG lookup), indicate the corresponding Service Task Type.
Define the customer contact types that represent the collection notices that a taxpayer may pay online using the Pay a Collection Notice payment destination.
If your implementation requires a pre-signed agreement from the taxpayer when submitting a payment through their bank account, define a characteristic type on the taxpayer, the following configuration is needed:
Create an appropriate characteristic type for ACH Agreement. Define a valid characteristic entity of Person.
Update the master configuration to indicate this characteristic type.
Update the business object C1-StandardOneTimePaySSTask to plug in the validation algorithm to check for the existence of this characteristic. Navigate to the Lifecycle tab and expand the configuration for the Pending state. Add an entry in the Algorithms collection with a System Event of Enter, an appropriate sequence and the algorithm C1-CHKACHAGR.
Obligation types used by the product should have corresponding values defined in the self service product.
Your implementation may decide to use exactly the same values in both products or configure the mapping using domain value mapping in the SOA Composer application
Copyright © 2007, 2016, Oracle and/or its affiliates. All rights reserved. Documentation build: 2.5.2016 10:21:45 [T1_1454696505000]