This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
versago:record_submission_report_configuration [2019/09/20 09:54] runger [Before You Begin] |
versago:record_submission_report_configuration [2019/11/13 13:45] (current) |
||
|---|---|---|---|
| Line 50: | Line 50: | ||
| The “Record Submission” page is used to configure the report for record selection. When the “Enable Record Submission” checkbox is selected, additional configuration items are displayed. | The “Record Submission” page is used to configure the report for record selection. When the “Enable Record Submission” checkbox is selected, additional configuration items are displayed. | ||
| - | {{: | + | {{ : |
| Also select the “Process Payments” option checkbox if this report will be used for accepting and processing credit card and eCheck payments. | Also select the “Process Payments” option checkbox if this report will be used for accepting and processing credit card and eCheck payments. | ||
| Line 56: | Line 56: | ||
| Configuration of Record Submission reports for payments is described in the documents //Versago – Payments Setup//. | Configuration of Record Submission reports for payments is described in the documents //Versago – Payments Setup//. | ||
| - | See the [[# | + | See the //**[[# |
| ===== Calendar tab ===== | ===== Calendar tab ===== | ||
| Line 82: | Line 82: | ||
| The Selection Screen setup defines what the users sees on the Report page where they select the items for submission. Click the [**View Example**] button to see a generic version of a record selection screen. | The Selection Screen setup defines what the users sees on the Report page where they select the items for submission. Click the [**View Example**] button to see a generic version of a record selection screen. | ||
| - | {{: | + | {{ : |
| - | - The two checkboxes | + | - The two check-boxes |
| - The “Editable field” selection causes a field with the current value (the open balance of an invoice, for example) to be displayed on the selection page and allows the user to change the value (to pay less than the balance, for example). | - The “Editable field” selection causes a field with the current value (the open balance of an invoice, for example) to be displayed on the selection page and allows the user to change the value (to pay less than the balance, for example). | ||
| - The “Show and submit …” selection causes the values the user enters in the editable field for the selected records to be summed, the sum displayed at the bottom of that column and submitted to the next step in the process which is the confirmation screen. | - The “Show and submit …” selection causes the values the user enters in the editable field for the selected records to be summed, the sum displayed at the bottom of that column and submitted to the next step in the process which is the confirmation screen. | ||
| Line 92: | Line 92: | ||
| Here is an example of how the selection page might look, followed by the confirmation page. | Here is an example of how the selection page might look, followed by the confirmation page. | ||
| - | {{: | + | {{ : |
| - | {{: | + | {{ : |
| ===== Confirmation Screen ===== | ===== Confirmation Screen ===== | ||
| Line 100: | Line 100: | ||
| The Confirmation Screen setup defines what the users sees on the page where they review the items selected for submission. This setup is required for payment processing. Click the [**View Example**] button to see a generic version of a confirmation screen. | The Confirmation Screen setup defines what the users sees on the page where they review the items selected for submission. This setup is required for payment processing. Click the [**View Example**] button to see a generic version of a confirmation screen. | ||
| - | {{: | + | {{ : |
| - Check the “Include a Confirmation Screen …” checkbox to provide a screen with a summary of their selections. | - Check the “Include a Confirmation Screen …” checkbox to provide a screen with a summary of their selections. | ||
| Line 115: | Line 115: | ||
| The final piece of the setup process is to define where the information selected by the user will be stored in the database. | The final piece of the setup process is to define where the information selected by the user will be stored in the database. | ||
| - | {{: | + | {{ : |
| - Select a database from the “Database” drop-down list. | - Select a database from the “Database” drop-down list. | ||
| Line 127: | Line 127: | ||
| ====== Submission Database Table Structure Details ====== | ====== Submission Database Table Structure Details ====== | ||
| - | As noted earlier, a table to hold the information related to the selected records is stored in a table in the specified database. All record submission tables have the same basic structure as described | + | As noted earlier, a table to hold the information related to the selected records is stored in a table in the specified database. All record submission tables have the same basic structure as described **// |
| - | + | ||
| - | ^Column Name ^Type and Size^Notes | + | |
| - | |User columns from initial setup appear first | | + | |
| - | |vgo_PaymentDate | + | |
| - | |vgo_PaymentDetails | + | |
| - | |vgo_CC_RespCode | + | |
| - | |vgo_TransID | + | |
| - | |vgo_PaymentType | + | |
| - | |vgo_CreatedBy | + | |
| - | |vgo_CreateDate | + | |
| - | |vgo_CreatedById | + | |
| - | |vgo_PostingStatus | + | |
| - | |vgo_PostingDate | + | |
| - | |vgo_PostingId | + | |
| - | |vgo_BatchId | + | |
| - | |User columns added after initial setup appear last| | + | |
| - | | | | + | |
| - | + | ||
| - | - **Payment Processing** items are used by the internal payment process. These values are only populated for payment transaction. | + | |
| - | - **Creation Information** items are populated for all transactions. | + | |
| - | - **vgo_CreatedBy**: | + | |
| - | - **vgo_CreateDate**: | + | |
| - | - **vgo_CreatedById**: | + | |
| - | - **Processing Control** items can be used to manage back-end processing using tools such as Bizweaver. | + | |
| - | - **vgo_PostingStatus**: | + | |
| - | - **vgo_PostingDate**: | + | |
| - | - **vgo_PostingId**: | + | |
| - | - **vgo_BatchId**: | + | |
| ====== Back-End Processing ====== | ====== Back-End Processing ====== | ||
| Line 168: | Line 139: | ||
| The more sophisticated approach is to initiate the workflow when the submission is saved to the database. For the second option a database trigger is used. | The more sophisticated approach is to initiate the workflow when the submission is saved to the database. For the second option a database trigger is used. | ||
| - | <WRAP center round important | + | The SQL database first needs to be initialized to allow triggered (immediate) processing to occur. |
| - | The following discussions | + | |
| + | <WRAP center round important | ||
| + | Descriptions of the initialization process and examples of various triggers are found **// | ||
| </ | </ | ||
| - | |||
| - | The SQL database needs to be initialized to allow triggered (immediate) processing to occur. | ||
| - | |||
| - | |||
| - | |||