All n One's bxp software Wixi - User contributions [en-gb]

Bxp Release 10 SER 1 release notes

2017-08-11T13:20:02Z

Patrick Jenkins:

bxp Release 10 Service Enhancement Release 1 has no set date for release yet. Cooperation and collaboration with clients is currently in progress.

= Existing Module Changes =

== Appointment Manager [[File:000.png]] ==

=== Interface ===

bxp has two different interfaces for dealing with the Appointment Manager engine. [[Appointment_Management_-_Interface]]
* The first is a pure HTML backwards compliant engine.
* The second is the open source fullcaldendar.io engine https://fullcalendar.io/

[[File:bxpR10SER1_001.png]]

FullCalendar.io has a more limited support base. https://fullcalendar.io/support/

The bxp engine is going to embrace further the fullcalendar.io engine but provide a selectable option to allow clients revert to the pure HTML version if their browsers are incompatible.

This option will be selectable on the Diary Add / Edit screens

The calendar version has been upgraded from the previous 2.3.1 to 3.4.0
* https://fullcalendar.io/blog/2016/09/feature-packed-releases/
* https://fullcalendar.io/blog/2017/03/fullcalendar-33-and-scheduler-16/

The scheduler engine is not included in the release but is under review.

=== Linking facility ===

A facility to add a form record, eCourse reference and a Meeting Manager reference will be included in the data structures.

The linking options will be enabled at a Diary Add / Edit level using the Features field. [[Appointment_Management_-_Features]]

=== Filtering ===

The interfaces will be provided with a filtering engine which will allow filtering by
* Person
* Category
* Duration
* Subject keyword
* Body keyword
* Form link
* eCourse link
* Meeting Manager link

The filtering bar will be an option configured at the Diary Add / Edit level.

The filtering will also be available as a data report listing type, as well as the interactive calendar view.

=== Appointment API ===

A dedicated API will be developed to facilitate add, edit, delete and listing of events.

Responses will be provide in XML and / or JSON depending on FullCalendar.io’s compatibility requirements.

=== Data listing method ===

The current approach for the diary system using FullCalendar.io is a listing for a 6 month historical and 6 month advance listing of events. Outside this window the data doesn’t list.

With the addition of the API, this will allow event data to be loaded in real time, making the window of reportable events universal.

=== “Drag to edit” facility ===

FullCalendar.io supports drag and drop editing. This facility will be enabled by Diary Add / Edit option and also limited by QueryString capability.

=== “Email on edit” facility ===

This change will allow an email to be sent automatically those associated with the event. This facility will be based on Category.

== Communications Centre ==

=== Attachments ===

The bxp email engine is to be expanded to facilitate the sending of attachments with emails. This change will require file management capabilities to be added to the module.

The primary attachments will allow files from the Report Library module to be added to the emails. Delivery rates will be reduced but the facility is sought by numerous clients.

This facility will also provide the basis for outcomes in a form being able to attach documents directly.

=== Communications Report enhancement ===

The current communications reports include a total amount of communications based on the total recipients. If a wrong data source field is chosen by mistake no communications are made but the report identifies that X attempts were made. The reports will be modified to list both values, obvious blank / incorrect data counts and attempted recipient counts.

Using an SMS example : Whilst not validation can be provided on “looks kinda right data”... no values or text in values will result in that attempt not being counted.

=== Mail Merge issues ===

The engine of bxp had a direct integrated link with Word. Create.Object(“Word.Application”)

This used Microsoft Office XP which is no longer supported by Microsoft. As a result the engine has been disabled for security reasons.

An alternate using RTF is being investigated and applied and will be available in this release.

== eCourse ==

=== New Table of Contents layout options ===

The table of contents will be given the option for new styles and approaches. These options are set at a Book level.

==== TOC’less. ====

This approach is for short training courses where it is linear in nature. The pages will be provided with a dot bar system, each dot representing a page. The system will provide a next previous button set as well. This is for getting straight into training. When the user selects the book, they are taken straight to the first page of material of the book, or the last page viewed if the book has been read before.

[[File:bxpR10SER1_003.png]][[File:bxpR10SER1_002.png]]

==== The Moodle’esqe view. ====

This is a university based, drag and drop type interface where material is secondary to the layout. i.e. links to word docs, PowerPoint is more the focus than the presentation of them.

[[File:bxpR10SER1_004.png]]

==== The styled table of contents. ====

As page can be styled, so the ToC can be styled using an asset and key repeating tags within the code.

* header
* chapters
* pages
* stoppointtest
* supportpointtest
* footer

<syntaxhighlight lang="html4strict">
<div class="css_eCourse_Chapter" id="eCourse_Chapter_X">--eCourse_Chapter_Title--<div>
<div class="css_eCourse_Page" id="eCourse_Page_X">--eCourse_Chapter_Page--<div>
<div class="css_eCouurse_StopPointTest" id="eCourse_Chapter_Stop_X">--eCourse_Chapter_Stop--<div>
<div class="css_eCouurse_SupportPointTest" id="eCourse_Chapter_Support_X">--eCourse_Chapter_Support--<div>
</syntaxhighlight>

These four views (including the original) should provide exciting new options for presentation of courses.

== Form Management ==

This area covers all changes to forms and their respective supporting modules, Inbound, Outbound, Case, Quality, Testing, Survey and a new area of management Project

=== Campaign table changes ===

A number of fields will be added to the campaign table to facilitate the forth coming changes
* strCampaign_Prebuild_Type (which of the below prebuilds it is)
* strCampaign_Prebuild_Ids (related ids of forms in the prebuild)
* strCampaign_Prebuild_Role (if there are multiple forms, which form in the relationship is this)

=== Project Header ===

For people who’ve ever used Microsoft Project the concept of work items, tasks, milestones, etc. will be very familiar. Each entry in a record could be considered a line in a spreadsheet, or in our case a record in a form (CDA).

We’re adding a new prebuilt form header question type called Project, to allow a form to become the data storage for a MS Project style amount of data. The interface will be delivered through the Project Management module but the data stored in a form.

To this end a new header type will be made available in bxp to allow any form to become the support for a project.

For details on the header click here
https://www.bxpsoftware.com/wixi/index.php/Form_Project_Header

=== Inbox - onArrival matching engine ===

When BEMail reads an email from an inbox it can create a CDA and log the record.

As part of this mechanism matching and preprocessing can be done on the emails.
[[BEmail_(_Email-2-Campaign_)#Configuring_the_form_to_retrieve_the_email]]

This engine will be expanded to provide two new levels / approaches for matching.

1. email comes in from user@something.com, a search is done on the “Contacts” form to identify which account this belongs to

This first process means that preapproved addresses can be quickly managed and emails allocated to clients for reporting purposes.

2. That contact account is managed by Aiden. Therefore that email is meant for Aiden, so automatically display it in his worklist.

This way, though emails are coming into a general email box they can be allocated to individuals for account management.

This engine can be applied to all forms using BEMail retrospectively

=== Form Prebuilds ===

This engine will forms in bxp to be built very quickly based on templates. These templates are industry best practice layouts as identified by the All n One team to speed up implementations.

==== Prebuild – Inbox manager ====

Give the engine an inbox and it will construct a complete case management solution with appropriate prebuilt associated reporting. Build time currently < 0.5 of a second! More details on this will be available through the wixi

The engine will also provide the onArrival matching engine.

==== Prebuild – Outlook contacts exports ====

Give the engine an export of your contacts from outlook and it will build two forms. One for contacts one for companies. It loads all the contacts into a predesigned and tabbed contacts form. It then uses identification techniques to create the companies entries. It can then link based on email domain and company name fields to quickly build a contacts and companies populated structure.

The engine also facilitates further loads from different people. So user 1, creates the first list and first companies. User 2, like a smart load, can add to the contents and expand the data.

==== Prebuild – Contacts from emails ====

Using outlook, export all the emails to a data file.
Outlook > File menu > Options > Advanced > Export > Export to a file > Choose Excel > Choose what you want to export > Save the file on your desktop

{|
| [[File:bxpR10SER1_005.png | 300px]] || [[File:bxpR10SER1_006.png | 300px]] || [[File:bxpR10SER1_007.png | 300px]]
|}

The output is a file with the following headings

* Subject
* Body
* FromName
* FromAddress
* FromType
* ToName
* ToAddress
* ToType
* CCName
* CCAddress
* CCType
* BCCName
* BCCAddress
* BCCType
* BillingInformation
* Categories
* Importance
* Mileage
* Sensitivity

These can be loaded into a form. bxp instead can use the FromName, FromAddress, ToName, ToAddress, CCName and CCAddress. From these it attempts to extract unique contacts. It then attempts to tidy up the data and store those contacts in a form. In this way previous emails from an outlook folder can be quickly processed into a useable contact list for marketing and other related interactions.

Using the smart update engine the form can allow for multiple uploads.

==== Prebuild – SalesForce data ====

When loading data from SalesForce there are a number of fields and sources of data. Exporting from SalesForce is easy and provides a number of templated files.

{|
| [[File:bxpR10SER1_008.png | 200px]] || [[File:bxpR10SER1_009.png | 200px]] || [[File:bxpR10SER1_010.png | 200px]] || [[File:bxpR10SER1_011.png | 200px]]
|}

Not all of these files are used. It depends on how you use your SalesForce account. In size however the most common used files (ones with the most data ) are usually.

[[File:bxpR10SER1_012.png]]

By uploading key files into bxp and specifying a number of parameters, bxp can auto-build a number of structures, link the data and import the data from SalesForce. The data is then bxp forms and can be used and manipulated as per system requirements.
* Account = company
* Contact = contacts (link contacts to companies)
* Opportunity = sales opportunity (link to account)
* Notes = attached to account (loaded as ccls or as separate form)
* Task = attacked to account (loaded as ccls or as a separate form)
* User = System Access Management mapping to bxp users (the Client table field will contain their SalesForceId)

==== Prebuild – ISO27001 SOA ====

This build is to allow the “Statement of Applicability”, a key requirement of bxp to be almost instantly built in bxp. The form will store documents and updates, whilst a prebuilt keystat provides the headings and numbering system to deliver the requirements of the standard.

This form and keystat can then be easily modified, if needed, to the requirements of the business.

==== Prebuild – Excel no data ====

* To quickly build a form, you can select the top row of a spreadsheet.
* Copy and paste this into bxp
* The columns will be separated by the “Tab” character
* bxp will read the tabs, split the fields and then create a basic text box field for each heading and set the field mapping.
* This should allow very quick form builds and enable perfect field mapping.

=== Complex – Email Block change ===

When a BEMail question is added you get.

[[File:bxpR10SER1_013.png]]

The challenge is the amount of space given to the subject and body of the email. There is over 50% more space to the left of the boxes.

The suggestion is to convert this from being text areas to being text wide boxes which would use the width of the screen and make it easier to read the body of received emails.

This is a layout change rather than a data change, so should only cosmetically affect clients. i.e. JavaScript will not be affected

=== Cross Linked report repair ===

This is identified as a bug that the reports are not working as posted in the Wixi. This will be fixed for the release.

=== Outbound Data Drill down ===

Currently the “Set the Current Working Outcome” engine allows a number to be displayed to allow the user set which group of records are being worked on.

An option on the screen in the form of a drop down list, will allow by default (“Set the stack”) and a new option “View stack”. This view stack when clicked will open in a new tab a report showing the records that are in that stack, using the default fields of the search engine, as per the lookup screen. Upon click those records, they can then be opening in Inbound way (i.e. no taking the record off the stack), to allow an admin review the contents of the records.

=== Create template from form ===

This engine will construct a blank Excel template of a form using the field mapping fields, which will match perfectly, for data to be filled into them.
This should allow mass copying of data into an Excel sheet which will perfectly match and load easily into bxp.

=== Word to form fix ===

Identified as not working with some outputs, a number of fixes are going to be applied to the creation of a form using the text based data input process. These are fixes based off hamsters and reported incorrect logical outputs.

=== Access on Pass ===

This is an outcome extension that allows security permissions, specifically a UAM function and content security permissions application can occur on successful passing of an exam.

A reporting showing the linking is also to be developed, to make management easier.

This process means that career pathing is easier to implement.

=== Outcome Exception Cost ===

This processing engine will allow exception costs to be added by the outcome rather than through AJAX.

Exception costs are discussed in Projects section

=== Data Import timer ===

Main Menu > Form Management > Form - Data Import > Load Data Records – Retrieve Email 2 – Form
(affects anyone using the bemail retrieval to form engine)

Currently if you select this page, it goes Form Selection > Results. There is no landing / timing page.
This change will put a landing page before the downloads begin with a stop watch on it.

Main reasons for this change:
* to provide timing feedback on loading
* to provide better feedback to users that loading is going on
* to provide explanation and troubleshooting wixi links to users more appropriately (i.e. if troubleshooting then the loading page never appeared, how did a user see the links to help themselves?)

=== Record deletion audit log fix ===

Currently grouped record deletion requires a reason to be provided. It has been highlighted that these reasons are not instantly available to users to review. This fix will see the comments and the record Ids being properly logged into the system audit trail for review through System Access Management.

=== Data Profiling - Instant Data Analysis ===

A new report and search tool will be available through ''Main Menu > Data Profiling > Instant – Data > Data – Instant Data Analytics'' with the ability to export the data results to Excel or Instantly Visualise the data.

For more information please read [[Data_-_Instant_Data_Analysis]]

== Information Centre ==

=== Scrolling Information Centre ===

The current information centre for backwards compatibility does not scroll.

This configurable option will be enabled to allow a system setting to choose whether scrolling or not is employed.

Browser detection will also be employed so if the scroller is turned on, but the browser doesn’t support it, the info centre will be static.

=== Access by Security Groups ===

Currently the limiting security engine for messages is based off access to forms. This engine is to be changed to use Security Groups from the Organogram instead.

For historical messages, the security will be maintained but going forward Security Groups will only be available.

For limited access user sends, the user can only send to security groups they are in.

== KeyStats ==

=== Console ===

The security and administration of KeyStats needs some addressing to optimise build and support functions.

A KeyStats console will be made available.

=== Mass Edit Security ===

The mass editing security feature needs to be developed.

This will be included as a function stand alone and as part of the console.

=== Hide Tabs ===

The tabs will be modified to have Ids.
The KeyStat itself will have a flag to show / don’t show the tabs.
By default “show tabs” will be selected.

== MetaData ==

=== Console ===

This console will facilitate easier management of metadata rules and their associated security and reporting.

== Project Manager ==

=== Gantt Chart interface ===

FusionCharts supplies a Gantt chart as part of their reporting suite.
http://www.fusioncharts.com/dev/gauge-and-widgets-guide/gantt-chart/introduction.html

bxp will use the Gantt chart tool to render the Gantt with the data being stored in a form.

A link field will be provided to link the Form to the Project.

The bxp form will need a Project Header block, as discussed in the Form Management section.
https://www.bxpsoftware.com/wixi/index.php/Form_Project_Header

=== Project API ===

This engine will allow tasks, milestones and other data to be add, edit, delete and listed for any given project.

=== Costing ===

The time tracker engine is being expanded to support the application of costs against the various units logged.

The solution will allow three primary data additions to be done per time tracker entry.
* Unit cost
* Sales price
* Margin

The billable flag will also be used for tracking sales price.
The engine will also accommodate confirmation / approval, to sense check numbers before reporting.

The costing will allow group to specific unit cost application.
Costs for
* By Time Unit (1 hour, 30 mins, etc)
* By Project (Different rates per unit by project are possible)
* By Day (By day allows weekend and bank holiday rates to be applied)
* By Work Type (allows different rates by different activities)
* By Staff (allows the rates to be different by resource used)

=== Scheduling ===

The output of the scheduling engine will manifest that the hours in Time Tracker will be prefilled with a user having the ability to edit as their day progresses.

Actual scheduling will be done by a new module called Scheduler and the interaction of the output will be supported by Time Tracker.

=== Exception Costs and API ===

A log engine will be provide that exceptional costs for a project can be logged. The fields will be

* intExceptionCost_Id
* intExceptionCost_ProjectId
* strExceptionCost_Type
* intExceptionCost_FromCampaignId
* intExceptionCost_FromCDAId
* intExceptionCost_FromCCLId
* strExceptionCost_Title
* strExceptionCost_Details
* strExceptionCost_FileLink
* strExceptionCost_FutureCost_YesNo
* fltExceptionCost_Cost_AmountExVAT
* fltExceptionCost_Cost_AmountIncVAT
* strExceptionCost_Cost_VATCode
* fltExceptionCost_Billable_AmountExVAT
* fltExceptionCost_Billable_AmountIncVAT
* strExceptionCost_Billable_VATCode
* dteExceptionCost_DateTime
* intExceptionCost_LoggedBy
* strExceptionCost_Approved_YesNo
* dteExceptionCost_Approved_DateTime
* intExceptionCost_Approved_LoggedBy
* strExceptionCost_Paid_YesNo
* dteExceptionCost_Paid_DateTime
* intExceptionCost_Paid_LoggedBy
* strExceptionCost_Paid_Reference
* strExceptionCost_Billed_YesNo
* dteExceptionCost_Billed_DateTime
* intExceptionCost_Billed_LoggedBy
* strExceptionCost_Billed_Reference

Exception costs allow a form to log a survey complete, or a mystery shop complete directly to a project.
This logging means one of purchases or logs can be directly associated with a project for billing purposes.

This engine will also include an API to allow add, edit, delete and list capabilities. This will be delivered through AJAX.

=== Project Costs report ===

The project costs report will have 4 sections and delivered by time period

There will be options on the two preceding options selection pages.
* Page 1: Time period and project
* Page 2: Section selection and include costing reporting information

The report itself will be in 6 sections
* Section 1: Project overview
* Section 2: Tasks by period
* Section 3: Time Tracker report
* Section 4: Expenses report (mileage and subsistence report)
* Section 5: PO report (for large preapproved purchases)
* Section 6: Exception costs report

The report will have security to those with project access only.
The report generation will be logged in the System Audit log for security reasons.

=== Project profile ===

This report is a text and listing based report to output the contents of a task and details for the project and provide summative amounts rather than detailed breakdowns.

This report will begin as an onscreen and with client feedback be transition into an RTF / PDF output format. Client feedback required after initial build.

=== Project Management console ===

Given the extensive module options and selection choices a project console will be developed to put all the project management tools in a single interface for easy user management of the options and navigating the modules.

=== User by project profile ===

This will facilitate a by user profile report which allows expenses and owed charges by project to be reported on by user.

== System Access Management ==

=== User tabs ===

Given the length of the user setup screens a more effective interface screen is being designed.

Borrowing from the tabs capability of forms the interface will look follow this format.

[[File:bxpR10SER1_014.png]]

The tab bar will contain the sections currently available but only show the fields when that tab is clicked

The Module title and counts bar will use module icons (with name and count of ticks on hover over)
Then upon clicking the module, the sections for the module appear for selection.

The module access tick box (overall access to the module) will be removed in favour of intelligent access if you have access to 1 or more sections in the module.

=== UAM “function” support engine ===

Since the launch of UAM it’s speed, accuracy and popularity amongst clients and security specialists has shown that a UAM approach is far more effective for administrators to manage a business.
https://www.bxpsoftware.com/wixi/index.php/UAM_-_User_Access_Management

A system setting flagging “Using UAM” will be added to system settings.

When turned on in a system, add and edit a user will only provide a list of UAM buttons. The buttons will self-generate based on accounts flagged as templates.

UAM template users will have flags available allowing them to be easily managed, using the new enhanced layout above.

Any modifications of the UAM accounts will be logged in the audit trails.

The user management console will be moved to prominently appear in the user administration section of SAM.

Each user account if based on a UAM will now have a flag listing on which UAM template user account it is based. This will help reporting and group user updates.

=== UAM and SAM wixis ===

After all these changes a significant amount of wixi material will need to be updated to reflect the new user interfaces.

This documentation will see a gap between go live and testing where documentation may exist on the wixi before the functionality is in place.

=== Password blacklist engine ===

This facility will allow clients and the bxp administration team to apply a list of weak known hack attempted passwords which may validate as strong. These password combinations are designed to reduce risk of security break-ins even if the password strength is flagged as strong.

A global list will be maintained by All n One, with clients able to control their own lists from inside System Settings.

=== Client table alterations ===

The client table will have a number of fields added to support numerous new functions

* strClient_SalesForceId to allow mapping to SalesForce data
* strClient_UAMTitle to allow reporting and grouping of UAM permissions
* strClient_IsUAM to flag account is a UAM template
* strClient_LimitTimeTrackerCosting to influence Time Tracker option display on day view.
* strClient_Retired_LastDateTime to make retired reporting easier
* strClient_Retired_LastByWhom to make retired reporting easier

=== Security - Retired date time ===

Whilst this information is available through the audit logs it is not easily reported upon.

* When was a user retired?
* Who retired the user?

There will be the addition of two summary data fields to the Client table
* strClient_Retired_LastDateTime
* strClient_Retired_LastByWhom

The reason they have last is that the information will only be the last time an account was retired. So if it was retired multiple times, this field will only hold the last data. This also compensates for the fact that logs are only held for 6 months.

So if you go over the 6 months without manually backing up the logs the information is no longer auditable.

# So the fields will be added for future record changes only
# The columns of information will be made available in the retired functions search abilities
# A dedicated report in SAM will be provided to allow reporting on these fields.

The fields if a user is already retired will be initialised to.
* Last Date Time will be the date that the field is implemented
* By Whom will be associated with the Admin istrator account.

=== System Settings - Tabbed view ===

To reduce space on screen for very long screens with lots of settings, tabs, as used in KeyStats are being implemented system wide. The layout will change for the System Settings page with all the same sections and fields just tabbed.

A new filed for "Table Styling" discussed later will be made available on this screen.

=== System Keywords - Tabbed view ===

To reduce space on screen for very long screens with lots of settings, tabs, as used in KeyStats are being implemented system wide.

The layout will change for the System Keywords page with all the same sections and fields just tabbed.

There are no new fields on this page.

== Time Tracker ==

=== Confirmation Engine ===

A number of extensions are being added to the time tracker module.

One of these is, by project, if hours have to be confirmed by a manager. This allows a safety check before billable hours are applied to clients.

Mass confirmation ability will be part of this engine.

Confirmation can be applied on a project by project basis.

=== Limit project and work type by Costing ===

This engine will add intelligence by user, to only allow users to log data for projects they have access to AND where they have had pricing set up for them against the activity.

This allows greater control of project by work type by billing control for reporting purposes.

This setting will be centrally controlled in Project. There will be a flag by user to allow specific user only limitation.

= New Modules =

== Dashboards ==

The Dashboards module allows for prebuilt, predesigned panes of information to be collated into a single operational dashboard.

A user can have access to multiple dashboards.
[[Module_-_Dashboards]]

A number of predesigned dashboards will be launched with the module.

== Expenses Management ==

The Expenses module in bxp jargon is the logging of costs incurred as part of the delivery or a project. An expense is logged to an individual and requires that individual to be reimbursed by the business.

Expenses are associated with a project.

Expense items include entries such as mileage, subsistence and operational day to day costs of smaller one off purchases for the business.

Expenses will also support an administrator approval engine

[[Module_-_Expenses_Management]]

== PO Module ==

The Purchase Order (PO) Management module allows for the management of Purchase Order requests, approvals and tracking. Where significant purchases are to be made by a business a purchase order management approach allows for sense checking of purchases by management.

[[Module_-_Purchase_Order]]

== Scheduler ==

The scheduler module will deliver in conjunction with Time Tacker and Appointment Manager the ability to plan staff hours and allocate them in advance.

The module is in concept stage and is being worked through with a client to deliver specific requirements.

The primary challenge in the development of this module is the development and application of the resource allocation algorithms
* http://www.eventhelix.com/RealtimeMantra/Patterns/ResourceAllocationPatterns.htm
* https://en.wikipedia.org/wiki/Banker%27s_algorithm
* https://en.wikipedia.org/wiki/Resource_allocation

As bxp moves towards being able to offer ERP solutions, the schedule features as a key stepping stone in this development
https://en.wikipedia.org/wiki/Enterprise_resource_planning

= Engine =

== KeyStats plan ==

In order to better manage the potential slow down issues with incorrectly built KeyStats, the render page of the keystat is going to be given it’s own server W3 to process it. If W3 becomes unavailable a fall back to W1 and W2 will be implemented.

This action is considered a priority and is being worked on with Sungard at this time.

== Scheduled reports plan ==

Scheduled reporting will be moved to W3 and Db2 to reduce operational load on W1, W2 and Db1

== Big reports plan ==

Where are a report is identified as working on a very large data set, e.g. > 10,000 CDA records, the report will be generated on W3 and Db2 in a scheduled fashion. When the report has generated it will be available in the Report Library module for collection. An email notification will also be sent to the user that the report is ready to collect.

== Analytics ==

R is a free statistical computing tool available from
https://www.r-project.org/

bxp will generate data in a format compatible with R to facilitate the implementation of a number of data mining algorithms.

Algorithms currently considered
* kMeans Clustering algorithm
* k Nearest Neighbour algorithm
* Apriori algorithm
* CART 4.5 algorithm

== Custom folder via sftp ==

Access to the custom folder via the current web interface requires a “one by one” file approach. Where a client needs numerous file management access, sftp access will be provided to the file storage engine of bxp. This will in turn be managed on a scheduled or click request basis to kick off an audited and antivirus scanned transfer of the file storage to the live web infrastructure.

This should provide easier access for system administrators to mass manage their custom folder.

[[The_Custom_folder_through_sFTP_management]]

== API Tester Engine ==

Currently testing the API engine requires an external solution to poll the bxp servers. To make testing the interface more controlled and generate consistent repeatable results, an API testing interface will be developed.

This interface will be developed using PHP and live on the www.bxpsoftware.com public webserver. The interface will be available to all to use and provide sample code.

== API Hamster Report (Moss and others) ==

To make API support easier hamsters generated by the API engine will be interrogate-able and searchable. This interface will initially only be available to internal All n One staff with the interface on refinement being rolled out the System Access Management module.

A new section for API support will be provided in the System Access Management module.

== Table styling ==

We’ve been asked more than once to allow tables to “pop” or look more stylish.

bxp can adopt a look from other known office tools and using a well-known package to suggest some HTML interpretations.

[[File:bxpR10SER1_015.png | 800px]]

In order to implement these styles the tables will have to have new CSS tags applied.

* css_Table_New_Table
* css_Table_First_Cell
* css_Table_First_Row
* css_Table_Data_FirstCell
* css_Table_Data_DataCell
* css_Table_Data_LastCell
* css_Table_Data_Alt_FirstCell
* css_Table_Data_Alt_DataCell
* css_Table_Data_Alt_LastCell
* css_Table_Last_FirstCell
* css_Table_Last_Row
* css_Table_Last_LastCell

These tags are then set with appropriate styles and makes styling really easy to apply.

This change will affect where clients might have customisations or expect data to appear in particular layouts.

A default style matching current styles will be created BUT the HTML will have the new css Headers added.

Application of styling will vary throughout the system. i.e. there will be a master default but only some reports will allow “selective” styling.

== System Wipe function ==

This tool will purge all data and accounts from the ww5 or live environments as required. The tool will require a special code only supplied by All n One staff to allow a client enact the removal of all their data.

This tool also will help to reset testing environments where experimentation or training is required.

== System notification emails ==

A number of email and reports from bxp come from a variety of email addresses currently. These are to be unified under the bxpsoftware.com domain.

* security@bxpsoftware.com
* hamsters@bxpsoftware.com
* notification@bxpsoftware.com
* alerts@bxpsoftware.com
* compliance@bxpsoftware.com

== Client daily picture engine ==

This small change will allow clients to have their own 365 daily images run from the clients custom folder.

Currently using the keyword dailyPic in the background image of a user or a system will use the daily pic engine as their background.

By changing the word to customDailyPic, the engine will use the path https://ww3.allnone.ie/client/client_x/custom/dailypic/YYY.png folder. X is the name of the system currently being used and YYY is the 3 digit code for the day of the year, ie. 001 is 1st January of that year.

For more information [[The_dailyPic_engine]]

== Login page - Username autocomplete ==

As part of security the password field has a feature which removes the auto-complete of the password. This is a reasonable security measure.

In order to further improve security the username field will now also have autocomplete removed. The reason being that if a machine is used in a public environment, the username is left in the box providing a valid account which could be attacked to force unwanted lock outs. This change means a user will need to type their name in regularly.

== AJAX engine - Title when no records ==

Currently the text displays

[[File:bxpR10_AJAXTitle.png]]

This will be changed to "No records found."

== Key Stats engine - Web Server 3 Implementation ==

Currently the KeyStats engine for generating reports executes on Web servers 1 and 2 using Database server 1 as its data repository. This will be updated to execute on web sever 3 and use database server 2 as its data repository.

Syntax highlighting for both SQL and HTML will be added.

[[Category:Topic:About bxp]]
[[Category:Topic:Security]]

MetaData - Processing Rules - CCL Specific

2017-07-19T08:36:01Z

Patrick Jenkins: /* Insert Into CCL Simple */

MetaData - Processing Rules - Date and Time Management

2017-07-19T08:29:01Z

Patrick Jenkins: /* ZULU */

= Overview =

For more information on

{| class="wikitable"
! Area
! Link
|-
| MetaData please refer here || [[MetaData_-_Start_Here]]
|-
| Processing rules please refer here || [[MetaData_Process_Rules]]
|-
| Parameter construction please refer here || [[MetaData_Program_and_Outcomes]]
|-
|}

= Reference =

This wixi article is meant to serve as a reference guide to a subset of MetaData Processing Rules.

= Rules =

== Date ==

The date rule allows for a field in the database to be formatted into universal date format i.e. YYY-MM-DD

Required fields to execute rule:
# Rule Name
# Form id (the same as the current sequence)
# Field to store the end result
# Form id (the same as the current sequence)
# Filed containing the date to format

Example:
<syntaxhighlight lang="xml">
Rule Name[[-SEP-]]Form Id[[-SEP-]]Destination field[[-SEP-]]Form Id[[-SEP-]] Date to format[[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]]
</syntaxhighlight>

Example (with replacement values):
<syntaxhighlight lang="xml">
Date[[-SEP-]]1[[-SEP-]]strCDA_1_field_0_1[[-SEP-]]1[[-SEP-]]strCDA_1_field_0_2[[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]]
</syntaxhighlight>

== Date|Time ==

The date|time rule allows for a field in the database to be formatted into universal date time format i.e. YYY-MM-DD HH:MM:SS

Required fields to execute rule:
# Rule Name
# Form id (the same as the current sequence)
# Field to store the end result
# Form id (the same as the current sequence)
# Filed containing the date to format

Example:
<syntaxhighlight lang="xml">
Rule Name[[-SEP-]]Form Id[[-SEP-]]Destination field[[-SEP-]]Form Id[[-SEP-]] Date to format[[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]]
</syntaxhighlight>

Example (with replacement values):
<syntaxhighlight lang="xml">
DateTime [[-SEP-]]1[[-SEP-]]strCDA_1_field_0_1[[-SEP-]]1[[-SEP-]]strCDA_1_field_0_2[[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]]
</syntaxhighlight>

== Date|Time Now ==

The date|time now rule allows for a field in the database to be updated with the current date and time in universal date time format i.e. YYY-MM-DD HH:MM:SS

Required fields to execute rule:
# Rule Name
# Form id (the same as the current sequence)
# Field to store the end result

Example:
<syntaxhighlight lang="xml">
Rule Name[[-SEP-]]Form Id[[-SEP-]]Destination field[[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]]
</syntaxhighlight>

Example (with replacement values):
<syntaxhighlight lang="xml">
DateTimeNow [[-SEP-]]1[[-SEP-]]strCDA_1_field_0_1[[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]]
</syntaxhighlight>

== Report Time To Seconds ==

The report time to seconds rule converts a field in the database that contains a report time to a seconds value.

Required fields to execute rule:
# Rule Name
# Form id (the same as the current sequence)
# Field to store the end result
# Field containing the value to convert

Example:
<syntaxhighlight lang="xml">
Rule Name[[-SEP-]]Form Id[[-SEP-]]Destination field[[-SEP-]]Field containing the value to convert[[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]]
</syntaxhighlight>

Example (with replacement values):
<syntaxhighlight lang="xml">
ReportTimeToSeconds[[-SEP-]]1[[-SEP-]]strCDA_1_field_0_1[[-SEP-]] strCDA_1_field_0_2[[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]]
</syntaxhighlight>

== Seconds To Report Time ==

The seconds to report time rule converts a field in the database that contains seconds to a report time.

Required fields to execute rule:
# Rule Name
# Form id (the same as the current sequence)
# Field to store the end result
# Field containing the value to convert

Example:
<syntaxhighlight lang="xml">
Rule Name[[-SEP-]]Form Id[[-SEP-]]Destination field[[-SEP-]]Field containing the value to convert[[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]]
</syntaxhighlight>

Example (with replacement values):
<syntaxhighlight lang="xml">
SecondsToReportTime[[-SEP-]]1[[-SEP-]]strCDA_1_field_0_1[[-SEP-]] strCDA_1_field_0_2[[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]]
</syntaxhighlight>

== Time ==

The time rule allows for a field in the database to be formatted into universal time format i.e. HH:MM:SS

Required fields to execute rule:
# Rule Name
# Form id (the same as the current sequence)
# Field to store the end result
# Form id (the same as the current sequence)
# Filed containing the date to format

Example:
<syntaxhighlight lang="xml">
Rule Name[[-SEP-]]Form Id[[-SEP-]]Destination field[[-SEP-]]Form Id[[-SEP-]] Date to format[[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]]
</syntaxhighlight>

Example (with replacement values):
<syntaxhighlight lang="xml">
Time[[-SEP-]]1[[-SEP-]]strCDA_1_field_0_1[[-SEP-]]1[[-SEP-]]strCDA_1_field_0_2[[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]]
</syntaxhighlight>

== Time To Seconds ==

The time to seconds rule allows for a field in the database to be converted from a time in the form HH:MM:SS to seconds

Required fields to execute rule:
# Rule Name
# Form id (the same as the current sequence)
# Field to store the end result
# Form id (the same as the current sequence)
# Filed containing the date to format

Example:
<syntaxhighlight lang="xml">
Rule Name[[-SEP-]]Form Id[[-SEP-]]Destination field[[-SEP-]]Form Id[[-SEP-]] Date to format[[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]]
</syntaxhighlight>

Example (with replacement values):
<syntaxhighlight lang="xml">
TimeToSeconds [[-SEP-]]1[[-SEP-]]strCDA_1_field_0_1[[-SEP-]]1[[-SEP-]]strCDA_1_field_0_2[[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]]
</syntaxhighlight>

== ZULU ==

The ZULU rule allows for a field in the database to be formatted into ZULU Date TIme format i.e. ZYYYY-MM-DDTHH:MM:SS

Required fields to execute rule:
# Rule Name
# Form id (the same as the current sequence)
# Field to store the end result
# Form id (the same as the current sequence)
# Filed containing the date to format

Example:
<syntaxhighlight lang="xml">
Rule Name[[-SEP-]]Form Id[[-SEP-]]Destination field[[-SEP-]]Form Id[[-SEP-]] Date to format[[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]]
</syntaxhighlight>

Example (with replacement values):
<syntaxhighlight lang="xml">
Zulu[[-SEP-]]1[[-SEP-]]strCDA_1_field_0_1[[-SEP-]]1[[-SEP-]]strCDA_1_field_0_2[[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]]
</syntaxhighlight>

== Day Between ==

The Days Between rule calculates the difference between a passed in date and now, it will return the number of days.

Required fields to execute rule:
# Rule Name
# Form id (the same as the current sequence)
# Field to store the end result
# Form id (the same as the current sequence)
# Filed containing the date check

Example:
<syntaxhighlight lang="xml">
Rule Name[[-SEP-]]Form Id[[-SEP-]]Destination field[[-SEP-]]Form Id[[-SEP-]] Date to check[[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]]
</syntaxhighlight>

Example (with replacement values):
<syntaxhighlight lang="xml">
DaysBetweenGivenAndNow [[-SEP-]]1[[-SEP-]]strCDA_1_field_0_1[[-SEP-]]1[[-SEP-]]strCDA_1_field_0_2[[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]]
</syntaxhighlight>

== Month To number ==

The month to number rule converts the text name of a month to the its numeric value.

Required fields to execute rule:
# Rule Name
# Form id (the same as the current sequence)
# Field to store the end result
# Form id (the same as the current sequence)
# Filed containing the month to convert

Example:
<syntaxhighlight lang="xml">
Rule Name[[-SEP-]]Form Id[[-SEP-]]Destination field[[-SEP-]]Form Id[[-SEP-]] Month to conver[[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]]
</syntaxhighlight>

Example (with replacement values):
<syntaxhighlight lang="xml">
ConvertMonthTostrNumber[[-SEP-]]1[[-SEP-]]strCDA_1_field_0_1[[-SEP-]]1[[-SEP-]]strCDA_1_field_0_2[[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]]
</syntaxhighlight>

[[Category:Topic:MetaData]]
[[Category:Module Specific:MetaData]]

MetaData - Processing Rules - Date and Time Management

2017-07-19T08:28:40Z

Patrick Jenkins: /* Time */

= Overview =

For more information on

{| class="wikitable"
! Area
! Link
|-
| MetaData please refer here || [[MetaData_-_Start_Here]]
|-
| Processing rules please refer here || [[MetaData_Process_Rules]]
|-
| Parameter construction please refer here || [[MetaData_Program_and_Outcomes]]
|-
|}

= Reference =

This wixi article is meant to serve as a reference guide to a subset of MetaData Processing Rules.

= Rules =

== Date ==

The date rule allows for a field in the database to be formatted into universal date format i.e. YYY-MM-DD

Required fields to execute rule:
# Rule Name
# Form id (the same as the current sequence)
# Field to store the end result
# Form id (the same as the current sequence)
# Filed containing the date to format

Example:
<syntaxhighlight lang="xml">
Rule Name[[-SEP-]]Form Id[[-SEP-]]Destination field[[-SEP-]]Form Id[[-SEP-]] Date to format[[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]]
</syntaxhighlight>

Example (with replacement values):
<syntaxhighlight lang="xml">
Date[[-SEP-]]1[[-SEP-]]strCDA_1_field_0_1[[-SEP-]]1[[-SEP-]]strCDA_1_field_0_2[[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]]
</syntaxhighlight>

== Date|Time ==

The date|time rule allows for a field in the database to be formatted into universal date time format i.e. YYY-MM-DD HH:MM:SS

Required fields to execute rule:
# Rule Name
# Form id (the same as the current sequence)
# Field to store the end result
# Form id (the same as the current sequence)
# Filed containing the date to format

Example:
<syntaxhighlight lang="xml">
Rule Name[[-SEP-]]Form Id[[-SEP-]]Destination field[[-SEP-]]Form Id[[-SEP-]] Date to format[[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]]
</syntaxhighlight>

Example (with replacement values):
<syntaxhighlight lang="xml">
DateTime [[-SEP-]]1[[-SEP-]]strCDA_1_field_0_1[[-SEP-]]1[[-SEP-]]strCDA_1_field_0_2[[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]]
</syntaxhighlight>

== Date|Time Now ==

The date|time now rule allows for a field in the database to be updated with the current date and time in universal date time format i.e. YYY-MM-DD HH:MM:SS

Required fields to execute rule:
# Rule Name
# Form id (the same as the current sequence)
# Field to store the end result

Example:
<syntaxhighlight lang="xml">
Rule Name[[-SEP-]]Form Id[[-SEP-]]Destination field[[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]]
</syntaxhighlight>

Example (with replacement values):
<syntaxhighlight lang="xml">
DateTimeNow [[-SEP-]]1[[-SEP-]]strCDA_1_field_0_1[[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]]
</syntaxhighlight>

== Report Time To Seconds ==

The report time to seconds rule converts a field in the database that contains a report time to a seconds value.

Required fields to execute rule:
# Rule Name
# Form id (the same as the current sequence)
# Field to store the end result
# Field containing the value to convert

Example:
<syntaxhighlight lang="xml">
Rule Name[[-SEP-]]Form Id[[-SEP-]]Destination field[[-SEP-]]Field containing the value to convert[[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]]
</syntaxhighlight>

Example (with replacement values):
<syntaxhighlight lang="xml">
ReportTimeToSeconds[[-SEP-]]1[[-SEP-]]strCDA_1_field_0_1[[-SEP-]] strCDA_1_field_0_2[[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]]
</syntaxhighlight>

== Seconds To Report Time ==

The seconds to report time rule converts a field in the database that contains seconds to a report time.

Required fields to execute rule:
# Rule Name
# Form id (the same as the current sequence)
# Field to store the end result
# Field containing the value to convert

Example:
<syntaxhighlight lang="xml">
Rule Name[[-SEP-]]Form Id[[-SEP-]]Destination field[[-SEP-]]Field containing the value to convert[[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]]
</syntaxhighlight>

Example (with replacement values):
<syntaxhighlight lang="xml">
SecondsToReportTime[[-SEP-]]1[[-SEP-]]strCDA_1_field_0_1[[-SEP-]] strCDA_1_field_0_2[[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]]
</syntaxhighlight>

== Time ==

The time rule allows for a field in the database to be formatted into universal time format i.e. HH:MM:SS

Required fields to execute rule:
# Rule Name
# Form id (the same as the current sequence)
# Field to store the end result
# Form id (the same as the current sequence)
# Filed containing the date to format

Example:
<syntaxhighlight lang="xml">
Rule Name[[-SEP-]]Form Id[[-SEP-]]Destination field[[-SEP-]]Form Id[[-SEP-]] Date to format[[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]]
</syntaxhighlight>

Example (with replacement values):
<syntaxhighlight lang="xml">
Time[[-SEP-]]1[[-SEP-]]strCDA_1_field_0_1[[-SEP-]]1[[-SEP-]]strCDA_1_field_0_2[[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]]
</syntaxhighlight>

== Time To Seconds ==

The time to seconds rule allows for a field in the database to be converted from a time in the form HH:MM:SS to seconds

Required fields to execute rule:
# Rule Name
# Form id (the same as the current sequence)
# Field to store the end result
# Form id (the same as the current sequence)
# Filed containing the date to format

Example:
<syntaxhighlight lang="xml">
Rule Name[[-SEP-]]Form Id[[-SEP-]]Destination field[[-SEP-]]Form Id[[-SEP-]] Date to format[[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]]
</syntaxhighlight>

Example (with replacement values):
<syntaxhighlight lang="xml">
TimeToSeconds [[-SEP-]]1[[-SEP-]]strCDA_1_field_0_1[[-SEP-]]1[[-SEP-]]strCDA_1_field_0_2[[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]]
</syntaxhighlight>

== ZULU ==

The ZULU rule allows for a field in the database to be formatted into ZULU Date TIme format i.e. ZYYYY-MM-DDTHH:MM:SS

Required fields to execute rule:
# Rule Name
# Form id (the same as the current sequence)
# Field to store the end result
# Form id (the same as the current sequence)
# Filed containing the date to format

Example:
<syntaxhighlight lang="xml">
Rule Name[[-SEP-]]Form Id[[-SEP-]]Destination field[[-SEP-]]Form Id[[-SEP-]] Date to format[[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]]
</syntaxhighlight>

Example (with replacement values):
<syntaxhighlight lang="xml">
Date[[-SEP-]]1[[-SEP-]]strCDA_1_field_0_1[[-SEP-]]1[[-SEP-]]strCDA_1_field_0_2[[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]]
</syntaxhighlight>

== Day Between ==

The Days Between rule calculates the difference between a passed in date and now, it will return the number of days.

Required fields to execute rule:
# Rule Name
# Form id (the same as the current sequence)
# Field to store the end result
# Form id (the same as the current sequence)
# Filed containing the date check

Example:
<syntaxhighlight lang="xml">
Rule Name[[-SEP-]]Form Id[[-SEP-]]Destination field[[-SEP-]]Form Id[[-SEP-]] Date to check[[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]]
</syntaxhighlight>

Example (with replacement values):
<syntaxhighlight lang="xml">
DaysBetweenGivenAndNow [[-SEP-]]1[[-SEP-]]strCDA_1_field_0_1[[-SEP-]]1[[-SEP-]]strCDA_1_field_0_2[[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]]
</syntaxhighlight>

== Month To number ==

The month to number rule converts the text name of a month to the its numeric value.

Required fields to execute rule:
# Rule Name
# Form id (the same as the current sequence)
# Field to store the end result
# Form id (the same as the current sequence)
# Filed containing the month to convert

Example:
<syntaxhighlight lang="xml">
Rule Name[[-SEP-]]Form Id[[-SEP-]]Destination field[[-SEP-]]Form Id[[-SEP-]] Month to conver[[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]]
</syntaxhighlight>

Example (with replacement values):
<syntaxhighlight lang="xml">
ConvertMonthTostrNumber[[-SEP-]]1[[-SEP-]]strCDA_1_field_0_1[[-SEP-]]1[[-SEP-]]strCDA_1_field_0_2[[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]]
</syntaxhighlight>

[[Category:Topic:MetaData]]
[[Category:Module Specific:MetaData]]

Form - Data Protection - Scheduled

2017-06-06T06:52:59Z

Patrick Jenkins: /* Overview */

= Overview =

Using the scheduling engine of bxp, any user who has access to a form and has access to the form management module can create a scheduled data protection process.

''Main Menu > Form Management > Form - Primary Management > Form - Advanced Settings > Select the Form > Scheduled Data Protection''

This scheduled process takes a number of parameters.

* Enable the process
* Execution frequency (Yearly/Monthly/Weekly/Daily)
* Time of execution (15 minute intervals between 06:00:00 and 22:00:00)
* Fields to wipe (Fields separated by ,'s i.e. strCDA_X_field_0_1,strCDA_X_field_0_2,strCDA_X_field_0_5) - If you wish to delete, the records simply put 'bxp_Wipe_Record' in place of the field listing (make sure there is no trailing spaces)
* Time frame for data wipe (All/Delta)
* Password for encrypted file
* Send notification email
* Email notification list (Email addresses separated by ,'s i.e. patrick.jenkins@allnone.ie,philip.lacey@allnone.ie)

Provided that the details above have been entered correctly a scheduled instruction will be created for the following day with the time period selected.

When the scheduled instruction is executed, the following sequences will be executed on the desired database.

* Perform a complete data dump of the records in the form for the time period selected
* ZIP and encrypt the data file for collection by the bxp client
* Wipe the contents of the outlined fields
* provided that the email notification function is enabled, bxp will generate stats on the scheduled process and email these to the specified accounts.

To enable this function simply navigate to the advanced settings of the form you wish to enable this functionality for and open the section ''Scheduled Data Protection'', and enter in your desired settings. Please note in order to download the encrypted data file, you will need to contact the support team of bxp so an SFTP account can be created, so you can download the file.

[[File:ScheduledDataProtectionSettings.png|800px]]

The following is an example email notification that the system will generate when the process is activated.

[[File:ScheduledDataProtectionEmail.png]]

[[Category:Topic:Security]]
[[Category:Module Specific:Form Management]]

Meet the Team

2017-05-22T12:43:00Z

Patrick Jenkins: /* The Team */

The bxp software (bxp) team is made up of very skilled very experienced professionals ideally positioned to help and support your needs.

(in order of joining the company)

=The Team=
{|
|-
! style="text-align: left; width: 130px;"|Image
! style="text-align: left; width: 140px;"|LinkedIn
! style="text-align: left; width: 150px;"|Name
! style="text-align: left; width: 200px;"|Role
! style="text-align: left; width: 150px;"|Department
! style="text-align: left; width: 75px;"|Documentation Initials
! style="text-align: left; width: 75px;"|Related Articles
|-
||[[File:Signature_nickwheeler.png]]
||[https://ie.linkedin.com/pub/nick-wheeler/2/ba5/191 LinkedIn]
||Nick Wheeler
||Chief Executive Officer
||Sales
||NW
||
|-
||[[File:Signature_christhomson.png]]
||[https://ie.linkedin.com/in/christhomsondublin LinkedIn]
||Chris Thomson
||Chief Operating Officer
||Sales
||CT
||
|-
||[[File:Signature_philiplacey.png]]
||[https://ie.linkedin.com/pub/philip-lacey/11/654/2a1 LinkedIn]
||Philip Lacey
||Chief Technical Officer
||Projects
||PL
||
|-
||[[File:Signature_danielcoughlan.png]]
||[https://ie.linkedin.com/pub/daniel-coughlan/37/2b5/900 LinkedIn]
||Daniel Coughlan
||Senior Framework Developer
||Frameworks
||DC
||
|-
||[[File:Signature_patrickjenkins.png]]
||[https://ie.linkedin.com/pub/patrick-jenkins/53/226/ba8 LinkedIn]
||Patrick Jenkins
||Senior Projects Developer
||Projects
||PJ
||
|-
||[[File:Signature_meabhlanders.png]]
||[https://ie.linkedin.com/pub/meabh-landers/35/2b5/559 LinkedIn]
||Meabh Landers
||Content Developer
||Content
||ML
|-
||[[File:Signature_andrewforde.png]]
||[https://ie.linkedin.com/pub/andrew-forde/50/8a/725 LinkedIn]
||Andrew Forde
||Techincal Contact Centre Administrator
||Contact
||AF
||
|-
||[[File:Signature_thomasglennon.png]]
||[https://ie.linkedin.com/pub/thomas-glennon/91/3b2/505 LinkedIn]
||Thomas Glennon
||Security Administrator
||Security
||TG
||
|-
||[[File:Signature_robertcarson.png]]
||[https://ie.linkedin.com/pub/robert-carson/90/227/a66 LinkedIn]
||Robert Carson
||Jr. System Architect
||Sales
||RC
||
|-
||[[File:signature_paulkelly.png]]
||[https://ie.linkedin.com/in/paul-kelly-75312228 LinkedIn]
||Paul Kelly
||Junior Content Developer
||Content
||PK
||
|-
||[[File:Signature_JasonRyan.png]]
||[https://ie.linkedin.com/in/jasonryan59 LinkedIn]
||Jason Ryan
||Infrastructure Administrator
||Infrastructure
||JR
||
|-
||[[File:Signature_lidiagrisi2.png]]
||[https://ie.linkedin.com/in/lidia-grisi-3b247a10 LinkedIn]
||Lidia Grisi
||Morale Officer
||Back Office
||LG
||
|-
||[[File:Aiden_Rice.jpg]]
||[https://www.linkedin.com/in/aiden-rice-4bba9049 LinkedIn]
||Aiden Rice
||Business Development Manager
||Sales
||AR
||
|}

[[Category:Topic:About All n One]]
[[Category:Topic:About bxp]]

MetaData - Processing Rules - Cross Form

2017-02-20T09:30:17Z

Patrick Jenkins: /* Cross Form Update Smart */

= Overview =

For more information on

{| class="wikitable"
! Area
! Link
|-
| MetaData please refer here || [[MetaData_-_Start_Here]]
|-
| Processing rules please refer here || [[MetaData_Process_Rules]]
|-
| Parameter construction please refer here || [[MetaData_Program_and_Outcomes]]
|-
|}

= Reference =

This wixi article is meant to serve as a reference guide to a subset of MetaData Processing Rules.

= Rules =

== Copy To Destination ==

This function allows you to specify a source value and then to sequentially add that value to a subsequent or previous number of fields.

Required fields to execute rule:
# Rule Name
# Form id (the same as the current sequence)
# Field containing the data to copy
# Destination field
# Number of times to copy the data
# Gap between each insert

Example:
<syntaxhighlight lang="xml">
Rule Name[[-SEP-]]Form Id[[-SEP-]]Fields to copy[[-SEP-]]Destination fields[[-SEP]]number of times to copy the data[[-SEP-]]Gap between each copy[[-SEP-]] [[-SEP-]] [[-SEP-]] [[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]]
</syntaxhighlight>

Example (with replacement values):
<syntaxhighlight lang="xml">
Copy_To_Destination[[-SEP-]]1[[-SEP-]]strCDA_1_field_0_1,strCDA_1_field_0_2[[-SEP-]]strCDA_1_field_0_3,strCDA_1_field_0_4[[-SEP]]50[[-SEP-]]2[[-SEP-]] [[-SEP-]] [[-SEP-]] [[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]]
</syntaxhighlight>

== Cross Form Update ==

This function allows for the updating of records in one database with values stored in another

The Options field should be set to True if a CCL is required to be inserted as well in the destination campaign.

Required fields to execute rule:
# Rule Name
# Form id (the same as the current sequence)
# Destination field
# Form id (the same as the current sequence)
# Fields separated by comma’s
# Form id (the same as the current sequence)
# Fields to separate by comma’s

Example:
<syntaxhighlight lang="xml">
Rule Name[[-SEP-]] Form id [[-SEP-]]Destination field[[-SEP-]]Form id[[-SEP-]]Fields[[-SEP-]]Form id[[-SEP-]]Fields[[-SEP-]]Options[[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]]
</syntaxhighlight>

Example (with replacement values):
<syntaxhighlight lang="xml">
CrossDatabase_Update[[-SEP-]]1[[-SEP-]]strCDA_1_field_0_1[[-SEP-]]2[[-SEP-]] strCDA_2_field_0_1 [[-SEP-]]3[[-SEP-]]strCDA_3_field_0_1[[-SEP-]]True[[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]]
</syntaxhighlight>

== Cross Form Insert ==

This function allows for the creation of new records in a database using the values stored in another database. The system will auto generate the values for the system fields including the ID, Future Use, Status, Last Date Time, Last Agent Id, unless explicitly stated.

The Options field should be set to True if a CCL is required to be inserted as well in the destination campaign.

Required fields to execute rule:
# Rule Name
# Form id (the same as the current sequence)
# Destination field
# Form id (the same as the current sequence)
# Fields separated by comma’s
# Form id (the same as the current sequence)
# Fields to separate by comma’s

Example:
<syntaxhighlight lang="xml">
Rule Name[[-SEP-]]Form id[[-SEP-]]Destination field[[-SEP-]]Form id[[-SEP-]]Fields[[-SEP-]]Form id[[-SEP-]]Fields[[-SEP-]]Options[[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]]
</syntaxhighlight>

Example (with replacement values):
<syntaxhighlight lang="xml">
CrossDatabase_Insert[[-SEP-]]1[[-SEP-]]strCDA_1_field_0_1[[-SEP-]]2[[-SEP-]] strCDA_2_field_0_1 [[-SEP-]]3[[-SEP-]]strCDA_3_field_0_1[[-SEP-]]True[[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]]
</syntaxhighlight>

== Cross Form Update Simple/Custom ==

This function allows for the updating of records in one database with values stored in another, using a custom group by clause

Required fields to execute rule:
# Rule Name
# Table name (values to be updated in)
# Fields to update
# Files that contain the values to update
# Form Id to search on
# Update search field
# Form id containing search value
# Update search value

Example:
<syntaxhighlight lang="xml">
Rule Name[[-SEP-]] Table name [[-SEP-]]Fields to update[[-SEP-]]Form id[[-SEP-]]Fields[[-SEP-]]Form id[[-SEP-]]Fields[[-SEP-]]Options[[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]]
</syntaxhighlight>

Example (with replacement values):
<syntaxhighlight lang="xml">
CrossDatabase_Update_Custom[[-SEP-]]CDA_1[[-SEP-]]strCDA_1_field_0_7[[-SEP-]]strCDA_2_field_0_1[[-SEP-]]intCDA_2_Id[[-SEP-]]strCDA_1_field_0_7[[-SEP-]]CDA_2[[-SEP-]]strCDA_1_field_0_7[[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]]
</syntaxhighlight>

== Cross Form Update Smart ==

This function allows for the updating of records in one database with values stored in another, using a custom group by clause. If a matching record is not found in the destination database then the MetaData will not perform and update. It does however perform a brand new record insert

Required fields to execute rule:
# Rule to process
# Table to insert to
# Fields to insert values into
# Values to insert into the fields
# Table with the values
# Fields to search for records
# values to search for
# Boolean add CCL
# CCL Outcome
# CCL Comments
# Boolean update current status
# New Status
# Part Matching Enabled
# Alternate matching patterns fields
# Alternate matching patterns value

Example:
<syntaxhighlight lang="xml">
Rule Name[[-SEP-]]Table to insert to[[-SEP-]]Fields to insert values into[[-SEP-]]Values to insert into the fields[[-SEP-]]Table with the values[[-SEP-]]Fields to search for records[[-SEP-]]values to search for[[-SEP-]]Boolean add CCL[[-SEP-]]CCL Outcome[[-SEP-]]CCL Comments[[-SEP-]]Boolean update current status[[-SEP-]]New Status[[-SEP-]]Part Matching Enabled[[-SEP-]]Alternate matching patterns fields[[-SEP-]]Alternate matching patterns value[[-SEP-]][[-SEP-]]
</syntaxhighlight>

Example (with replacement values):
<syntaxhighlight lang="xml">
CrossDatabase_Update_Smart[[-SEP-]]11[[-SEP-]]strCDA_11_field_0_4,strCDA_11_field_0_7,strCDA_11_field_0_8,strCDA_11_field_0_9,strCDA_11_field_0_10[[-SEP-]]strCDA_12_field_0_4,strCDA_12_field_0_7,strCDA_12_field_0_8,strCDA_12_field_0_9,strCDA_12_field_0_10[[-SEP-]]12[[-SEP-]]strCDA_11_field_0_16{{--SEP--}}strCDA_11_field_0_17{{--SEP--}}strCDA_11_field_0_18{{--SEP--}}strCDA_11_field_0_4[[-SEP-]]--AccountFirstname--{{--SEP--}}--AccountSurname--{{--SEP--}}--AccountDOB--{{--SEP--}}--AccountIOB--[[-SEP-]]true[[-SEP-]]Real Time update from IOB [[-SEP-]]Real Time update process from DB Id:12[[-SEP-]]true[[-SEP-]]Real Time update from DB 11[[-SEP-]]true[[-SEP-]]strCDA_11_field_0_16{{--SEP--}}strCDA_11_field_0_17{{--SEP--}}strCDA_11_field_0_18{{##SEP##}}strCDA_11_field_0_16{{--SEP--}}strCDA_11_field_0_17{{--SEP--}}strCDA_11_field_0_4{{##SEP##}}strCDA_11_field_0_16{{--SEP--}}strCDA_11_field_0_18{{--SEP--}}strCDA_11_field_0_4{{##SEP##}}strCDA_11_field_0_17{{--SEP--}}strCDA_11_field_0_18{{--SEP--}}strCDA_11_field_0_4[[-SEP-]]--AccountFirstname--{{--SEP--}}--AccountSurname--{{--SEP--}}--AccountDOB--{{##SEP##}}--AccountFirstname--{{--SEP--}}--AccountSurname--{{--SEP--}}--AccountIOB--{{##SEP##}}--AccountFirstname--{{--SEP--}}--AccountDOB--{{--SEP--}}--AccountIOB--{{##SEP##}}--AccountSurname--{{--SEP--}}--AccountDOB--{{--SEP--}}--AccountIOB--[[-SEP-]][[-SEP-]][[-SEP-]]
</syntaxhighlight>

[[Category:Topic:MetaData]]
[[Category:Module Specific:MetaData]]

MetaData - Processing Rules - Cross Form

2017-02-20T09:29:42Z

Patrick Jenkins: /* Cross Form Update Smart */

= Overview =

For more information on

{| class="wikitable"
! Area
! Link
|-
| MetaData please refer here || [[MetaData_-_Start_Here]]
|-
| Processing rules please refer here || [[MetaData_Process_Rules]]
|-
| Parameter construction please refer here || [[MetaData_Program_and_Outcomes]]
|-
|}

= Reference =

This wixi article is meant to serve as a reference guide to a subset of MetaData Processing Rules.

= Rules =

== Copy To Destination ==

This function allows you to specify a source value and then to sequentially add that value to a subsequent or previous number of fields.

Required fields to execute rule:
# Rule Name
# Form id (the same as the current sequence)
# Field containing the data to copy
# Destination field
# Number of times to copy the data
# Gap between each insert

Example:
<syntaxhighlight lang="xml">
Rule Name[[-SEP-]]Form Id[[-SEP-]]Fields to copy[[-SEP-]]Destination fields[[-SEP]]number of times to copy the data[[-SEP-]]Gap between each copy[[-SEP-]] [[-SEP-]] [[-SEP-]] [[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]]
</syntaxhighlight>

Example (with replacement values):
<syntaxhighlight lang="xml">
Copy_To_Destination[[-SEP-]]1[[-SEP-]]strCDA_1_field_0_1,strCDA_1_field_0_2[[-SEP-]]strCDA_1_field_0_3,strCDA_1_field_0_4[[-SEP]]50[[-SEP-]]2[[-SEP-]] [[-SEP-]] [[-SEP-]] [[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]]
</syntaxhighlight>

== Cross Form Update ==

This function allows for the updating of records in one database with values stored in another

The Options field should be set to True if a CCL is required to be inserted as well in the destination campaign.

Required fields to execute rule:
# Rule Name
# Form id (the same as the current sequence)
# Destination field
# Form id (the same as the current sequence)
# Fields separated by comma’s
# Form id (the same as the current sequence)
# Fields to separate by comma’s

Example:
<syntaxhighlight lang="xml">
Rule Name[[-SEP-]] Form id [[-SEP-]]Destination field[[-SEP-]]Form id[[-SEP-]]Fields[[-SEP-]]Form id[[-SEP-]]Fields[[-SEP-]]Options[[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]]
</syntaxhighlight>

Example (with replacement values):
<syntaxhighlight lang="xml">
CrossDatabase_Update[[-SEP-]]1[[-SEP-]]strCDA_1_field_0_1[[-SEP-]]2[[-SEP-]] strCDA_2_field_0_1 [[-SEP-]]3[[-SEP-]]strCDA_3_field_0_1[[-SEP-]]True[[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]]
</syntaxhighlight>

== Cross Form Insert ==

This function allows for the creation of new records in a database using the values stored in another database. The system will auto generate the values for the system fields including the ID, Future Use, Status, Last Date Time, Last Agent Id, unless explicitly stated.

The Options field should be set to True if a CCL is required to be inserted as well in the destination campaign.

Required fields to execute rule:
# Rule Name
# Form id (the same as the current sequence)
# Destination field
# Form id (the same as the current sequence)
# Fields separated by comma’s
# Form id (the same as the current sequence)
# Fields to separate by comma’s

Example:
<syntaxhighlight lang="xml">
Rule Name[[-SEP-]]Form id[[-SEP-]]Destination field[[-SEP-]]Form id[[-SEP-]]Fields[[-SEP-]]Form id[[-SEP-]]Fields[[-SEP-]]Options[[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]]
</syntaxhighlight>

Example (with replacement values):
<syntaxhighlight lang="xml">
CrossDatabase_Insert[[-SEP-]]1[[-SEP-]]strCDA_1_field_0_1[[-SEP-]]2[[-SEP-]] strCDA_2_field_0_1 [[-SEP-]]3[[-SEP-]]strCDA_3_field_0_1[[-SEP-]]True[[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]]
</syntaxhighlight>

== Cross Form Update Simple/Custom ==

This function allows for the updating of records in one database with values stored in another, using a custom group by clause

Required fields to execute rule:
# Rule Name
# Table name (values to be updated in)
# Fields to update
# Files that contain the values to update
# Form Id to search on
# Update search field
# Form id containing search value
# Update search value

Example:
<syntaxhighlight lang="xml">
Rule Name[[-SEP-]] Table name [[-SEP-]]Fields to update[[-SEP-]]Form id[[-SEP-]]Fields[[-SEP-]]Form id[[-SEP-]]Fields[[-SEP-]]Options[[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]]
</syntaxhighlight>

Example (with replacement values):
<syntaxhighlight lang="xml">
CrossDatabase_Update_Custom[[-SEP-]]CDA_1[[-SEP-]]strCDA_1_field_0_7[[-SEP-]]strCDA_2_field_0_1[[-SEP-]]intCDA_2_Id[[-SEP-]]strCDA_1_field_0_7[[-SEP-]]CDA_2[[-SEP-]]strCDA_1_field_0_7[[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]]
</syntaxhighlight>

== Cross Form Update Smart ==

This function allows for the updating of records in one database with values stored in another, using a custom group by clause. If a matching record is not found in the destination database then the MetaData will not perform and update. It does however perform a brand new record insert

Required fields to execute rule:
# Rule to process
# Table to insert to
# Fields to insert values into
# Values to insert into the fields
# Table with the values
# Fields to search for records
# values to search for
# Boolean add CCL
# CCL Outcome
# CCL Comments
# Boolean update current status
# New Status
# Part Matching Enabled
# Alternate matching patterns fields
# Alternate matching patterns value

Example:
<syntaxhighlight lang="xml">
Rule Name[[-SEP-]]Table to insert to[[-SEP-]]Fields to insert values into[[-SEP-]]Values to insert into the fields[[-SEP-]]Table with the values[[-SEP-]]Fields to search for records[[-SEP-]]values to search for[[-SEP-]]Boolean add CCL[[-SEP-]]CCL Outcome[[-SEP-]]CCL Comments[[-SEP-]]Boolean update current status[[-SEP-]]New Status[[-SEP-]]Part Matching Enabled[[-SEP-]]Alternate matching patterns fields[[-SEP-]]Alternate matching patterns value[[-SEP-]][[-SEP-]]
</syntaxhighlight>

Example (with replacement values):
<syntaxhighlight lang="xml">
CrossDatabase_Update_Smart[[-SEP-]]11[[-SEP-]]strCDA_11_field_0_4,strCDA_11_field_0_7,strCDA_11_field_0_8,strCDA_11_field_0_9,strCDA_11_field_0_10[[-SEP-]]strCDA_12_field_0_4,strCDA_12_field_0_7,strCDA_12_field_0_8,strCDA_12_field_0_9,strCDA_12_field_0_10[[-SEP-]]12[[-SEP-]]strCDA_11_field_0_16{{--SEP--}}strCDA_11_field_0_17{{--SEP--}}strCDA_11_field_0_18{{--SEP--}}strCDA_11_field_0_4[[-SEP-]]--AccountFirstname--{{--SEP--}}--AccountSurname--{{--SEP--}}--AccountDOB--{{--SEP--}}--AccountIOB--[[-SEP-]]true[[-SEP-]]Real Time update from IOB [[-SEP-]]Real Time update process from DB Id:12[[-SEP-]]true[[-SEP-]]Real Time update from DB 11[[-SEP-]]true[[-SEP-]]strCDA_11_field_0_16{{--SEP--}}strCDA_11_field_0_17{{--SEP--}}strCDA_11_field_0_18{{##SEP##}}strCDA_11_field_0_16{{--SEP--}}strCDA_11_field_0_17{{--SEP--}}strCDA_11_field_0_4{{##SEP##}}strCDA_11_field_0_16{{--SEP--}}strCDA_11_field_0_18{{--SEP--}}strCDA_11_field_0_4{{##SEP##}}strCDA_11_field_0_17{{--SEP--}}strCDA_11_field_0_18{{--SEP--}}strCDA_11_field_0_4[[-SEP-]]--AccountFirstname--{{--SEP--}}--AccountSurname--{{--SEP--}}--AccountDOB--{{##SEP##}}--AccountFirstname--{{--SEP--}}--AccountSurname--{{--SEP--}}--AccountIOB--{{##SEP##}}--AccountFirstname--{{--SEP--}}--AccountDOB--{{--SEP--}}--AccountIOB--{{##SEP##}}--AccountSurname--{{--SEP--}}--AccountDOB--{{--SEP--}}--AccountIOB--[[-SEP-]][[-SEP-]][[-SEP-]]
</syntaxhighlight>

[[Category:Topic:MetaData]]
[[Category:Module Specific:MetaData]]

MetaData - Processing Rules - Cross Form

2017-02-20T09:25:14Z

Patrick Jenkins: /* Copy To Destination */

= Overview =

For more information on

{| class="wikitable"
! Area
! Link
|-
| MetaData please refer here || [[MetaData_-_Start_Here]]
|-
| Processing rules please refer here || [[MetaData_Process_Rules]]
|-
| Parameter construction please refer here || [[MetaData_Program_and_Outcomes]]
|-
|}

= Reference =

This wixi article is meant to serve as a reference guide to a subset of MetaData Processing Rules.

= Rules =

== Copy To Destination ==

This function allows you to specify a source value and then to sequentially add that value to a subsequent or previous number of fields.

Required fields to execute rule:
# Rule Name
# Form id (the same as the current sequence)
# Field containing the data to copy
# Destination field
# Number of times to copy the data
# Gap between each insert

Example:
<syntaxhighlight lang="xml">
Rule Name[[-SEP-]]Form Id[[-SEP-]]Fields to copy[[-SEP-]]Destination fields[[-SEP]]number of times to copy the data[[-SEP-]]Gap between each copy[[-SEP-]] [[-SEP-]] [[-SEP-]] [[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]]
</syntaxhighlight>

Example (with replacement values):
<syntaxhighlight lang="xml">
Copy_To_Destination[[-SEP-]]1[[-SEP-]]strCDA_1_field_0_1,strCDA_1_field_0_2[[-SEP-]]strCDA_1_field_0_3,strCDA_1_field_0_4[[-SEP]]50[[-SEP-]]2[[-SEP-]] [[-SEP-]] [[-SEP-]] [[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]]
</syntaxhighlight>

== Cross Form Update ==

This function allows for the updating of records in one database with values stored in another

The Options field should be set to True if a CCL is required to be inserted as well in the destination campaign.

Required fields to execute rule:
# Rule Name
# Form id (the same as the current sequence)
# Destination field
# Form id (the same as the current sequence)
# Fields separated by comma’s
# Form id (the same as the current sequence)
# Fields to separate by comma’s

Example:
<syntaxhighlight lang="xml">
Rule Name[[-SEP-]] Form id [[-SEP-]]Destination field[[-SEP-]]Form id[[-SEP-]]Fields[[-SEP-]]Form id[[-SEP-]]Fields[[-SEP-]]Options[[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]]
</syntaxhighlight>

Example (with replacement values):
<syntaxhighlight lang="xml">
CrossDatabase_Update[[-SEP-]]1[[-SEP-]]strCDA_1_field_0_1[[-SEP-]]2[[-SEP-]] strCDA_2_field_0_1 [[-SEP-]]3[[-SEP-]]strCDA_3_field_0_1[[-SEP-]]True[[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]]
</syntaxhighlight>

== Cross Form Insert ==

This function allows for the creation of new records in a database using the values stored in another database. The system will auto generate the values for the system fields including the ID, Future Use, Status, Last Date Time, Last Agent Id, unless explicitly stated.

The Options field should be set to True if a CCL is required to be inserted as well in the destination campaign.

Required fields to execute rule:
# Rule Name
# Form id (the same as the current sequence)
# Destination field
# Form id (the same as the current sequence)
# Fields separated by comma’s
# Form id (the same as the current sequence)
# Fields to separate by comma’s

Example:
<syntaxhighlight lang="xml">
Rule Name[[-SEP-]]Form id[[-SEP-]]Destination field[[-SEP-]]Form id[[-SEP-]]Fields[[-SEP-]]Form id[[-SEP-]]Fields[[-SEP-]]Options[[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]]
</syntaxhighlight>

Example (with replacement values):
<syntaxhighlight lang="xml">
CrossDatabase_Insert[[-SEP-]]1[[-SEP-]]strCDA_1_field_0_1[[-SEP-]]2[[-SEP-]] strCDA_2_field_0_1 [[-SEP-]]3[[-SEP-]]strCDA_3_field_0_1[[-SEP-]]True[[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]]
</syntaxhighlight>

== Cross Form Update Simple/Custom ==

This function allows for the updating of records in one database with values stored in another, using a custom group by clause

Required fields to execute rule:
# Rule Name
# Table name (values to be updated in)
# Fields to update
# Files that contain the values to update
# Form Id to search on
# Update search field
# Form id containing search value
# Update search value

Example:
<syntaxhighlight lang="xml">
Rule Name[[-SEP-]] Table name [[-SEP-]]Fields to update[[-SEP-]]Form id[[-SEP-]]Fields[[-SEP-]]Form id[[-SEP-]]Fields[[-SEP-]]Options[[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]]
</syntaxhighlight>

Example (with replacement values):
<syntaxhighlight lang="xml">
CrossDatabase_Update_Custom[[-SEP-]]CDA_1[[-SEP-]]strCDA_1_field_0_7[[-SEP-]]strCDA_2_field_0_1[[-SEP-]]intCDA_2_Id[[-SEP-]]strCDA_1_field_0_7[[-SEP-]]CDA_2[[-SEP-]]strCDA_1_field_0_7[[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]][[-SEP-]]
</syntaxhighlight>

== Cross Form Update Smart ==

This function allows for the updating of records in one database with values stored in another, using a custom group by clause. If a matching record is not found in the destination database then the MetaData will not perform and update. It does however perform a brand new record insert

Required fields to execute rule:
# Rule to process
# Table to insert to
# Fields to insert values into
# Values to insert into the fields
# Table with the values
# Fields to search for records
# values to search for
# Boolean add CCL
# CCL Outcome
# CCL Comments
# Boolean update current status
# New Status
# Part Matching Enabled
# Alternate matching patterns fields
# Alternate matching patterns value

Example:
<syntaxhighlight lang="xml">
CrossDatabase_Update_Smart[[-SEP-]]11[[-SEP-]]strCDA_11_field_0_4,strCDA_11_field_0_7,strCDA_11_field_0_8,strCDA_11_field_0_9,strCDA_11_field_0_10[[-SEP-]]strCDA_12_field_0_4,strCDA_12_field_0_7,strCDA_12_field_0_8,strCDA_12_field_0_9,strCDA_12_field_0_10[[-SEP-]]12[[-SEP-]]strCDA_11_field_0_16{{--SEP--}}strCDA_11_field_0_17{{--SEP--}}strCDA_11_field_0_18{{--SEP--}}strCDA_11_field_0_4[[-SEP-]]--AccountFirstname--{{--SEP--}}--AccountSurname--{{--SEP--}}--AccountDOB--{{--SEP--}}--AccountIOB--[[-SEP-]]true[[-SEP-]]Real Time update from IOB [[-SEP-]]Real Time update process from DB Id:12[[-SEP-]]true[[-SEP-]]Real Time update from DB 11[[-SEP-]]true[[-SEP-]]strCDA_11_field_0_16{{--SEP--}}strCDA_11_field_0_17{{--SEP--}}strCDA_11_field_0_18{{##SEP##}}strCDA_11_field_0_16{{--SEP--}}strCDA_11_field_0_17{{--SEP--}}strCDA_11_field_0_4{{##SEP##}}strCDA_11_field_0_16{{--SEP--}}strCDA_11_field_0_18{{--SEP--}}strCDA_11_field_0_4{{##SEP##}}strCDA_11_field_0_17{{--SEP--}}strCDA_11_field_0_18{{--SEP--}}strCDA_11_field_0_4[[-SEP-]]--AccountFirstname--{{--SEP--}}--AccountSurname--{{--SEP--}}--AccountDOB--{{##SEP##}}--AccountFirstname--{{--SEP--}}--AccountSurname--{{--SEP--}}--AccountIOB--{{##SEP##}}--AccountFirstname--{{--SEP--}}--AccountDOB--{{--SEP--}}--AccountIOB--{{##SEP##}}--AccountSurname--{{--SEP--}}--AccountDOB--{{--SEP--}}--AccountIOB--[[-SEP-]][[-SEP-]][[-SEP-]]
</syntaxhighlight>

[[Category:Topic:MetaData]]
[[Category:Module Specific:MetaData]]

MetaData - Processing Rules - Data Conversion

2017-02-20T09:22:24Z

Patrick Jenkins: /* Convert Data field */

Security - Password Strength Report

2017-02-02T09:25:18Z

Patrick Jenkins:

With bxp software (bxp) in the System Access Management module [[File:016.png]] there are a number of security reports within the Security Reports section.

''Main Menu > System Access Management > Security Reports > Security - Password Strength''

One of these reports is the Password Strength Report. This report allows for a review of the strength of users passwords.

[[File:SecurityReports-PasswordStrength_001.png|800px]]

Password strength is determined according to Google's Password rating system API. http://www.codeproject.com/Articles/19245/Google-Password-Strength-API

1 = Weak, 2 = Medium, 3 = Strong, 4 = Best

The report allows you to group the types before display. Using All allows you to see all non-retired users in a single report.

[[File:SecurityReports-PasswordStrength_002.png|800px]]

= Update =

As of 2016-06-28, the Google API wasn't available which caused the bxp reporting to not display correctly.

To prevent this occurence and also remove dependence on an external service we've implemented a security engine, that caters for four password minimum levels Weak, Medium, Strong and Best. Please find below the minimum password requirments for each level:

== Weak Password Minimum Requirements ==

1) New password and confirm new password must match

2) Length needs to be 8

3) Not contain Spaces

[[File:bxp_weak_password.png|800px]]

== Medium Password Minimum Requirements ==

1) New password and confirm new password must match

2) Length needs to be 8

3) Not contain Spaces

4) Must contain at lease one symbol

[[File:bxp_medium_password.png|800px]]

== Strong Password Minimum Requirements ==

1) New password and confirm new password must match

2) Length needs to be 8

3) Not contain Spaces

4) Must contain at lease one symbol

5) Must contain at least one number

6) Must contain at least one Uppercase letter

[[File:bxp_strong_password.png|800px]]

== Best Password Minimum Requirements ==

1) New password and confirm new password must match

2) Length needs to be 8

3) Not contain Spaces

4) Must contain at lease one symbol

5) Must contain at least one number

6) Must contain at least one Uppercase letter

7) Not contain the the same character 3 times in a row

8) Must not contain both the first name of the user or the surname of the use

[[File:bxp_best_password.png|800px]]

Whilst far from perfect it does provide a reasonable approximation of the results.

[[Category:Topic:Security]]

File:bxp best password.png

2017-02-02T09:23:46Z

Patrick Jenkins:

File:bxp strong password.png

2017-02-02T09:18:45Z

Patrick Jenkins:

Security - Password Strength Report

2017-02-02T09:16:39Z

Patrick Jenkins:

With bxp software (bxp) in the System Access Management module [[File:016.png]] there are a number of security reports within the Security Reports section.

''Main Menu > System Access Management > Security Reports > Security - Password Strength''

One of these reports is the Password Strength Report. This report allows for a review of the strength of users passwords.

[[File:SecurityReports-PasswordStrength_001.png|800px]]

Password strength is determined according to Google's Password rating system API. http://www.codeproject.com/Articles/19245/Google-Password-Strength-API

1 = Weak, 2 = Medium, 3 = Strong, 4 = Best

The report allows you to group the types before display. Using All allows you to see all non-retired users in a single report.

[[File:SecurityReports-PasswordStrength_002.png|800px]]

= Update =

As of 2016-06-28, the Google API wasn't available which caused the bxp reporting to not display correctly.

To prevent this occurence and also remove dependence on an external service we've implemented a security engine, that caters for four password minimum levels Weak, Medium, Strong and Best. Please find below the minimum password requirments for each level:

== Weak Password Minimum Requirements ==

1) New password and confirm new password must match

2) Length needs to be 8

[[File:bxp_weak_password.png|800px]]

== Medium Password Minimum Requirements ==

1) New password and confirm new password must match

2) Length needs to be 8

3) Not contain Spaces

4) Must contain at lease one symbol

[[File:bxp_medium_password.png|800px]]

== Strong Password Minimum Requirements ==

1) New password and confirm new password must match

2) Length needs to be 8

3) Not contain Spaces

4) Must contain at lease one symbol

5) Must contain at least one number

6) Must contain at least one Uppercase letter

[[File:bxp_strong_password.png|800px]]

== Best Password Minimum Requirements ==

1) New password and confirm new password must match

2) Length needs to be 8

3) Not contain Spaces

4) Must contain at lease one symbol

5) Must contain at least one number

6) Must contain at least one Uppercase letter

7) Not contain the the same character 3 times in a row

8) Must not contain both the first name of the user or the surname of the use

[[File:bxp_best_password.png|800px]]

Whilst far from perfect it does provide a reasonable approximation of the results.

[[Category:Topic:Security]]

File:bxp medium password.png

2017-02-02T09:07:51Z

Patrick Jenkins:

File:bxp weak password.png

2017-02-02T08:52:47Z

Patrick Jenkins:

Bar Code Engine

2016-11-21T09:59:48Z

Patrick Jenkins: Created page with " == Overview == bxp has the ability to generate custom bar codes, when saving a record in a form or through the API. These bar codes can have completely custom encoded conte..."

== Overview ==

bxp has the ability to generate custom bar codes, when saving a record in a form or through the API. These bar codes can have completely custom encoded content. To add a bar-code to a bx template simply create you template that you wish to generate when saving a record and note the following settings:

{| class="wikitable"
|-
! Setting
! Description
|-
| Enable PDF Bar Code
| This option when set to True, tells bxp to enable the bar ode engine for this template
|-
| Bar Code Type
| This lets bxp know the type to generate - PDF417
|-
| Bar Code Location
| Location to generate on the document - Top/Bottom - Left/Center/Right
|-
| Bar Code Size
| Size of the bar code to generate - Small/Medium/Large/Ex-Large
|-
| Bar Code Aspect Ratio
| Set the aspect ration of the bar code: 1 - 10
|-
| Outcome Mail Merge Save To CCL
| If this is set to true bxp will save a copy of the PDF document to the CCL history for the record
|-
| Bar Code Encoded Data
| The content of this is the data that will be encoded to the bar code, standard bxp -- replacments can be used. (Char Limit - 800)
|}

== Example Bar Code Settings ==
[[File:barcode_Settings.png|890px|thumb|left]]

== Example Bar Code Render==
[[File:barcode_Sample.png|890px|thumb|left]]

== Example Scan ==
[[File:barcode_Output.png|890px|thumb|left]]

File:barcode Output.png

2016-11-21T09:58:43Z

Patrick Jenkins: Patrick Jenkins uploaded a new version of File:barcode Output.png

File:barcode Output.png

2016-11-21T09:56:36Z

Patrick Jenkins:

File:barcode Sample.png

2016-11-21T09:42:04Z

Patrick Jenkins:

File:barcode Settings.png

2016-11-21T09:30:59Z

Patrick Jenkins:

MetaData - SEPA

2016-09-30T14:13:49Z

Patrick Jenkins: /* SEPA Import Form Required Fields */

== MetaData - SEPA Rule ==

bxp has the ability through MetaData, both manual and scheduled to generate a SEPA PAIN 008 file and import to a form a SEPA PAIN 002 Rejection file.

== SEPA Pain 008 Export ==

In order to generate a SEPA Pain 008 file bxp needs two forms, one to store all of the Header information for the file and one that stores the individual transaction data. Both the header form and the transaction form must contain the fields mentioned below.

Once the '''MetaData Process''' Rule has been set up correctly, bxp will cycle through the header and transaction forms taking all of the required data. The MetaData sequence needs to be set up on the transaction form as this controls the transactions to include in the file.

After a success full process bxp will store the SEPA Pain 008 file in the specified MetaData directory and also perform the following options:

1) Store a CCL of the SEPA file generation in all of the transaction records included

2) Store a CCL of the SEPA file generation in the header form record

3) Store a copy of the SEPA file generated in the header form record, once here this copy cannot be modified/deleted (optional action)

Reference Document -- [[Media:SEPA_008_LayoutDocument.pdf]]

=== Header Form Required Fields ===
{| class="wikitable"
|-
! #
! BOI XML Reference
! Information
! Manual or Automatic Data Entry
|-
| 1
| 1.1
| Message Information
| Manual
|-
| 2
| 2.2
| Creation Date Time
| Automatic
|-
| 3
| 1.6
| Number of transactions
| Automatic
|-
| 4
| 1.7
| Control Sum
| Automatic
|-
| 5
| 1.8
| Identification
| Manual
|-
| 6
| 2.1
| Payment Information Identification
| Manual
|-
| 7
| 2
| Payment Method
| Manual
|-
| 8
| 2.4
| Number of transactions
| Automatic
|-
| 9
| 2.5
| Control Sum
| Automatic
|-
| 10
| 2.9
| Code
| Manual
|-
| 11
| 2.12
| Code
| Manual
|-
| 12
| 2.14
| Sequence Type
| Manual
|-
| 13
| 2.17
| Proprietary
| Manual
|-
| 14
| 2.18
| Requested Collection Date
| Manual
|-
| 15
| 2.19
| Name
| Manual
|-
| 16
| 2.20
| IBAN
| Manual
|-
| 17
| 2.21
| BIC
| Manual
|}

=== Transaction Form Required Fields ===
{| class="wikitable"
|-
! #
! BOI XML Reference
! Information
! Manual or Automatic Data Entry
|-
| 1
| 2.30
| Payment Identification/Instruction Identification
| Manual
|-
| 2
| 2.31
| Payment Identification/End to End Identification
| Manual
|-
| 3
| 2.44
| Instructed Amount
| Manual
|-
| 4
| 2.48
| Mandate Identification
| Manual
|-
| 5
| 2.49
| Date of Signature
| Manual
|-
| 6
| 2.66
| Identification
| Manual
|-
| 7
| 2.66
| Proprietary
| Manual
|-
| 8
| 2.70
| Financial Institution Identification
| Manual
|-
| 9
| 2.72
| Name
| Manual
|-
| 10
| 2.73
| IBAN
| Manual
|}

=== Rule Parameter Explanation ===
{| class="wikitable"
|-
! #
! Example
! Type
! Mandatory
! Description
|-
| 0
| SEPAFileGeneration
| Text
| True
| This tells bxp what rule to execute and must be as specified
|-
| 1
| Header Form Id
| Number
| True
| This tells bxp what form contains the header information
|-
| 2
| Header Record Id
| Number
| True
| This tells bxp what record contains the header information
|-
| 3
| Header form fields
| Text
| True
| This tells bxp the fields that the header information are stored
|-
| 4
| Transaction form Id
| Number
| True
| This tells bxp what form contains the transaction information
|-
| 5
| Transaction form fields
| Text
| True
| This tells bxp the fields that the transaction information are stored
|-
| 6
| Record Status update
| True/False
| True
| This tells bxp to apply a custom status to the records updated
|-
| 7
| Custom Status to apply
| Text
| True
| This is the custom status that will be applied to the records
|-
| 8
| Store in CCL of Record
| True/False
| True
| This tells bxp to store a copy of the XML file in the CCL of the header record
|-
| 9
| Sub folder Location
| Text
| True
| This tells bxp to look in sub folders if specified
|}

=== Example Rule ===

<syntaxhighlight lang="java">
SEPAFileGeneration
[[-SEP-]]1
[[-SEP-]]1
[[-SEP-]]strCDA_1_field_0_1,strCDA_1_field_0_2,..............,strCDA_1_field_0_16,strCDA_1_field_0_17
[[-SEP-]]2
[[-SEP-]]strCDA_2_field_0_1,strCDA_2_field_0_2,..............,strCDA_2_field_0_9,strCDA_2_field_0_10
[[-SEP-]]True
[[-SEP-]]SEPA FILE GENERATION
[[-SEP-]]True
[[-SEP-]]SubFolder1\SubFolder2\SubFolder3
[[-SEP-]]
[[-SEP-]]
[[-SEP-]]
[[-SEP-]]
[[-SEP-]]
[[-SEP-]]
[[-SEP-]]
[[-SEP-]]
</syntaxhighlight>

== SEPA Pain 002 Import==

In order to import a SEPA Pain 002 file bxp needs one forms, one to store all of the transaction information as wee as the group header information. The form must contain the fields mentioned below.

Once the '''MetaData Input''' Rule has been set up correctly, bxp will go through .xml files in the specified location and take all group header information and refused transaction information and store them in the form. Please note that there will be one record in the form for every refused transaction.

After a success full process bxp will perform the following options:

1) Store a CCL of the refusal record creation for each record created

2) Update the Refusal Reason to include the English Reason i.e. convert the refusal code

3) Store a CCL of the SEPA file that was processed for each record created (optional action - but highly recommended)

4) Delete the original file from the specified location (optional action - but highly recommended)

Reference Document -- [[Media:SEPA_002_LayoutDocument.pdf]]

=== SEPA Import Form Required Fields ===
{| class="wikitable"
|-
! #
! BOI XML Reference
! Information
! XML Data Path
|-
| 1
| 1.1
| Message Identification
| GrpHdr > MsgId
|-
| 2
| 1.2
| Creation Date Time
| GrpHdr > CreDtTm
|-
| 3
| 1.6
| BIC
| GrpHdr > CdtrAgt > FinInstnId > BIC
|-
| 4
| 2.1
| Original Message Identification
| OrgnlGrpInfAndSts > OrgnlMsgId
|-
| 5
| 2.2
| Original Message Name Identification
| OrgnlGrpInfAndSts > OrgnlMsgNmId
|-
| 6
| 2.4
| Original Number of Transactions
| OrgnlGrpInfAndSts > OrgnlNbOfTxs
|-
| 7
| 2.5
| Original Control Sum
| OrgnlGrpInfAndSts > OrgnlCtrlSum
|-
| 8
| 3.1
| Original Payment Information Identification
| OrgnlPmtInfAndSts > OrgnlPmtInfId
|-
| 9
| 3.2
| Original Number Of Transactions
| OrgnlPmtInfAndSts > OrgnlNbOfTxs
|-
| 10
| 3.3
| Original Control Sum
| OrgnlPmtInfAndSts > OrgnlCtrlSum
|-
| 11
| 3.16
| Status Identification
| TxInfAndSts > StsId
|-
| 12
| 3.17
| Original Instruction Identification
| TxInfAndSts > OrgnlInstrId
|-
| 13
| 3.18
| Original End To End Identification
| TxInfAndSts > OrgnlEndToEndId
|-
| 14
| 3.19
| Transaction Status
| TxInfAndSts > TxSts
|-
| 15
| 3.21
| BIC Or BEI
| TxInfAndSts > StsRsnInf > Orgtr > Id > OrgId > BICOrBEI
|-
| 16
| 3.23
| Code
| TxInfAndSts > StsRsnInf > Rsn > Cd
|-
| 17
| 3.35
| Instructed Amount
| TxInfAndSts > OrgnlTxRef > Amt > InstdAmt
|-
| 18
| 3.40
| Requested Collection Date
| TxInfAndSts > OrgnlTxRef > ReqdColltnDt
|-
| 19
| 3.42
| Identification
| TxInfAndSts > OrgnlTxRef > CdtrSchmeId > Id > PrvtId > Othr > Id
|-
| 20
| 3.42
| Proprietary
| TxInfAndSts > OrgnlTxRef > CdtrSchmeId > Id > PrvtId > Othr > SchmeNm > Prtry
|-
| 21
| 3.59
| Code
| TxInfAndSts > OrgnlTxRef > PmtTpInf > SvcLvl > Cd
|-
| 22
| 3.62
| Code
| TxInfAndSts > OrgnlTxRef > PmtTpInf > LclInstrm > Cd
|-
| 23
| 3.64
| SequenceType
| TxInfAndSts > OrgnlTxRef > PmtTpInf > SeqTp
|-
| 24
| 3.67
| Proprietary
| TxInfAndSts > OrgnlTxRef > PmtTpInf > CtgyPurp > Prtry
|-
| 25
| 3.70
| Mandate Identification
| TxInfAndSts > OrgnlTxRef > MndtRltdInf > MndtId
|-
| 26
| 3.71
| Date of Signature
| TxInfAndSts > OrgnlTxRef > MndtRltdInf > DtOfSgntr
|-
| 27
| 3.72
| Amendment Indicator
| TxInfAndSts > OrgnlTxRef > MndtRltdInf > AmdmntInd
|-
| 28
| 3.121
| Name
| TxInfAndSts > OrgnlTxRef > Dbtr > Nm
|-
| 29
| 3.122
| IBAN
| TxInfAndSts > OrgnlTxRef > DbtrAcct > Id > IBAN
|-
| 30
| 3.123
| BIC
| TxInfAndSts > OrgnlTxRef > DbtrAgt > FinInstnId > BIC
|-
| 31
| 3.125
| BIC
| TxInfAndSts > OrgnlTxRef > CdtrAgt > FinInstnId > BIC
|-
| 32
| 3.127
| Name
| TxInfAndSts > OrgnlTxRef > Cdtr > Nm
|-
| 33
| 3.128
| IBAN
| TxInfAndSts > OrgnlTxRef > CdtrAcct > Id > IBAN
|-
|}

=== Example Rule ===
<syntaxhighlight lang="java">
SEPA002FileRead
[[-SEP-]]1
[[-SEP-]]strCDA_1_field_0_1,strCDA_1_field_0_2,..............,strCDA_1_field_0_32,strCDA_1_field_0_33
[[-SEP-]]SubFolder1\SubFolder2\SubFolder3
[[-SEP-]]True
[[-SEP-]]SEPA Rejection
[[-SEP-]]False
[[-SEP-]]
[[-SEP-]]
[[-SEP-]]
[[-SEP-]]
[[-SEP-]]
[[-SEP-]]
</syntaxhighlight>

MetaData - SEPA

2016-09-30T14:13:07Z

Patrick Jenkins: /* SEPA Pain 002 Import */

== MetaData - SEPA Rule ==

bxp has the ability through MetaData, both manual and scheduled to generate a SEPA PAIN 008 file and import to a form a SEPA PAIN 002 Rejection file.

== SEPA Pain 008 Export ==

In order to generate a SEPA Pain 008 file bxp needs two forms, one to store all of the Header information for the file and one that stores the individual transaction data. Both the header form and the transaction form must contain the fields mentioned below.

Once the '''MetaData Process''' Rule has been set up correctly, bxp will cycle through the header and transaction forms taking all of the required data. The MetaData sequence needs to be set up on the transaction form as this controls the transactions to include in the file.

After a success full process bxp will store the SEPA Pain 008 file in the specified MetaData directory and also perform the following options:

1) Store a CCL of the SEPA file generation in all of the transaction records included

2) Store a CCL of the SEPA file generation in the header form record

3) Store a copy of the SEPA file generated in the header form record, once here this copy cannot be modified/deleted (optional action)

Reference Document -- [[Media:SEPA_008_LayoutDocument.pdf]]

=== Header Form Required Fields ===
{| class="wikitable"
|-
! #
! BOI XML Reference
! Information
! Manual or Automatic Data Entry
|-
| 1
| 1.1
| Message Information
| Manual
|-
| 2
| 2.2
| Creation Date Time
| Automatic
|-
| 3
| 1.6
| Number of transactions
| Automatic
|-
| 4
| 1.7
| Control Sum
| Automatic
|-
| 5
| 1.8
| Identification
| Manual
|-
| 6
| 2.1
| Payment Information Identification
| Manual
|-
| 7
| 2
| Payment Method
| Manual
|-
| 8
| 2.4
| Number of transactions
| Automatic
|-
| 9
| 2.5
| Control Sum
| Automatic
|-
| 10
| 2.9
| Code
| Manual
|-
| 11
| 2.12
| Code
| Manual
|-
| 12
| 2.14
| Sequence Type
| Manual
|-
| 13
| 2.17
| Proprietary
| Manual
|-
| 14
| 2.18
| Requested Collection Date
| Manual
|-
| 15
| 2.19
| Name
| Manual
|-
| 16
| 2.20
| IBAN
| Manual
|-
| 17
| 2.21
| BIC
| Manual
|}

=== Transaction Form Required Fields ===
{| class="wikitable"
|-
! #
! BOI XML Reference
! Information
! Manual or Automatic Data Entry
|-
| 1
| 2.30
| Payment Identification/Instruction Identification
| Manual
|-
| 2
| 2.31
| Payment Identification/End to End Identification
| Manual
|-
| 3
| 2.44
| Instructed Amount
| Manual
|-
| 4
| 2.48
| Mandate Identification
| Manual
|-
| 5
| 2.49
| Date of Signature
| Manual
|-
| 6
| 2.66
| Identification
| Manual
|-
| 7
| 2.66
| Proprietary
| Manual
|-
| 8
| 2.70
| Financial Institution Identification
| Manual
|-
| 9
| 2.72
| Name
| Manual
|-
| 10
| 2.73
| IBAN
| Manual
|}

=== Rule Parameter Explanation ===
{| class="wikitable"
|-
! #
! Example
! Type
! Mandatory
! Description
|-
| 0
| SEPAFileGeneration
| Text
| True
| This tells bxp what rule to execute and must be as specified
|-
| 1
| Header Form Id
| Number
| True
| This tells bxp what form contains the header information
|-
| 2
| Header Record Id
| Number
| True
| This tells bxp what record contains the header information
|-
| 3
| Header form fields
| Text
| True
| This tells bxp the fields that the header information are stored
|-
| 4
| Transaction form Id
| Number
| True
| This tells bxp what form contains the transaction information
|-
| 5
| Transaction form fields
| Text
| True
| This tells bxp the fields that the transaction information are stored
|-
| 6
| Record Status update
| True/False
| True
| This tells bxp to apply a custom status to the records updated
|-
| 7
| Custom Status to apply
| Text
| True
| This is the custom status that will be applied to the records
|-
| 8
| Store in CCL of Record
| True/False
| True
| This tells bxp to store a copy of the XML file in the CCL of the header record
|-
| 9
| Sub folder Location
| Text
| True
| This tells bxp to look in sub folders if specified
|}

=== Example Rule ===

<syntaxhighlight lang="java">
SEPAFileGeneration
[[-SEP-]]1
[[-SEP-]]1
[[-SEP-]]strCDA_1_field_0_1,strCDA_1_field_0_2,..............,strCDA_1_field_0_16,strCDA_1_field_0_17
[[-SEP-]]2
[[-SEP-]]strCDA_2_field_0_1,strCDA_2_field_0_2,..............,strCDA_2_field_0_9,strCDA_2_field_0_10
[[-SEP-]]True
[[-SEP-]]SEPA FILE GENERATION
[[-SEP-]]True
[[-SEP-]]SubFolder1\SubFolder2\SubFolder3
[[-SEP-]]
[[-SEP-]]
[[-SEP-]]
[[-SEP-]]
[[-SEP-]]
[[-SEP-]]
[[-SEP-]]
[[-SEP-]]
</syntaxhighlight>

== SEPA Pain 002 Import==

In order to import a SEPA Pain 002 file bxp needs one forms, one to store all of the transaction information as wee as the group header information. The form must contain the fields mentioned below.

Once the '''MetaData Input''' Rule has been set up correctly, bxp will go through .xml files in the specified location and take all group header information and refused transaction information and store them in the form. Please note that there will be one record in the form for every refused transaction.

After a success full process bxp will perform the following options:

1) Store a CCL of the refusal record creation for each record created

2) Update the Refusal Reason to include the English Reason i.e. convert the refusal code

3) Store a CCL of the SEPA file that was processed for each record created (optional action - but highly recommended)

4) Delete the original file from the specified location (optional action - but highly recommended)

Reference Document -- [[Media:SEPA_002_LayoutDocument.pdf]]

=== SEPA Import Form Required Fields ===
{| class="wikitable"
|-
! #
! BOI XML Reference
! Information
| XML Data Path
|-
| 1
| 1.1
| Message Identification
| GrpHdr > MsgId
|-
| 2
| 1.2
| Creation Date Time
| GrpHdr > CreDtTm
|-
| 3
| 1.6
| BIC
| GrpHdr > CdtrAgt > FinInstnId > BIC
|-
| 4
| 2.1
| Original Message Identification
| OrgnlGrpInfAndSts > OrgnlMsgId
|-
| 5
| 2.2
| Original Message Name Identification
| OrgnlGrpInfAndSts > OrgnlMsgNmId
|-
| 6
| 2.4
| Original Number of Transactions
| OrgnlGrpInfAndSts > OrgnlNbOfTxs
|-
| 7
| 2.5
| Original Control Sum
| OrgnlGrpInfAndSts > OrgnlCtrlSum
|-
| 8
| 3.1
| Original Payment Information Identification
| OrgnlPmtInfAndSts > OrgnlPmtInfId
|-
| 9
| 3.2
| Original Number Of Transactions
| OrgnlPmtInfAndSts > OrgnlNbOfTxs
|-
| 10
| 3.3
| Original Control Sum
| OrgnlPmtInfAndSts > OrgnlCtrlSum
|-
| 11
| 3.16
| Status Identification
| TxInfAndSts > StsId
|-
| 12
| 3.17
| Original Instruction Identification
| TxInfAndSts > OrgnlInstrId
|-
| 13
| 3.18
| Original End To End Identification
| TxInfAndSts > OrgnlEndToEndId
|-
| 14
| 3.19
| Transaction Status
| TxInfAndSts > TxSts
|-
| 15
| 3.21
| BIC Or BEI
| TxInfAndSts > StsRsnInf > Orgtr > Id > OrgId > BICOrBEI
|-
| 16
| 3.23
| Code
| TxInfAndSts > StsRsnInf > Rsn > Cd
|-
| 17
| 3.35
| Instructed Amount
| TxInfAndSts > OrgnlTxRef > Amt > InstdAmt
|-
| 18
| 3.40
| Requested Collection Date
| TxInfAndSts > OrgnlTxRef > ReqdColltnDt
|-
| 19
| 3.42
| Identification
| TxInfAndSts > OrgnlTxRef > CdtrSchmeId > Id > PrvtId > Othr > Id
|-
| 20
| 3.42
| Proprietary
| TxInfAndSts > OrgnlTxRef > CdtrSchmeId > Id > PrvtId > Othr > SchmeNm > Prtry
|-
| 21
| 3.59
| Code
| TxInfAndSts > OrgnlTxRef > PmtTpInf > SvcLvl > Cd
|-
| 22
| 3.62
| Code
| TxInfAndSts > OrgnlTxRef > PmtTpInf > LclInstrm > Cd
|-
| 23
| 3.64
| SequenceType
| TxInfAndSts > OrgnlTxRef > PmtTpInf > SeqTp
|-
| 24
| 3.67
| Proprietary
| TxInfAndSts > OrgnlTxRef > PmtTpInf > CtgyPurp > Prtry
|-
| 25
| 3.70
| Mandate Identification
| TxInfAndSts > OrgnlTxRef > MndtRltdInf > MndtId
|-
| 26
| 3.71
| Date of Signature
| TxInfAndSts > OrgnlTxRef > MndtRltdInf > DtOfSgntr
|-
| 27
| 3.72
| Amendment Indicator
| TxInfAndSts > OrgnlTxRef > MndtRltdInf > AmdmntInd
|-
| 28
| 3.121
| Name
| TxInfAndSts > OrgnlTxRef > Dbtr > Nm
|-
| 29
| 3.122
| IBAN
| TxInfAndSts > OrgnlTxRef > DbtrAcct > Id > IBAN
|-
| 30
| 3.123
| BIC
| TxInfAndSts > OrgnlTxRef > DbtrAgt > FinInstnId > BIC
|-
| 31
| 3.125
| BIC
| TxInfAndSts > OrgnlTxRef > CdtrAgt > FinInstnId > BIC
|-
| 32
| 3.127
| Name
| TxInfAndSts > OrgnlTxRef > Cdtr > Nm
|-
| 33
| 3.128
| IBAN
| TxInfAndSts > OrgnlTxRef > CdtrAcct > Id > IBAN
|-
|}

=== Example Rule ===
<syntaxhighlight lang="java">
SEPA002FileRead
[[-SEP-]]1
[[-SEP-]]strCDA_1_field_0_1,strCDA_1_field_0_2,..............,strCDA_1_field_0_32,strCDA_1_field_0_33
[[-SEP-]]SubFolder1\SubFolder2\SubFolder3
[[-SEP-]]True
[[-SEP-]]SEPA Rejection
[[-SEP-]]False
[[-SEP-]]
[[-SEP-]]
[[-SEP-]]
[[-SEP-]]
[[-SEP-]]
[[-SEP-]]
</syntaxhighlight>

MetaData - SEPA

2016-09-30T14:11:42Z

Patrick Jenkins: /* SEPA Import Form Required Fields */

== MetaData - SEPA Rule ==

bxp has the ability through MetaData, both manual and scheduled to generate a SEPA PAIN 008 file and import to a form a SEPA PAIN 002 Rejection file.

== SEPA Pain 008 Export ==

In order to generate a SEPA Pain 008 file bxp needs two forms, one to store all of the Header information for the file and one that stores the individual transaction data. Both the header form and the transaction form must contain the fields mentioned below.

Once the '''MetaData Process''' Rule has been set up correctly, bxp will cycle through the header and transaction forms taking all of the required data. The MetaData sequence needs to be set up on the transaction form as this controls the transactions to include in the file.

After a success full process bxp will store the SEPA Pain 008 file in the specified MetaData directory and also perform the following options:

1) Store a CCL of the SEPA file generation in all of the transaction records included

2) Store a CCL of the SEPA file generation in the header form record

3) Store a copy of the SEPA file generated in the header form record, once here this copy cannot be modified/deleted (optional action)

Reference Document -- [[Media:SEPA_008_LayoutDocument.pdf]]

=== Header Form Required Fields ===
{| class="wikitable"
|-
! #
! BOI XML Reference
! Information
! Manual or Automatic Data Entry
|-
| 1
| 1.1
| Message Information
| Manual
|-
| 2
| 2.2
| Creation Date Time
| Automatic
|-
| 3
| 1.6
| Number of transactions
| Automatic
|-
| 4
| 1.7
| Control Sum
| Automatic
|-
| 5
| 1.8
| Identification
| Manual
|-
| 6
| 2.1
| Payment Information Identification
| Manual
|-
| 7
| 2
| Payment Method
| Manual
|-
| 8
| 2.4
| Number of transactions
| Automatic
|-
| 9
| 2.5
| Control Sum
| Automatic
|-
| 10
| 2.9
| Code
| Manual
|-
| 11
| 2.12
| Code
| Manual
|-
| 12
| 2.14
| Sequence Type
| Manual
|-
| 13
| 2.17
| Proprietary
| Manual
|-
| 14
| 2.18
| Requested Collection Date
| Manual
|-
| 15
| 2.19
| Name
| Manual
|-
| 16
| 2.20
| IBAN
| Manual
|-
| 17
| 2.21
| BIC
| Manual
|}

=== Transaction Form Required Fields ===
{| class="wikitable"
|-
! #
! BOI XML Reference
! Information
! Manual or Automatic Data Entry
|-
| 1
| 2.30
| Payment Identification/Instruction Identification
| Manual
|-
| 2
| 2.31
| Payment Identification/End to End Identification
| Manual
|-
| 3
| 2.44
| Instructed Amount
| Manual
|-
| 4
| 2.48
| Mandate Identification
| Manual
|-
| 5
| 2.49
| Date of Signature
| Manual
|-
| 6
| 2.66
| Identification
| Manual
|-
| 7
| 2.66
| Proprietary
| Manual
|-
| 8
| 2.70
| Financial Institution Identification
| Manual
|-
| 9
| 2.72
| Name
| Manual
|-
| 10
| 2.73
| IBAN
| Manual
|}

=== Rule Parameter Explanation ===
{| class="wikitable"
|-
! #
! Example
! Type
! Mandatory
! Description
|-
| 0
| SEPAFileGeneration
| Text
| True
| This tells bxp what rule to execute and must be as specified
|-
| 1
| Header Form Id
| Number
| True
| This tells bxp what form contains the header information
|-
| 2
| Header Record Id
| Number
| True
| This tells bxp what record contains the header information
|-
| 3
| Header form fields
| Text
| True
| This tells bxp the fields that the header information are stored
|-
| 4
| Transaction form Id
| Number
| True
| This tells bxp what form contains the transaction information
|-
| 5
| Transaction form fields
| Text
| True
| This tells bxp the fields that the transaction information are stored
|-
| 6
| Record Status update
| True/False
| True
| This tells bxp to apply a custom status to the records updated
|-
| 7
| Custom Status to apply
| Text
| True
| This is the custom status that will be applied to the records
|-
| 8
| Store in CCL of Record
| True/False
| True
| This tells bxp to store a copy of the XML file in the CCL of the header record
|-
| 9
| Sub folder Location
| Text
| True
| This tells bxp to look in sub folders if specified
|}

=== Example Rule ===

<syntaxhighlight lang="java">
SEPAFileGeneration
[[-SEP-]]1
[[-SEP-]]1
[[-SEP-]]strCDA_1_field_0_1,strCDA_1_field_0_2,..............,strCDA_1_field_0_16,strCDA_1_field_0_17
[[-SEP-]]2
[[-SEP-]]strCDA_2_field_0_1,strCDA_2_field_0_2,..............,strCDA_2_field_0_9,strCDA_2_field_0_10
[[-SEP-]]True
[[-SEP-]]SEPA FILE GENERATION
[[-SEP-]]True
[[-SEP-]]SubFolder1\SubFolder2\SubFolder3
[[-SEP-]]
[[-SEP-]]
[[-SEP-]]
[[-SEP-]]
[[-SEP-]]
[[-SEP-]]
[[-SEP-]]
[[-SEP-]]
</syntaxhighlight>

== SEPA Pain 002 Import==

In order to import a SEPA Pain 002 file bxp needs one forms, one to store all of the transaction information as wee as the group header information. The form must contain the fields mentioned below.

Once the '''MetaData Input''' Rule has been set up correctly, bxp will go through .xml files in the specified location and take all group header information and refused transaction information and store them in the form. Please note that there will be one record in the form for every refused transaction.

After a success full process bxp will perform the following options:

1) Store a CCL of the refusal record creation for each record created

2) Store a CCL of the SEPA file that was processed for each record created (optional action - but highly recommended)

3) Delete the original file from the specified location (optional action - but highly recommended)

Reference Document -- [[Media:SEPA_002_LayoutDocument.pdf]]

=== SEPA Import Form Required Fields ===
{| class="wikitable"
|-
! #
! BOI XML Reference
! Information
| XML Data Path
|-
| 1
| 1.1
| Message Identification
| GrpHdr > MsgId
|-
| 2
| 1.2
| Creation Date Time
| GrpHdr > CreDtTm
|-
| 3
| 1.6
| BIC
| GrpHdr > CdtrAgt > FinInstnId > BIC
|-
| 4
| 2.1
| Original Message Identification
| OrgnlGrpInfAndSts > OrgnlMsgId
|-
| 5
| 2.2
| Original Message Name Identification
| OrgnlGrpInfAndSts > OrgnlMsgNmId
|-
| 6
| 2.4
| Original Number of Transactions
| OrgnlGrpInfAndSts > OrgnlNbOfTxs
|-
| 7
| 2.5
| Original Control Sum
| OrgnlGrpInfAndSts > OrgnlCtrlSum
|-
| 8
| 3.1
| Original Payment Information Identification
| OrgnlPmtInfAndSts > OrgnlPmtInfId
|-
| 9
| 3.2
| Original Number Of Transactions
| OrgnlPmtInfAndSts > OrgnlNbOfTxs
|-
| 10
| 3.3
| Original Control Sum
| OrgnlPmtInfAndSts > OrgnlCtrlSum
|-
| 11
| 3.16
| Status Identification
| TxInfAndSts > StsId
|-
| 12
| 3.17
| Original Instruction Identification
| TxInfAndSts > OrgnlInstrId
|-
| 13
| 3.18
| Original End To End Identification
| TxInfAndSts > OrgnlEndToEndId
|-
| 14
| 3.19
| Transaction Status
| TxInfAndSts > TxSts
|-
| 15
| 3.21
| BIC Or BEI
| TxInfAndSts > StsRsnInf > Orgtr > Id > OrgId > BICOrBEI
|-
| 16
| 3.23
| Code
| TxInfAndSts > StsRsnInf > Rsn > Cd
|-
| 17
| 3.35
| Instructed Amount
| TxInfAndSts > OrgnlTxRef > Amt > InstdAmt
|-
| 18
| 3.40
| Requested Collection Date
| TxInfAndSts > OrgnlTxRef > ReqdColltnDt
|-
| 19
| 3.42
| Identification
| TxInfAndSts > OrgnlTxRef > CdtrSchmeId > Id > PrvtId > Othr > Id
|-
| 20
| 3.42
| Proprietary
| TxInfAndSts > OrgnlTxRef > CdtrSchmeId > Id > PrvtId > Othr > SchmeNm > Prtry
|-
| 21
| 3.59
| Code
| TxInfAndSts > OrgnlTxRef > PmtTpInf > SvcLvl > Cd
|-
| 22
| 3.62
| Code
| TxInfAndSts > OrgnlTxRef > PmtTpInf > LclInstrm > Cd
|-
| 23
| 3.64
| SequenceType
| TxInfAndSts > OrgnlTxRef > PmtTpInf > SeqTp
|-
| 24
| 3.67
| Proprietary
| TxInfAndSts > OrgnlTxRef > PmtTpInf > CtgyPurp > Prtry
|-
| 25
| 3.70
| Mandate Identification
| TxInfAndSts > OrgnlTxRef > MndtRltdInf > MndtId
|-
| 26
| 3.71
| Date of Signature
| TxInfAndSts > OrgnlTxRef > MndtRltdInf > DtOfSgntr
|-
| 27
| 3.72
| Amendment Indicator
| TxInfAndSts > OrgnlTxRef > MndtRltdInf > AmdmntInd
|-
| 28
| 3.121
| Name
| TxInfAndSts > OrgnlTxRef > Dbtr > Nm
|-
| 29
| 3.122
| IBAN
| TxInfAndSts > OrgnlTxRef > DbtrAcct > Id > IBAN
|-
| 30
| 3.123
| BIC
| TxInfAndSts > OrgnlTxRef > DbtrAgt > FinInstnId > BIC
|-
| 31
| 3.125
| BIC
| TxInfAndSts > OrgnlTxRef > CdtrAgt > FinInstnId > BIC
|-
| 32
| 3.127
| Name
| TxInfAndSts > OrgnlTxRef > Cdtr > Nm
|-
| 33
| 3.128
| IBAN
| TxInfAndSts > OrgnlTxRef > CdtrAcct > Id > IBAN
|-
|}

=== Example Rule ===
<syntaxhighlight lang="java">
SEPA002FileRead
[[-SEP-]]1
[[-SEP-]]strCDA_1_field_0_1,strCDA_1_field_0_2,..............,strCDA_1_field_0_32,strCDA_1_field_0_33
[[-SEP-]]SubFolder1\SubFolder2\SubFolder3
[[-SEP-]]True
[[-SEP-]]SEPA Rejection
[[-SEP-]]False
[[-SEP-]]
[[-SEP-]]
[[-SEP-]]
[[-SEP-]]
[[-SEP-]]
[[-SEP-]]
</syntaxhighlight>

MetaData - SEPA

2016-09-30T14:06:30Z

Patrick Jenkins: /* SEPA Import Form Required Fields */

== MetaData - SEPA Rule ==

bxp has the ability through MetaData, both manual and scheduled to generate a SEPA PAIN 008 file and import to a form a SEPA PAIN 002 Rejection file.

== SEPA Pain 008 Export ==

In order to generate a SEPA Pain 008 file bxp needs two forms, one to store all of the Header information for the file and one that stores the individual transaction data. Both the header form and the transaction form must contain the fields mentioned below.

Once the '''MetaData Process''' Rule has been set up correctly, bxp will cycle through the header and transaction forms taking all of the required data. The MetaData sequence needs to be set up on the transaction form as this controls the transactions to include in the file.

After a success full process bxp will store the SEPA Pain 008 file in the specified MetaData directory and also perform the following options:

1) Store a CCL of the SEPA file generation in all of the transaction records included

2) Store a CCL of the SEPA file generation in the header form record

3) Store a copy of the SEPA file generated in the header form record, once here this copy cannot be modified/deleted (optional action)

Reference Document -- [[Media:SEPA_008_LayoutDocument.pdf]]

=== Header Form Required Fields ===
{| class="wikitable"
|-
! #
! BOI XML Reference
! Information
! Manual or Automatic Data Entry
|-
| 1
| 1.1
| Message Information
| Manual
|-
| 2
| 2.2
| Creation Date Time
| Automatic
|-
| 3
| 1.6
| Number of transactions
| Automatic
|-
| 4
| 1.7
| Control Sum
| Automatic
|-
| 5
| 1.8
| Identification
| Manual
|-
| 6
| 2.1
| Payment Information Identification
| Manual
|-
| 7
| 2
| Payment Method
| Manual
|-
| 8
| 2.4
| Number of transactions
| Automatic
|-
| 9
| 2.5
| Control Sum
| Automatic
|-
| 10
| 2.9
| Code
| Manual
|-
| 11
| 2.12
| Code
| Manual
|-
| 12
| 2.14
| Sequence Type
| Manual
|-
| 13
| 2.17
| Proprietary
| Manual
|-
| 14
| 2.18
| Requested Collection Date
| Manual
|-
| 15
| 2.19
| Name
| Manual
|-
| 16
| 2.20
| IBAN
| Manual
|-
| 17
| 2.21
| BIC
| Manual
|}

=== Transaction Form Required Fields ===
{| class="wikitable"
|-
! #
! BOI XML Reference
! Information
! Manual or Automatic Data Entry
|-
| 1
| 2.30
| Payment Identification/Instruction Identification
| Manual
|-
| 2
| 2.31
| Payment Identification/End to End Identification
| Manual
|-
| 3
| 2.44
| Instructed Amount
| Manual
|-
| 4
| 2.48
| Mandate Identification
| Manual
|-
| 5
| 2.49
| Date of Signature
| Manual
|-
| 6
| 2.66
| Identification
| Manual
|-
| 7
| 2.66
| Proprietary
| Manual
|-
| 8
| 2.70
| Financial Institution Identification
| Manual
|-
| 9
| 2.72
| Name
| Manual
|-
| 10
| 2.73
| IBAN
| Manual
|}

=== Rule Parameter Explanation ===
{| class="wikitable"
|-
! #
! Example
! Type
! Mandatory
! Description
|-
| 0
| SEPAFileGeneration
| Text
| True
| This tells bxp what rule to execute and must be as specified
|-
| 1
| Header Form Id
| Number
| True
| This tells bxp what form contains the header information
|-
| 2
| Header Record Id
| Number
| True
| This tells bxp what record contains the header information
|-
| 3
| Header form fields
| Text
| True
| This tells bxp the fields that the header information are stored
|-
| 4
| Transaction form Id
| Number
| True
| This tells bxp what form contains the transaction information
|-
| 5
| Transaction form fields
| Text
| True
| This tells bxp the fields that the transaction information are stored
|-
| 6
| Record Status update
| True/False
| True
| This tells bxp to apply a custom status to the records updated
|-
| 7
| Custom Status to apply
| Text
| True
| This is the custom status that will be applied to the records
|-
| 8
| Store in CCL of Record
| True/False
| True
| This tells bxp to store a copy of the XML file in the CCL of the header record
|-
| 9
| Sub folder Location
| Text
| True
| This tells bxp to look in sub folders if specified
|}

=== Example Rule ===

<syntaxhighlight lang="java">
SEPAFileGeneration
[[-SEP-]]1
[[-SEP-]]1
[[-SEP-]]strCDA_1_field_0_1,strCDA_1_field_0_2,..............,strCDA_1_field_0_16,strCDA_1_field_0_17
[[-SEP-]]2
[[-SEP-]]strCDA_2_field_0_1,strCDA_2_field_0_2,..............,strCDA_2_field_0_9,strCDA_2_field_0_10
[[-SEP-]]True
[[-SEP-]]SEPA FILE GENERATION
[[-SEP-]]True
[[-SEP-]]SubFolder1\SubFolder2\SubFolder3
[[-SEP-]]
[[-SEP-]]
[[-SEP-]]
[[-SEP-]]
[[-SEP-]]
[[-SEP-]]
[[-SEP-]]
[[-SEP-]]
</syntaxhighlight>

== SEPA Pain 002 Import==

In order to import a SEPA Pain 002 file bxp needs one forms, one to store all of the transaction information as wee as the group header information. The form must contain the fields mentioned below.

Once the '''MetaData Input''' Rule has been set up correctly, bxp will go through .xml files in the specified location and take all group header information and refused transaction information and store them in the form. Please note that there will be one record in the form for every refused transaction.

After a success full process bxp will perform the following options:

1) Store a CCL of the refusal record creation for each record created

2) Store a CCL of the SEPA file that was processed for each record created (optional action - but highly recommended)

3) Delete the original file from the specified location (optional action - but highly recommended)

Reference Document -- [[Media:SEPA_002_LayoutDocument.pdf]]

=== SEPA Import Form Required Fields ===
{| class="wikitable"
|-
! #
! BOI XML Reference
! Information
| XML Data Path
|-
| 1
| 1.1
| Message Identification
| GrpHdr > MsgId
|-
| 2
| 1.2
|
| GrpHdr > CreDtTm
|-
| 3
| 1.6
|
| GrpHdr > CdtrAgt > FinInstnId > BIC
|-
| 4
| 2.1
|
| OrgnlGrpInfAndSts > OrgnlMsgId
|-
| 5
| 2.2
|
| OrgnlGrpInfAndSts > OrgnlMsgNmId
|-
| 6
| 2.4
|
| OrgnlGrpInfAndSts > OrgnlNbOfTxs
|-
| 7
| 2.5
|
| OrgnlGrpInfAndSts > OrgnlCtrlSum
|-
| 8
| 3.1
|
| OrgnlPmtInfAndSts > OrgnlPmtInfId
|-
| 9
| 3.2
|
| OrgnlPmtInfAndSts > OrgnlNbOfTxs
|-
| 10
| 3.3
|
| OrgnlPmtInfAndSts > OrgnlCtrlSum
|-
| 11
| 3.16
|
| TxInfAndSts > StsId
|-
| 12
| 3.17
|
| TxInfAndSts > OrgnlInstrId
|-
| 13
| 3.18
|
| TxInfAndSts > OrgnlEndToEndId
|-
| 14
| 3.19
|
| TxInfAndSts > TxSts
|-
| 15
| 3.21
|
| TxInfAndSts > StsRsnInf > Orgtr > Id > OrgId > BICOrBEI
|-
| 16
| 3.23
|
| TxInfAndSts > StsRsnInf > Rsn > Cd
|-
| 17
| 3.35
|
| TxInfAndSts > OrgnlTxRef > Amt > InstdAmt
|-
| 18
| 3.40
|
| TxInfAndSts > OrgnlTxRef > ReqdColltnDt
|-
| 19
| 3.42
|
| TxInfAndSts > OrgnlTxRef > CdtrSchmeId > Id > PrvtId > Othr > Id
|-
| 20
| 3.42
|
| TxInfAndSts > OrgnlTxRef > CdtrSchmeId > Id > PrvtId > Othr > SchmeNm > Prtry
|-
| 21
| 3.59
|
| TxInfAndSts > OrgnlTxRef > PmtTpInf > SvcLvl > Cd
|-
| 22
| 3.62
|
| TxInfAndSts > OrgnlTxRef > PmtTpInf > LclInstrm > Cd
|-
| 23
| 3.64
|
| TxInfAndSts > OrgnlTxRef > PmtTpInf > SeqTp
|-
| 24
| 3.67
|
| TxInfAndSts > OrgnlTxRef > PmtTpInf > CtgyPurp > Prtry
|-
| 25
| 3.70
|
| TxInfAndSts > OrgnlTxRef > MndtRltdInf > MndtId
|-
| 26
| 3.71
|
| TxInfAndSts > OrgnlTxRef > MndtRltdInf > DtOfSgntr
|-
| 27
| 3.72
|
| TxInfAndSts > OrgnlTxRef > MndtRltdInf > AmdmntInd
|-
| 28
| 3.121
|
| TxInfAndSts > OrgnlTxRef > Dbtr > Nm
|-
| 29
| 3.122
|
| TxInfAndSts > OrgnlTxRef > DbtrAcct > Id > IBAN
|-
| 30
| 3.123
|
| TxInfAndSts > OrgnlTxRef > DbtrAgt > FinInstnId > BIC
|-
| 31
| 3.125
|
| TxInfAndSts > OrgnlTxRef > CdtrAgt > FinInstnId > BIC
|-
| 32
| 3.127
|
| TxInfAndSts > OrgnlTxRef > Cdtr > Nm
|-
| 33
| 3.128
|
| TxInfAndSts > OrgnlTxRef > CdtrAcct > Id > IBAN
|-
|}

=== Example Rule ===
<syntaxhighlight lang="java">
SEPA002FileRead
[[-SEP-]]1
[[-SEP-]]strCDA_1_field_0_1,strCDA_1_field_0_2,..............,strCDA_1_field_0_32,strCDA_1_field_0_33
[[-SEP-]]SubFolder1\SubFolder2\SubFolder3
[[-SEP-]]True
[[-SEP-]]SEPA Rejection
[[-SEP-]]False
[[-SEP-]]
[[-SEP-]]
[[-SEP-]]
[[-SEP-]]
[[-SEP-]]
[[-SEP-]]
</syntaxhighlight>

MetaData - SEPA

2016-09-30T14:01:35Z

Patrick Jenkins:

== MetaData - SEPA Rule ==

bxp has the ability through MetaData, both manual and scheduled to generate a SEPA PAIN 008 file and import to a form a SEPA PAIN 002 Rejection file.

== SEPA Pain 008 Export ==

In order to generate a SEPA Pain 008 file bxp needs two forms, one to store all of the Header information for the file and one that stores the individual transaction data. Both the header form and the transaction form must contain the fields mentioned below.

Once the '''MetaData Process''' Rule has been set up correctly, bxp will cycle through the header and transaction forms taking all of the required data. The MetaData sequence needs to be set up on the transaction form as this controls the transactions to include in the file.

After a success full process bxp will store the SEPA Pain 008 file in the specified MetaData directory and also perform the following options:

1) Store a CCL of the SEPA file generation in all of the transaction records included

2) Store a CCL of the SEPA file generation in the header form record

3) Store a copy of the SEPA file generated in the header form record, once here this copy cannot be modified/deleted (optional action)

Reference Document -- [[Media:SEPA_008_LayoutDocument.pdf]]

=== Header Form Required Fields ===
{| class="wikitable"
|-
! #
! BOI XML Reference
! Information
! Manual or Automatic Data Entry
|-
| 1
| 1.1
| Message Information
| Manual
|-
| 2
| 2.2
| Creation Date Time
| Automatic
|-
| 3
| 1.6
| Number of transactions
| Automatic
|-
| 4
| 1.7
| Control Sum
| Automatic
|-
| 5
| 1.8
| Identification
| Manual
|-
| 6
| 2.1
| Payment Information Identification
| Manual
|-
| 7
| 2
| Payment Method
| Manual
|-
| 8
| 2.4
| Number of transactions
| Automatic
|-
| 9
| 2.5
| Control Sum
| Automatic
|-
| 10
| 2.9
| Code
| Manual
|-
| 11
| 2.12
| Code
| Manual
|-
| 12
| 2.14
| Sequence Type
| Manual
|-
| 13
| 2.17
| Proprietary
| Manual
|-
| 14
| 2.18
| Requested Collection Date
| Manual
|-
| 15
| 2.19
| Name
| Manual
|-
| 16
| 2.20
| IBAN
| Manual
|-
| 17
| 2.21
| BIC
| Manual
|}

=== Transaction Form Required Fields ===
{| class="wikitable"
|-
! #
! BOI XML Reference
! Information
! Manual or Automatic Data Entry
|-
| 1
| 2.30
| Payment Identification/Instruction Identification
| Manual
|-
| 2
| 2.31
| Payment Identification/End to End Identification
| Manual
|-
| 3
| 2.44
| Instructed Amount
| Manual
|-
| 4
| 2.48
| Mandate Identification
| Manual
|-
| 5
| 2.49
| Date of Signature
| Manual
|-
| 6
| 2.66
| Identification
| Manual
|-
| 7
| 2.66
| Proprietary
| Manual
|-
| 8
| 2.70
| Financial Institution Identification
| Manual
|-
| 9
| 2.72
| Name
| Manual
|-
| 10
| 2.73
| IBAN
| Manual
|}

=== Rule Parameter Explanation ===
{| class="wikitable"
|-
! #
! Example
! Type
! Mandatory
! Description
|-
| 0
| SEPAFileGeneration
| Text
| True
| This tells bxp what rule to execute and must be as specified
|-
| 1
| Header Form Id
| Number
| True
| This tells bxp what form contains the header information
|-
| 2
| Header Record Id
| Number
| True
| This tells bxp what record contains the header information
|-
| 3
| Header form fields
| Text
| True
| This tells bxp the fields that the header information are stored
|-
| 4
| Transaction form Id
| Number
| True
| This tells bxp what form contains the transaction information
|-
| 5
| Transaction form fields
| Text
| True
| This tells bxp the fields that the transaction information are stored
|-
| 6
| Record Status update
| True/False
| True
| This tells bxp to apply a custom status to the records updated
|-
| 7
| Custom Status to apply
| Text
| True
| This is the custom status that will be applied to the records
|-
| 8
| Store in CCL of Record
| True/False
| True
| This tells bxp to store a copy of the XML file in the CCL of the header record
|-
| 9
| Sub folder Location
| Text
| True
| This tells bxp to look in sub folders if specified
|}

=== Example Rule ===

<syntaxhighlight lang="java">
SEPAFileGeneration
[[-SEP-]]1
[[-SEP-]]1
[[-SEP-]]strCDA_1_field_0_1,strCDA_1_field_0_2,..............,strCDA_1_field_0_16,strCDA_1_field_0_17
[[-SEP-]]2
[[-SEP-]]strCDA_2_field_0_1,strCDA_2_field_0_2,..............,strCDA_2_field_0_9,strCDA_2_field_0_10
[[-SEP-]]True
[[-SEP-]]SEPA FILE GENERATION
[[-SEP-]]True
[[-SEP-]]SubFolder1\SubFolder2\SubFolder3
[[-SEP-]]
[[-SEP-]]
[[-SEP-]]
[[-SEP-]]
[[-SEP-]]
[[-SEP-]]
[[-SEP-]]
[[-SEP-]]
</syntaxhighlight>

== SEPA Pain 002 Import==

In order to import a SEPA Pain 002 file bxp needs one forms, one to store all of the transaction information as wee as the group header information. The form must contain the fields mentioned below.

Once the '''MetaData Input''' Rule has been set up correctly, bxp will go through .xml files in the specified location and take all group header information and refused transaction information and store them in the form. Please note that there will be one record in the form for every refused transaction.

After a success full process bxp will perform the following options:

1) Store a CCL of the refusal record creation for each record created

2) Store a CCL of the SEPA file that was processed for each record created (optional action - but highly recommended)

3) Delete the original file from the specified location (optional action - but highly recommended)

Reference Document -- [[Media:SEPA_002_LayoutDocument.pdf]]

=== SEPA Import Form Required Fields ===
{| class="wikitable"
|-
! #
! BOI XML Reference
! Information
|-
| 1
| 1.1
| GrpHdr > MsgId
|-
| 2
| 1.2
| GrpHdr > CreDtTm
|-
| 3
| 1.6
| GrpHdr > CdtrAgt > FinInstnId > BIC
|-
| 4
| 2.1
| OrgnlGrpInfAndSts > OrgnlMsgId
|-
| 5
| 2.2
| OrgnlGrpInfAndSts > OrgnlMsgNmId
|-
| 6
| 2.4
| OrgnlGrpInfAndSts > OrgnlNbOfTxs
|-
| 7
| 2.5
| OrgnlGrpInfAndSts > OrgnlCtrlSum
|-
| 8
| 3.1
| OrgnlPmtInfAndSts > OrgnlPmtInfId
|-
| 9
| 3.2
| OrgnlPmtInfAndSts > OrgnlNbOfTxs
|-
| 10
| 3.3
| OrgnlPmtInfAndSts > OrgnlCtrlSum
|-
| 11
| 3.16
| TxInfAndSts > StsId
|-
| 12
| 3.17
| TxInfAndSts > OrgnlInstrId
|-
| 13
| 3.18
| TxInfAndSts > OrgnlEndToEndId
|-
| 14
| 3.19
| TxInfAndSts > TxSts
|-
| 15
| 3.21
| TxInfAndSts > StsRsnInf > Orgtr > Id > OrgId > BICOrBEI
|-
| 16
| 3.23
| TxInfAndSts > StsRsnInf > Rsn > Cd
|-
| 17
| 3.35
| TxInfAndSts > OrgnlTxRef > Amt > InstdAmt
|-
| 18
| 3.40
| TxInfAndSts > OrgnlTxRef > ReqdColltnDt
|-
| 19
| 3.42
| TxInfAndSts > OrgnlTxRef > CdtrSchmeId > Id > PrvtId > Othr > Id
|-
| 20
| 3.42
| TxInfAndSts > OrgnlTxRef > CdtrSchmeId > Id > PrvtId > Othr > SchmeNm > Prtry
|-
| 21
| 3.59
| TxInfAndSts > OrgnlTxRef > PmtTpInf > SvcLvl > Cd
|-
| 22
| 3.62
| TxInfAndSts > OrgnlTxRef > PmtTpInf > LclInstrm > Cd
|-
| 23
| 3.64
| TxInfAndSts > OrgnlTxRef > PmtTpInf > SeqTp
|-
| 24
| 3.67
| TxInfAndSts > OrgnlTxRef > PmtTpInf > CtgyPurp > Prtry
|-
| 25
| 3.70
| TxInfAndSts > OrgnlTxRef > MndtRltdInf > MndtId
|-
| 26
| 3.71
| TxInfAndSts > OrgnlTxRef > MndtRltdInf > DtOfSgntr
|-
| 27
| 3.72
| TxInfAndSts > OrgnlTxRef > MndtRltdInf > AmdmntInd
|-
| 28
| 3.121
| TxInfAndSts > OrgnlTxRef > Dbtr > Nm
|-
| 29
| 3.122
| TxInfAndSts > OrgnlTxRef > DbtrAcct > Id > IBAN
|-
| 30
| 3.123
| TxInfAndSts > OrgnlTxRef > DbtrAgt > FinInstnId > BIC
|-
| 31
| 3.125
| TxInfAndSts > OrgnlTxRef > CdtrAgt > FinInstnId > BIC
|-
| 32
| 3.127
| TxInfAndSts > OrgnlTxRef > Cdtr > Nm
|-
| 33
| 3.128
| TxInfAndSts > OrgnlTxRef > CdtrAcct > Id > IBAN
|-
|}

=== Example Rule ===
<syntaxhighlight lang="java">
SEPA002FileRead
[[-SEP-]]1
[[-SEP-]]strCDA_1_field_0_1,strCDA_1_field_0_2,..............,strCDA_1_field_0_32,strCDA_1_field_0_33
[[-SEP-]]SubFolder1\SubFolder2\SubFolder3
[[-SEP-]]True
[[-SEP-]]SEPA Rejection
[[-SEP-]]False
[[-SEP-]]
[[-SEP-]]
[[-SEP-]]
[[-SEP-]]
[[-SEP-]]
[[-SEP-]]
</syntaxhighlight>

MetaData - SEPA

2016-09-30T13:34:59Z

Patrick Jenkins:

== MetaData - SEPA Rule ==

bxp has the ability through MetaData, both manual and scheduled to generate a SEPA PAIN 008 file and import to a form a SEPA PAIN 002 Rejection file.

== SEPA Pain 008 Export ==

In order to generate a SEPA Pain 008 file bxp needs two forms, one to store all of the Header information for the file and one that stores the individual transaction data. Both the header form and the transaction form must contain the fields mentioned below.

Once the '''MetaData Process''' Rule has been set up correctly, bxp will cycle through the header and transaction forms taking all of the required data. The MetaData sequence needs to be set up on the transaction form as this controls the transactions to include in the file.

After a success full process bxp will store the SEPA Pain 008 file in the specified MetaData directory and also perform the following options:

1) Store a CCL of the SEPA file generation in all of the transaction records included

2) Store a CCL of the SEPA file generation in the header form record

3) Store a copy of the SEPA file generated in the header form record, once here this copy cannot be modified/deleted (optional action)

Reference Document -- [[Media:SEPA_008_LayoutDocument.pdf]]

=== Header Form Required Fields ===
{| class="wikitable"
|-
! #
! BOI XML Reference
! Information
! Manual or Automatic Data Entry
|-
| 1
| 1.1
| Message Information
| Manual
|-
| 2
| 2.2
| Creation Date Time
| Automatic
|-
| 3
| 1.6
| Number of transactions
| Automatic
|-
| 4
| 1.7
| Control Sum
| Automatic
|-
| 5
| 1.8
| Identification
| Manual
|-
| 6
| 2.1
| Payment Information Identification
| Manual
|-
| 7
| 2
| Payment Method
| Manual
|-
| 8
| 2.4
| Number of transactions
| Automatic
|-
| 9
| 2.5
| Control Sum
| Automatic
|-
| 10
| 2.9
| Code
| Manual
|-
| 11
| 2.12
| Code
| Manual
|-
| 12
| 2.14
| Sequence Type
| Manual
|-
| 13
| 2.17
| Proprietary
| Manual
|-
| 14
| 2.18
| Requested Collection Date
| Manual
|-
| 15
| 2.19
| Name
| Manual
|-
| 16
| 2.20
| IBAN
| Manual
|-
| 17
| 2.21
| BIC
| Manual
|}

=== Transaction Form Required Fields ===
{| class="wikitable"
|-
! #
! BOI XML Reference
! Information
! Manual or Automatic Data Entry
|-
| 1
| 2.30
| Payment Identification/Instruction Identification
| Manual
|-
| 2
| 2.31
| Payment Identification/End to End Identification
| Manual
|-
| 3
| 2.44
| Instructed Amount
| Manual
|-
| 4
| 2.48
| Mandate Identification
| Manual
|-
| 5
| 2.49
| Date of Signature
| Manual
|-
| 6
| 2.66
| Identification
| Manual
|-
| 7
| 2.66
| Proprietary
| Manual
|-
| 8
| 2.70
| Financial Institution Identification
| Manual
|-
| 9
| 2.72
| Name
| Manual
|-
| 10
| 2.73
| IBAN
| Manual
|}

=== Rule Parameter Explanation ===
{| class="wikitable"
|-
! #
! Example
! Type
! Mandatory
! Description
|-
| 0
| SEPAFileGeneration
| Text
| True
| This tells bxp what rule to execute and must be as specified
|-
| 1
| Header Form Id
| Number
| True
| This tells bxp what form contains the header information
|-
| 2
| Header Record Id
| Number
| True
| This tells bxp what record contains the header information
|-
| 3
| Header form fields
| Text
| True
| This tells bxp the fields that the header information are stored
|-
| 4
| Transaction form Id
| Number
| True
| This tells bxp what form contains the transaction information
|-
| 5
| Transaction form fields
| Text
| True
| This tells bxp the fields that the transaction information are stored
|-
| 6
| Record Status update
| True/False
| True
| This tells bxp to apply a custom status to the records updated
|-
| 7
| Custom Status to apply
| Text
| True
| This is the custom status that will be applied to the records
|-
| 8
| Store in CCL of Record
| True/False
| True
| This tells bxp to store a copy of the XML file in the CCL of the header record
|-
| 9
| Sub folder Location
| Text
| True
| This tells bxp to look in sub folders if specified
|}

=== Example Rule ===

<syntaxhighlight lang="java">
SEPAFileGeneration
[[-SEP-]]1
[[-SEP-]]1
[[-SEP-]]strCDA_1_field_0_1,strCDA_1_field_0_2,..............,strCDA_1_field_0_16,strCDA_1_field_0_17
[[-SEP-]]2
[[-SEP-]]strCDA_2_field_0_1,strCDA_2_field_0_2,..............,strCDA_2_field_0_9,strCDA_2_field_0_10
[[-SEP-]]True
[[-SEP-]]SEPA FILE GENERATION
[[-SEP-]]True
[[-SEP-]]SubFolder1\SubFolder2\SubFolder3
[[-SEP-]]
[[-SEP-]]
[[-SEP-]]
[[-SEP-]]
[[-SEP-]]
[[-SEP-]]
[[-SEP-]]
[[-SEP-]]
</syntaxhighlight>

== SEPA Pain 002 Import==

Reference Document -- [[Media:SEPA_002_LayoutDocument.pdf]]

=== Transaction Form Required Fields ===
{| class="wikitable"
|-
! #
! BOI XML Reference
! Information
|-
| 1
| 1.1
| GrpHdr > MsgId
|-
| 2
| 1.2
| GrpHdr > CreDtTm
|-
| 3
| 1.6
| GrpHdr > CdtrAgt > FinInstnId > BIC
|-
| 4
| 2.1
| OrgnlGrpInfAndSts > OrgnlMsgId
|-
| 5
| 2.2
| OrgnlGrpInfAndSts > OrgnlMsgNmId
|-
| 6
| 2.4
| OrgnlGrpInfAndSts > OrgnlNbOfTxs
|-
| 7
| 2.5
| OrgnlGrpInfAndSts > OrgnlCtrlSum
|-
| 8
| 3.1
| OrgnlPmtInfAndSts > OrgnlPmtInfId
|-
| 9
| 3.2
| OrgnlPmtInfAndSts > OrgnlNbOfTxs
|-
| 10
| 3.3
| OrgnlPmtInfAndSts > OrgnlCtrlSum
|-
| 11
| 3.16
| TxInfAndSts > StsId
|-
| 12
| 3.17
| TxInfAndSts > OrgnlInstrId
|-
| 13
| 3.18
| TxInfAndSts > OrgnlEndToEndId
|-
| 14
| 3.19
| TxInfAndSts > TxSts
|-
| 15
| 3.21
| TxInfAndSts > StsRsnInf > Orgtr > Id > OrgId > BICOrBEI
|-
| 16
| 3.23
| TxInfAndSts > StsRsnInf > Rsn > Cd
|-
| 17
| 3.35
| TxInfAndSts > OrgnlTxRef > Amt > InstdAmt
|-
| 18
| 3.40
| TxInfAndSts > OrgnlTxRef > ReqdColltnDt
|-
| 19
| 3.42
| TxInfAndSts > OrgnlTxRef > CdtrSchmeId > Id > PrvtId > Othr > Id
|-
| 20
| 3.42
| TxInfAndSts > OrgnlTxRef > CdtrSchmeId > Id > PrvtId > Othr > SchmeNm > Prtry
|-
| 21
| 3.59
| TxInfAndSts > OrgnlTxRef > PmtTpInf > SvcLvl > Cd
|-
| 22
| 3.62
| TxInfAndSts > OrgnlTxRef > PmtTpInf > LclInstrm > Cd
|-
| 23
| 3.64
| TxInfAndSts > OrgnlTxRef > PmtTpInf > SeqTp
|-
| 24
| 3.67
| TxInfAndSts > OrgnlTxRef > PmtTpInf > CtgyPurp > Prtry
|-
| 25
| 3.70
| TxInfAndSts > OrgnlTxRef > MndtRltdInf > MndtId
|-
| 26
| 3.71
| TxInfAndSts > OrgnlTxRef > MndtRltdInf > DtOfSgntr
|-
| 27
| 3.72
| TxInfAndSts > OrgnlTxRef > MndtRltdInf > AmdmntInd
|-
| 28
| 3.121
| TxInfAndSts > OrgnlTxRef > Dbtr > Nm
|-
| 29
| 3.122
| TxInfAndSts > OrgnlTxRef > DbtrAcct > Id > IBAN
|-
| 30
| 3.123
| TxInfAndSts > OrgnlTxRef > DbtrAgt > FinInstnId > BIC
|-
| 31
| 3.125
| TxInfAndSts > OrgnlTxRef > CdtrAgt > FinInstnId > BIC
|-
| 32
| 3.127
| TxInfAndSts > OrgnlTxRef > Cdtr > Nm
|-
| 33
| 3.128
| TxInfAndSts > OrgnlTxRef > CdtrAcct > Id > IBAN
|-
|}

=== Example Rule ===
<syntaxhighlight lang="java">
SEPA002FileRead
[[-SEP-]]1
[[-SEP-]]strCDA_1_field_0_1,strCDA_1_field_0_2,..............,strCDA_1_field_0_33,strCDA_1_field_0_34
[[-SEP-]]SubFolder1\SubFolder2\SubFolder3
[[-SEP-]]True
[[-SEP-]]SEPA Rejection
[[-SEP-]]False
[[-SEP-]]
[[-SEP-]]
[[-SEP-]]
[[-SEP-]]
[[-SEP-]]
[[-SEP-]]
</syntaxhighlight>

MetaData - SEPA

2016-09-30T13:34:07Z

Patrick Jenkins:

== MetaData - SEPA Rule ==

bxp has the ability through MetaData, both manual and scheduled to generate a SEPA PAIN 008 file and import to a form a SEPA PAIN 002 Rejection file.

== SEPA Pain 008 Export ==

In order to generate a SEPA Pain 008 file bxp needs two forms, one to store all of the Header information for the file and one that stores the individual transaction data. Both the header form and the transaction form must contain the fields mentioned below.

Once the '''MetaData Process''' Rule has been set up correctly, bxp will cycle through the header and transaction forms taking all of the required data. The MetaData sequence needs to be set up on the transaction form as this controls the transactions to include in the file.

After a success full process bxp will store the SEPA Pain 008 file in the specified MetaData directory and also perform the following options:

1) Store a CCL of the SEPA file generation in all of the transaction records included

2) Store a CCL of the SEPA file generation in the header form record

3) Store a copy of the SEPA file generated in the header form record, once here this copy cannot be modified/deleted (optional action)

[[Media:SEPA_008_LayoutDocument.pdf]]

=== Header Form Required Fields ===
{| class="wikitable"
|-
! #
! BOI XML Reference
! Information
! Manual or Automatic Data Entry
|-
| 1
| 1.1
| Message Information
| Manual
|-
| 2
| 2.2
| Creation Date Time
| Automatic
|-
| 3
| 1.6
| Number of transactions
| Automatic
|-
| 4
| 1.7
| Control Sum
| Automatic
|-
| 5
| 1.8
| Identification
| Manual
|-
| 6
| 2.1
| Payment Information Identification
| Manual
|-
| 7
| 2
| Payment Method
| Manual
|-
| 8
| 2.4
| Number of transactions
| Automatic
|-
| 9
| 2.5
| Control Sum
| Automatic
|-
| 10
| 2.9
| Code
| Manual
|-
| 11
| 2.12
| Code
| Manual
|-
| 12
| 2.14
| Sequence Type
| Manual
|-
| 13
| 2.17
| Proprietary
| Manual
|-
| 14
| 2.18
| Requested Collection Date
| Manual
|-
| 15
| 2.19
| Name
| Manual
|-
| 16
| 2.20
| IBAN
| Manual
|-
| 17
| 2.21
| BIC
| Manual
|}

=== Transaction Form Required Fields ===
{| class="wikitable"
|-
! #
! BOI XML Reference
! Information
! Manual or Automatic Data Entry
|-
| 1
| 2.30
| Payment Identification/Instruction Identification
| Manual
|-
| 2
| 2.31
| Payment Identification/End to End Identification
| Manual
|-
| 3
| 2.44
| Instructed Amount
| Manual
|-
| 4
| 2.48
| Mandate Identification
| Manual
|-
| 5
| 2.49
| Date of Signature
| Manual
|-
| 6
| 2.66
| Identification
| Manual
|-
| 7
| 2.66
| Proprietary
| Manual
|-
| 8
| 2.70
| Financial Institution Identification
| Manual
|-
| 9
| 2.72
| Name
| Manual
|-
| 10
| 2.73
| IBAN
| Manual
|}

=== Rule Parameter Explanation ===
{| class="wikitable"
|-
! #
! Example
! Type
! Mandatory
! Description
|-
| 0
| SEPAFileGeneration
| Text
| True
| This tells bxp what rule to execute and must be as specified
|-
| 1
| Header Form Id
| Number
| True
| This tells bxp what form contains the header information
|-
| 2
| Header Record Id
| Number
| True
| This tells bxp what record contains the header information
|-
| 3
| Header form fields
| Text
| True
| This tells bxp the fields that the header information are stored
|-
| 4
| Transaction form Id
| Number
| True
| This tells bxp what form contains the transaction information
|-
| 5
| Transaction form fields
| Text
| True
| This tells bxp the fields that the transaction information are stored
|-
| 6
| Record Status update
| True/False
| True
| This tells bxp to apply a custom status to the records updated
|-
| 7
| Custom Status to apply
| Text
| True
| This is the custom status that will be applied to the records
|-
| 8
| Store in CCL of Record
| True/False
| True
| This tells bxp to store a copy of the XML file in the CCL of the header record
|-
| 9
| Sub folder Location
| Text
| True
| This tells bxp to look in sub folders if specified
|}

=== Example Rule ===

<syntaxhighlight lang="java">
SEPAFileGeneration
[[-SEP-]]1
[[-SEP-]]1
[[-SEP-]]strCDA_1_field_0_1,strCDA_1_field_0_2,..............,strCDA_1_field_0_16,strCDA_1_field_0_17
[[-SEP-]]2
[[-SEP-]]strCDA_2_field_0_1,strCDA_2_field_0_2,..............,strCDA_2_field_0_9,strCDA_2_field_0_10
[[-SEP-]]True
[[-SEP-]]SEPA FILE GENERATION
[[-SEP-]]True
[[-SEP-]]SubFolder1\SubFolder2\SubFolder3
[[-SEP-]]
[[-SEP-]]
[[-SEP-]]
[[-SEP-]]
[[-SEP-]]
[[-SEP-]]
[[-SEP-]]
[[-SEP-]]
</syntaxhighlight>

== SEPA Pain 002 Import==

[[Media:SEPA_002_LayoutDocument.pdf]]

=== Transaction Form Required Fields ===
{| class="wikitable"
|-
! #
! BOI XML Reference
! Information
|-
| 1
| 1.1
| GrpHdr > MsgId
|-
| 2
| 1.2
| GrpHdr > CreDtTm
|-
| 3
| 1.6
| GrpHdr > CdtrAgt > FinInstnId > BIC
|-
| 4
| 2.1
| OrgnlGrpInfAndSts > OrgnlMsgId
|-
| 5
| 2.2
| OrgnlGrpInfAndSts > OrgnlMsgNmId
|-
| 6
| 2.4
| OrgnlGrpInfAndSts > OrgnlNbOfTxs
|-
| 7
| 2.5
| OrgnlGrpInfAndSts > OrgnlCtrlSum
|-
| 8
| 3.1
| OrgnlPmtInfAndSts > OrgnlPmtInfId
|-
| 9
| 3.2
| OrgnlPmtInfAndSts > OrgnlNbOfTxs
|-
| 10
| 3.3
| OrgnlPmtInfAndSts > OrgnlCtrlSum
|-
| 11
| 3.16
| TxInfAndSts > StsId
|-
| 12
| 3.17
| TxInfAndSts > OrgnlInstrId
|-
| 13
| 3.18
| TxInfAndSts > OrgnlEndToEndId
|-
| 14
| 3.19
| TxInfAndSts > TxSts
|-
| 15
| 3.21
| TxInfAndSts > StsRsnInf > Orgtr > Id > OrgId > BICOrBEI
|-
| 16
| 3.23
| TxInfAndSts > StsRsnInf > Rsn > Cd
|-
| 17
| 3.35
| TxInfAndSts > OrgnlTxRef > Amt > InstdAmt
|-
| 18
| 3.40
| TxInfAndSts > OrgnlTxRef > ReqdColltnDt
|-
| 19
| 3.42
| TxInfAndSts > OrgnlTxRef > CdtrSchmeId > Id > PrvtId > Othr > Id
|-
| 20
| 3.42
| TxInfAndSts > OrgnlTxRef > CdtrSchmeId > Id > PrvtId > Othr > SchmeNm > Prtry
|-
| 21
| 3.59
| TxInfAndSts > OrgnlTxRef > PmtTpInf > SvcLvl > Cd
|-
| 22
| 3.62
| TxInfAndSts > OrgnlTxRef > PmtTpInf > LclInstrm > Cd
|-
| 23
| 3.64
| TxInfAndSts > OrgnlTxRef > PmtTpInf > SeqTp
|-
| 24
| 3.67
| TxInfAndSts > OrgnlTxRef > PmtTpInf > CtgyPurp > Prtry
|-
| 25
| 3.70
| TxInfAndSts > OrgnlTxRef > MndtRltdInf > MndtId
|-
| 26
| 3.71
| TxInfAndSts > OrgnlTxRef > MndtRltdInf > DtOfSgntr
|-
| 27
| 3.72
| TxInfAndSts > OrgnlTxRef > MndtRltdInf > AmdmntInd
|-
| 28
| 3.121
| TxInfAndSts > OrgnlTxRef > Dbtr > Nm
|-
| 29
| 3.122
| TxInfAndSts > OrgnlTxRef > DbtrAcct > Id > IBAN
|-
| 30
| 3.123
| TxInfAndSts > OrgnlTxRef > DbtrAgt > FinInstnId > BIC
|-
| 31
| 3.125
| TxInfAndSts > OrgnlTxRef > CdtrAgt > FinInstnId > BIC
|-
| 32
| 3.127
| TxInfAndSts > OrgnlTxRef > Cdtr > Nm
|-
| 33
| 3.128
| TxInfAndSts > OrgnlTxRef > CdtrAcct > Id > IBAN
|-
|}

=== Example Rule ===
<syntaxhighlight lang="java">
SEPA002FileRead
[[-SEP-]]1
[[-SEP-]]strCDA_1_field_0_1,strCDA_1_field_0_2,..............,strCDA_1_field_0_33,strCDA_1_field_0_34
[[-SEP-]]SubFolder1\SubFolder2\SubFolder3
[[-SEP-]]True
[[-SEP-]]SEPA Rejection
[[-SEP-]]False
[[-SEP-]]
[[-SEP-]]
[[-SEP-]]
[[-SEP-]]
[[-SEP-]]
[[-SEP-]]
</syntaxhighlight>

MetaData - SEPA

2016-09-30T13:33:18Z

Patrick Jenkins:

== MetaData - SEPA Rule ==

bxp has the ability through MetaData, both manual and scheduled to generate a SEPA PAIN 008 file and import to a form a SEPA PAIN 002 Rejection file.

== SEPA Pain 008 Export ==

In order to generate a SEPA Pain 008 file bxp needs two forms, one to store all of the Header information for the file and one that stores the individual transaction data. Both the header form and the transaction form must contain the fields mentioned below.

Once the '''MetaData Process''' Rule has been set up correctly, bxp will cycle through the header and transaction forms taking all of the required data. The MetaData sequence needs to be set up on the transaction form as this controls the transactions to include in the file.

After a success full process bxp will store the SEPA Pain 008 file in the specified MetaData directory and also perform the following options:

1) Store a CCL of the SEPA file generation in all of the transaction records included

2) Store a CCL of the SEPA file generation in the header form record

3) Store a copy of the SEPA file generated in the header form record, once here this copy cannot be modified/deleted (optional action)

[[Media:SEPA_008_LayoutDocument.pdf]]

=== Header Form Required Fields ===
{| class="wikitable"
|-
! #
! BOI XML Reference
! Information
! Manual or Automatic Data Entry
|-
| 1
| 1.1
| Message Information
| Manual
|-
| 2
| 2.2
| Creation Date Time
| Automatic
|-
| 3
| 1.6
| Number of transactions
| Automatic
|-
| 4
| 1.7
| Control Sum
| Automatic
|-
| 5
| 1.8
| Identification
| Manual
|-
| 6
| 2.1
| Payment Information Identification
| Manual
|-
| 7
| 2
| Payment Method
| Manual
|-
| 8
| 2.4
| Number of transactions
| Automatic
|-
| 9
| 2.5
| Control Sum
| Automatic
|-
| 10
| 2.9
| Code
| Manual
|-
| 11
| 2.12
| Code
| Manual
|-
| 12
| 2.14
| Sequence Type
| Manual
|-
| 13
| 2.17
| Proprietary
| Manual
|-
| 14
| 2.18
| Requested Collection Date
| Manual
|-
| 15
| 2.19
| Name
| Manual
|-
| 16
| 2.20
| IBAN
| Manual
|-
| 17
| 2.21
| BIC
| Manual
|}

=== Transaction Form Required Fields ===
{| class="wikitable"
|-
! #
! BOI XML Reference
! Information
! Manual or Automatic Data Entry
|-
| 1
| 2.30
| Payment Identification/Instruction Identification
| Manual
|-
| 2
| 2.31
| Payment Identification/End to End Identification
| Manual
|-
| 3
| 2.44
| Instructed Amount
| Manual
|-
| 4
| 2.48
| Mandate Identification
| Manual
|-
| 5
| 2.49
| Date of Signature
| Manual
|-
| 6
| 2.66
| Identification
| Manual
|-
| 7
| 2.66
| Proprietary
| Manual
|-
| 8
| 2.70
| Financial Institution Identification
| Manual
|-
| 9
| 2.72
| Name
| Manual
|-
| 10
| 2.73
| IBAN
| Manual
|}

=== Rule Parameter Explanation ===
{| class="wikitable"
|-
! #
! Example
! Type
! Mandatory
! Description
|-
| 0
| SEPAFileGeneration
| Text
| True
| This tells bxp what rule to execute and must be as specified
|-
| 1
| Header Form Id
| Number
| True
| This tells bxp what form contains the header information
|-
| 2
| Header Record Id
| Number
| True
| This tells bxp what record contains the header information
|-
| 3
| Header form fields
| Text
| True
| This tells bxp the fields that the header information are stored
|-
| 4
| Transaction form Id
| Number
| True
| This tells bxp what form contains the transaction information
|-
| 5
| Transaction form fields
| Text
| True
| This tells bxp the fields that the transaction information are stored
|-
| 6
| Record Status update
| True/False
| True
| This tells bxp to apply a custom status to the records updated
|-
| 7
| Custom Status to apply
| Text
| True
| This is the custom status that will be applied to the records
|-
| 8
| Store in CCL of Record
| True/False
| True
| This tells bxp to store a copy of the XML file in the CCL of the header record
|-
| 9
| Sub folder Location
| Text
| True
| This tells bxp to look in sub folders if specified
|}

=== Example Rule ===

[[Media:SEPA_002_LayoutDocument.pdf]]

<syntaxhighlight lang="java">
SEPAFileGeneration
[[-SEP-]]1
[[-SEP-]]1
[[-SEP-]]strCDA_1_field_0_1,strCDA_1_field_0_2,..............,strCDA_1_field_0_16,strCDA_1_field_0_17
[[-SEP-]]2
[[-SEP-]]strCDA_2_field_0_1,strCDA_2_field_0_2,..............,strCDA_2_field_0_9,strCDA_2_field_0_10
[[-SEP-]]True
[[-SEP-]]SEPA FILE GENERATION
[[-SEP-]]True
[[-SEP-]]SubFolder1\SubFolder2\SubFolder3
[[-SEP-]]
[[-SEP-]]
[[-SEP-]]
[[-SEP-]]
[[-SEP-]]
[[-SEP-]]
[[-SEP-]]
[[-SEP-]]
</syntaxhighlight>

== SEPA Pain 002 Import==

=== Transaction Form Required Fields ===
{| class="wikitable"
|-
! #
! BOI XML Reference
! Information
|-
| 1
| 1.1
| GrpHdr > MsgId
|-
| 2
| 1.2
| GrpHdr > CreDtTm
|-
| 3
| 1.6
| GrpHdr > CdtrAgt > FinInstnId > BIC
|-
| 4
| 2.1
| OrgnlGrpInfAndSts > OrgnlMsgId
|-
| 5
| 2.2
| OrgnlGrpInfAndSts > OrgnlMsgNmId
|-
| 6
| 2.4
| OrgnlGrpInfAndSts > OrgnlNbOfTxs
|-
| 7
| 2.5
| OrgnlGrpInfAndSts > OrgnlCtrlSum
|-
| 8
| 3.1
| OrgnlPmtInfAndSts > OrgnlPmtInfId
|-
| 9
| 3.2
| OrgnlPmtInfAndSts > OrgnlNbOfTxs
|-
| 10
| 3.3
| OrgnlPmtInfAndSts > OrgnlCtrlSum
|-
| 11
| 3.16
| TxInfAndSts > StsId
|-
| 12
| 3.17
| TxInfAndSts > OrgnlInstrId
|-
| 13
| 3.18
| TxInfAndSts > OrgnlEndToEndId
|-
| 14
| 3.19
| TxInfAndSts > TxSts
|-
| 15
| 3.21
| TxInfAndSts > StsRsnInf > Orgtr > Id > OrgId > BICOrBEI
|-
| 16
| 3.23
| TxInfAndSts > StsRsnInf > Rsn > Cd
|-
| 17
| 3.35
| TxInfAndSts > OrgnlTxRef > Amt > InstdAmt
|-
| 18
| 3.40
| TxInfAndSts > OrgnlTxRef > ReqdColltnDt
|-
| 19
| 3.42
| TxInfAndSts > OrgnlTxRef > CdtrSchmeId > Id > PrvtId > Othr > Id
|-
| 20
| 3.42
| TxInfAndSts > OrgnlTxRef > CdtrSchmeId > Id > PrvtId > Othr > SchmeNm > Prtry
|-
| 21
| 3.59
| TxInfAndSts > OrgnlTxRef > PmtTpInf > SvcLvl > Cd
|-
| 22
| 3.62
| TxInfAndSts > OrgnlTxRef > PmtTpInf > LclInstrm > Cd
|-
| 23
| 3.64
| TxInfAndSts > OrgnlTxRef > PmtTpInf > SeqTp
|-
| 24
| 3.67
| TxInfAndSts > OrgnlTxRef > PmtTpInf > CtgyPurp > Prtry
|-
| 25
| 3.70
| TxInfAndSts > OrgnlTxRef > MndtRltdInf > MndtId
|-
| 26
| 3.71
| TxInfAndSts > OrgnlTxRef > MndtRltdInf > DtOfSgntr
|-
| 27
| 3.72
| TxInfAndSts > OrgnlTxRef > MndtRltdInf > AmdmntInd
|-
| 28
| 3.121
| TxInfAndSts > OrgnlTxRef > Dbtr > Nm
|-
| 29
| 3.122
| TxInfAndSts > OrgnlTxRef > DbtrAcct > Id > IBAN
|-
| 30
| 3.123
| TxInfAndSts > OrgnlTxRef > DbtrAgt > FinInstnId > BIC
|-
| 31
| 3.125
| TxInfAndSts > OrgnlTxRef > CdtrAgt > FinInstnId > BIC
|-
| 32
| 3.127
| TxInfAndSts > OrgnlTxRef > Cdtr > Nm
|-
| 33
| 3.128
| TxInfAndSts > OrgnlTxRef > CdtrAcct > Id > IBAN
|-
|}

=== Example Rule ===
<syntaxhighlight lang="java">
SEPA002FileRead
[[-SEP-]]1
[[-SEP-]]strCDA_1_field_0_1,strCDA_1_field_0_2,..............,strCDA_1_field_0_33,strCDA_1_field_0_34
[[-SEP-]]SubFolder1\SubFolder2\SubFolder3
[[-SEP-]]True
[[-SEP-]]SEPA Rejection
[[-SEP-]]False
[[-SEP-]]
[[-SEP-]]
[[-SEP-]]
[[-SEP-]]
[[-SEP-]]
[[-SEP-]]
</syntaxhighlight>

File:SEPA 008 LayoutDocument.pdf

2016-09-30T13:32:55Z

Patrick Jenkins:

File:SEPA 002 LayoutDocument.pdf

2016-09-30T13:28:47Z

Patrick Jenkins:

MetaData - SEPA

2016-09-30T13:24:27Z

Patrick Jenkins:

== MetaData - SEPA Rule ==

bxp has the ability through MetaData, both manual and scheduled to generate a SEPA PAIN 008 file and import to a form a SEPA PAIN 002 Rejection file.

== SEPA Pain 008 Export ==

In order to generate a SEPA Pain 008 file bxp needs two forms, one to store all of the Header information for the file and one that stores the individual transaction data. Both the header form and the transaction form must contain the fields mentioned below.

Once the '''MetaData Process''' Rule has been set up correctly, bxp will cycle through the header and transaction forms taking all of the required data. The MetaData sequence needs to be set up on the transaction form as this controls the transactions to include in the file.

After a success full process bxp will store the SEPA Pain 008 file in the specified MetaData directory and also perform the following options:

1) Store a CCL of the SEPA file generation in all of the transaction records included

2) Store a CCL of the SEPA file generation in the header form record

3) Store a copy of the SEPA file generated in the header form record, once here this copy cannot be modified/deleted (optional action)

=== Header Form Required Fields ===
{| class="wikitable"
|-
! #
! BOI XML Reference
! Information
! Manual or Automatic Data Entry
|-
| 1
| 1.1
| Message Information
| Manual
|-
| 2
| 2.2
| Creation Date Time
| Automatic
|-
| 3
| 1.6
| Number of transactions
| Automatic
|-
| 4
| 1.7
| Control Sum
| Automatic
|-
| 5
| 1.8
| Identification
| Manual
|-
| 6
| 2.1
| Payment Information Identification
| Manual
|-
| 7
| 2
| Payment Method
| Manual
|-
| 8
| 2.4
| Number of transactions
| Automatic
|-
| 9
| 2.5
| Control Sum
| Automatic
|-
| 10
| 2.9
| Code
| Manual
|-
| 11
| 2.12
| Code
| Manual
|-
| 12
| 2.14
| Sequence Type
| Manual
|-
| 13
| 2.17
| Proprietary
| Manual
|-
| 14
| 2.18
| Requested Collection Date
| Manual
|-
| 15
| 2.19
| Name
| Manual
|-
| 16
| 2.20
| IBAN
| Manual
|-
| 17
| 2.21
| BIC
| Manual
|}

=== Transaction Form Required Fields ===
{| class="wikitable"
|-
! #
! BOI XML Reference
! Information
! Manual or Automatic Data Entry
|-
| 1
| 2.30
| Payment Identification/Instruction Identification
| Manual
|-
| 2
| 2.31
| Payment Identification/End to End Identification
| Manual
|-
| 3
| 2.44
| Instructed Amount
| Manual
|-
| 4
| 2.48
| Mandate Identification
| Manual
|-
| 5
| 2.49
| Date of Signature
| Manual
|-
| 6
| 2.66
| Identification
| Manual
|-
| 7
| 2.66
| Proprietary
| Manual
|-
| 8
| 2.70
| Financial Institution Identification
| Manual
|-
| 9
| 2.72
| Name
| Manual
|-
| 10
| 2.73
| IBAN
| Manual
|}

=== Rule Parameter Explanation ===
{| class="wikitable"
|-
! #
! Example
! Type
! Mandatory
! Description
|-
| 0
| SEPAFileGeneration
| Text
| True
| This tells bxp what rule to execute and must be as specified
|-
| 1
| Header Form Id
| Number
| True
| This tells bxp what form contains the header information
|-
| 2
| Header Record Id
| Number
| True
| This tells bxp what record contains the header information
|-
| 3
| Header form fields
| Text
| True
| This tells bxp the fields that the header information are stored
|-
| 4
| Transaction form Id
| Number
| True
| This tells bxp what form contains the transaction information
|-
| 5
| Transaction form fields
| Text
| True
| This tells bxp the fields that the transaction information are stored
|-
| 6
| Record Status update
| True/False
| True
| This tells bxp to apply a custom status to the records updated
|-
| 7
| Custom Status to apply
| Text
| True
| This is the custom status that will be applied to the records
|-
| 8
| Store in CCL of Record
| True/False
| True
| This tells bxp to store a copy of the XML file in the CCL of the header record
|-
| 9
| Sub folder Location
| Text
| True
| This tells bxp to look in sub folders if specified
|}

=== Example Rule ===
<syntaxhighlight lang="java">
SEPAFileGeneration
[[-SEP-]]1
[[-SEP-]]1
[[-SEP-]]strCDA_1_field_0_1,strCDA_1_field_0_2,..............,strCDA_1_field_0_16,strCDA_1_field_0_17
[[-SEP-]]2
[[-SEP-]]strCDA_2_field_0_1,strCDA_2_field_0_2,..............,strCDA_2_field_0_9,strCDA_2_field_0_10
[[-SEP-]]True
[[-SEP-]]SEPA FILE GENERATION
[[-SEP-]]True
[[-SEP-]]SubFolder1\SubFolder2\SubFolder3
[[-SEP-]]
[[-SEP-]]
[[-SEP-]]
[[-SEP-]]
[[-SEP-]]
[[-SEP-]]
[[-SEP-]]
[[-SEP-]]
</syntaxhighlight>

== SEPA Pain 002 Import==

=== Transaction Form Required Fields ===
{| class="wikitable"
|-
! #
! BOI XML Reference
! Information
|-
| 1
| 1.1
| GrpHdr > MsgId
|-
| 2
| 1.2
| GrpHdr > CreDtTm
|-
| 3
| 1.6
| GrpHdr > CdtrAgt > FinInstnId > BIC
|-
| 4
| 2.1
| OrgnlGrpInfAndSts > OrgnlMsgId
|-
| 5
| 2.2
| OrgnlGrpInfAndSts > OrgnlMsgNmId
|-
| 6
| 2.4
| OrgnlGrpInfAndSts > OrgnlNbOfTxs
|-
| 7
| 2.5
| OrgnlGrpInfAndSts > OrgnlCtrlSum
|-
| 8
| 3.1
| OrgnlPmtInfAndSts > OrgnlPmtInfId
|-
| 9
| 3.2
| OrgnlPmtInfAndSts > OrgnlNbOfTxs
|-
| 10
| 3.3
| OrgnlPmtInfAndSts > OrgnlCtrlSum
|-
| 11
| 3.16
| TxInfAndSts > StsId
|-
| 12
| 3.17
| TxInfAndSts > OrgnlInstrId
|-
| 13
| 3.18
| TxInfAndSts > OrgnlEndToEndId
|-
| 14
| 3.19
| TxInfAndSts > TxSts
|-
| 15
| 3.21
| TxInfAndSts > StsRsnInf > Orgtr > Id > OrgId > BICOrBEI
|-
| 16
| 3.23
| TxInfAndSts > StsRsnInf > Rsn > Cd
|-
| 17
| 3.35
| TxInfAndSts > OrgnlTxRef > Amt > InstdAmt
|-
| 18
| 3.40
| TxInfAndSts > OrgnlTxRef > ReqdColltnDt
|-
| 19
| 3.42
| TxInfAndSts > OrgnlTxRef > CdtrSchmeId > Id > PrvtId > Othr > Id
|-
| 20
| 3.42
| TxInfAndSts > OrgnlTxRef > CdtrSchmeId > Id > PrvtId > Othr > SchmeNm > Prtry
|-
| 21
| 3.59
| TxInfAndSts > OrgnlTxRef > PmtTpInf > SvcLvl > Cd
|-
| 22
| 3.62
| TxInfAndSts > OrgnlTxRef > PmtTpInf > LclInstrm > Cd
|-
| 23
| 3.64
| TxInfAndSts > OrgnlTxRef > PmtTpInf > SeqTp
|-
| 24
| 3.67
| TxInfAndSts > OrgnlTxRef > PmtTpInf > CtgyPurp > Prtry
|-
| 25
| 3.70
| TxInfAndSts > OrgnlTxRef > MndtRltdInf > MndtId
|-
| 26
| 3.71
| TxInfAndSts > OrgnlTxRef > MndtRltdInf > DtOfSgntr
|-
| 27
| 3.72
| TxInfAndSts > OrgnlTxRef > MndtRltdInf > AmdmntInd
|-
| 28
| 3.121
| TxInfAndSts > OrgnlTxRef > Dbtr > Nm
|-
| 29
| 3.122
| TxInfAndSts > OrgnlTxRef > DbtrAcct > Id > IBAN
|-
| 30
| 3.123
| TxInfAndSts > OrgnlTxRef > DbtrAgt > FinInstnId > BIC
|-
| 31
| 3.125
| TxInfAndSts > OrgnlTxRef > CdtrAgt > FinInstnId > BIC
|-
| 32
| 3.127
| TxInfAndSts > OrgnlTxRef > Cdtr > Nm
|-
| 33
| 3.128
| TxInfAndSts > OrgnlTxRef > CdtrAcct > Id > IBAN
|-
|}

=== Example Rule ===
<syntaxhighlight lang="java">
SEPA002FileRead
[[-SEP-]]1
[[-SEP-]]strCDA_1_field_0_1,strCDA_1_field_0_2,..............,strCDA_1_field_0_33,strCDA_1_field_0_34
[[-SEP-]]SubFolder1\SubFolder2\SubFolder3
[[-SEP-]]True
[[-SEP-]]SEPA Rejection
[[-SEP-]]False
[[-SEP-]]
[[-SEP-]]
[[-SEP-]]
[[-SEP-]]
[[-SEP-]]
[[-SEP-]]
</syntaxhighlight>

MetaData - SEPA

2016-09-30T13:10:39Z

Patrick Jenkins:

== MetaData - SEPA Rule ==

bxp has the ability through MetaData, both manual and scheduled to generate a SEPA PAIN 008 file and import to a form a SEPA PAIN 002 Rejection file.

== SEPA Pain 008 Export ==

In order to generate a SEPA Pain 008 file bxp needs two forms, one to store all of the Header information for the file and one that stores the individual transaction data. Both the header form and the transaction form must contain the fields mentioned below.

Once the '''MetaData Process''' Rule has been set up correctly, bxp will cycle through the header and transaction forms taking all of the required data. The MetaData sequence needs to be set up on the transaction form as this controls the transactions to include in the file.

After a success full process bxp will store the SEPA Pain 008 file in the specified MetaData directory and also perform the following options:

1) Store a CCL of the SEPA file generation in all of the transaction records included

2) Store a CCL of the SEPA file generation in the header form record

3) Store a copy of the SEPA file generated in the header form record, once here this copy cannot be modified/deleted (optional action)

=== Header Form Required Fields ===
{| class="wikitable"
|-
! #
! BOI XML Reference
! Information
! Manual or Automatic Data Entry
|-
| 1
| 1.1
| Message Information
| Manual
|-
| 2
| 2.2
| Creation Date Time
| Automatic
|-
| 3
| 1.6
| Number of transactions
| Automatic
|-
| 4
| 1.7
| Control Sum
| Automatic
|-
| 5
| 1.8
| Identification
| Manual
|-
| 6
| 2.1
| Payment Information Identification
| Manual
|-
| 7
| 2
| Payment Method
| Manual
|-
| 8
| 2.4
| Number of transactions
| Automatic
|-
| 9
| 2.5
| Control Sum
| Automatic
|-
| 10
| 2.9
| Code
| Manual
|-
| 11
| 2.12
| Code
| Manual
|-
| 12
| 2.14
| Sequence Type
| Manual
|-
| 13
| 2.17
| Proprietary
| Manual
|-
| 14
| 2.18
| Requested Collection Date
| Manual
|-
| 15
| 2.19
| Name
| Manual
|-
| 16
| 2.20
| IBAN
| Manual
|-
| 17
| 2.21
| BIC
| Manual
|}

=== Transaction Form Required Fields ===
{| class="wikitable"
|-
! #
! BOI XML Reference
! Information
! Manual or Automatic Data Entry
|-
| 1
| 2.30
| Payment Identification/Instruction Identification
| Manual
|-
| 2
| 2.31
| Payment Identification/End to End Identification
| Manual
|-
| 3
| 2.44
| Instructed Amount
| Manual
|-
| 4
| 2.48
| Mandate Identification
| Manual
|-
| 5
| 2.49
| Date of Signature
| Manual
|-
| 6
| 2.66
| Identification
| Manual
|-
| 7
| 2.66
| Proprietary
| Manual
|-
| 8
| 2.70
| Financial Institution Identification
| Manual
|-
| 9
| 2.72
| Name
| Manual
|-
| 10
| 2.73
| IBAN
| Manual
|}

=== Rule Parameter Explanation ===
{| class="wikitable"
|-
! #
! Example
! Type
! Mandatory
! Description
|-
| 0
| SEPAFileGeneration
| Text
| True
| This tells bxp what rule to execute and must be as specified
|-
| 1
| Header Form Id
| Number
| True
| This tells bxp what form contains the header information
|-
| 2
| Header Record Id
| Number
| True
| This tells bxp what record contains the header information
|-
| 3
| Header form fields
| Text
| True
| This tells bxp the fields that the header information are stored
|-
| 4
| Transaction form Id
| Number
| True
| This tells bxp what form contains the transaction information
|-
| 5
| Transaction form fields
| Text
| True
| This tells bxp the fields that the transaction information are stored
|-
| 6
| Record Status update
| True/False
| True
| This tells bxp to apply a custom status to the records updated
|-
| 7
| Custom Status to apply
| Text
| True
| This is the custom status that will be applied to the records
|-
| 8
| Store in CCL of Record
| True/False
| True
| This tells bxp to store a copy of the XML file in the CCL of the header record
|-
| 9
| Sub folder Location
| Text
| True
| This tells bxp to look in sub folders if specified
|}

=== Example Rule ===
<syntaxhighlight lang="java">
SEPAFileGeneration
[[-SEP-]]1
[[-SEP-]]1
[[-SEP-]]strCDA_1_field_0_1,strCDA_1_field_0_2,..............,strCDA_1_field_0_16,strCDA_1_field_0_17
[[-SEP-]]2
[[-SEP-]]strCDA_2_field_0_1,strCDA_2_field_0_2,..............,strCDA_2_field_0_9,strCDA_2_field_0_10
[[-SEP-]]True
[[-SEP-]]SEPA FILE GENERATION
[[-SEP-]]True
[[-SEP-]]SubFolder1\SubFolder2\SubFolder3
[[-SEP-]]
[[-SEP-]]
[[-SEP-]]
[[-SEP-]]
[[-SEP-]]
[[-SEP-]]
[[-SEP-]]
[[-SEP-]]
</syntaxhighlight>

== SEPA Pain 002 Import==

=== Transaction Form Required Fields ===
{| class="wikitable"
|-
! #
! BOI XML Reference
! Information
|-
| 1
|
| GrpHdr > MsgId
|-
| 2
|
| GrpHdr > CreDtTm
|-
| 3
|
| GrpHdr > CdtrAgt > FinInstnId > BIC
|-
| 4
|
| OrgnlGrpInfAndSts > OrgnlMsgId
|-
| 5
|
| OrgnlGrpInfAndSts > OrgnlMsgNmId
|-
| 6
|
| OrgnlGrpInfAndSts > OrgnlNbOfTxs
|-
| 7
|
| OrgnlGrpInfAndSts > OrgnlCtrlSum
|-
| 8
|
| OrgnlPmtInfAndSts > OrgnlPmtInfId
|-
| 9
|
| OrgnlPmtInfAndSts > OrgnlNbOfTxs
|-
| 10
|
| OrgnlPmtInfAndSts > OrgnlCtrlSum
|-
| 11
|
| TxInfAndSts > StsId
|-
| 12
|
| TxInfAndSts > OrgnlInstrId
|-
| 13
|
| TxInfAndSts > OrgnlEndToEndId
|-
| 14
|
| TxInfAndSts > TxSts
|-
| 15
|
| TxInfAndSts > StsRsnInf > Orgtr > Id > OrgId > BICOrBEI
|-
| 16
|
| TxInfAndSts > StsRsnInf > Rsn > Cd
|-
| 17
|
| TxInfAndSts > OrgnlTxRef > Amt > InstdAmt
|-
| 18
|
| TxInfAndSts > OrgnlTxRef > ReqdColltnDt
|-
| 19
|
| TxInfAndSts > OrgnlTxRef > CdtrSchmeId > Id > PrvtId > Othr > Id
|-
| 20
|
| TxInfAndSts > OrgnlTxRef > CdtrSchmeId > Id > PrvtId > Othr > SchmeNm > Prtry
|-
| 21
|
| TxInfAndSts > OrgnlTxRef > PmtTpInf > SvcLvl > Cd
|-
| 22
|
| TxInfAndSts > OrgnlTxRef > PmtTpInf > LclInstrm > Cd
|-
| 23
|
| TxInfAndSts > OrgnlTxRef > PmtTpInf > SeqTp
|-
| 24
|
| TxInfAndSts > OrgnlTxRef > PmtTpInf > CtgyPurp > Prtry
|-
| 25
|
| TxInfAndSts > OrgnlTxRef > MndtRltdInf > MndtId
|-
| 26
|
| TxInfAndSts > OrgnlTxRef > MndtRltdInf > DtOfSgntr
|-
| 27
|
| TxInfAndSts > OrgnlTxRef > MndtRltdInf > AmdmntInd
|-
| 28
|
| TxInfAndSts > OrgnlTxRef > Dbtr > Nm
|-
| 29
|
| TxInfAndSts > OrgnlTxRef > DbtrAcct > Id > IBAN
|-
| 30
|
| TxInfAndSts > OrgnlTxRef > DbtrAgt > FinInstnId > BIC
|-
| 31
|
| TxInfAndSts > OrgnlTxRef > CdtrAgt > FinInstnId > BIC
|-
| 32
|
| TxInfAndSts > OrgnlTxRef > Cdtr > Nm
|-
| 33
|
| TxInfAndSts > OrgnlTxRef > CdtrAcct > Id > IBAN
|-
|}

=== Example Rule ===
<syntaxhighlight lang="java">
SEPA002FileRead
[[-SEP-]]1
[[-SEP-]]strCDA_1_field_0_1,strCDA_1_field_0_2,..............,strCDA_1_field_0_33,strCDA_1_field_0_34
[[-SEP-]]SubFolder1\SubFolder2\SubFolder3
[[-SEP-]]True
[[-SEP-]]SEPA Rejection
[[-SEP-]]False
[[-SEP-]]
[[-SEP-]]
[[-SEP-]]
[[-SEP-]]
[[-SEP-]]
[[-SEP-]]
</syntaxhighlight>

MetaData - SEPA

2016-09-30T12:45:55Z

Patrick Jenkins:

MetaData - SEPA

2016-09-30T12:22:30Z

Patrick Jenkins: /* Example Rule */

MetaData - SEPA

2016-09-30T12:22:12Z

Patrick Jenkins: /* Example Rule */

MetaData - SEPA

2016-09-30T12:21:25Z

Patrick Jenkins:

MetaData - SEPA

2016-09-30T12:18:42Z

Patrick Jenkins: Created page with " == MetaData - SEPA Rule == bxp has the ability through MetaData, both manual and scheduled to generate a SEPA PAIN 008 file and import to a form a SEPA PAIN 002 Rejection fi..."

AJAX - Function - LiveSearchKeyStatData

2016-08-31T07:42:55Z

Patrick Jenkins: /* Code */

= Primary Function =

= Example uses =

*
*

= Code =

<syntaxhighlight lang="javascript">

/******************************************************************************************************
Application: This function ............
Version [1.0] Date [2016-08-29] Author [PJ]
******************************************************************************************************/
function fn_FunctionName(){
if (typeof aryAjax_Settings=='undefined') { alert('Library did not load'); }
else {
// Clear all settings
fn_Ajax_bxp_ResetSettings();

// Security Settings
aryAjax_Settings[0] = 'client_demo';
aryAjax_Settings[22] = document.getElementById('intSystemGenerated_CompanyId').value; //Auto Login - System
aryAjax_Settings[23] = document.getElementById('intSystemGenerated_UserId').value; //Auto Login - User
aryAjax_Settings[24] = document.getElementById('intSystemGenerated_LoginKey').value; //Auto Login - SessionId

// Retrieval Settings
aryAjax_Settings[16] = 'LiveSearchKeyStatData'; //Engine to use
aryAjax_Settings[3] = 1; //The form with the data
aryAjax_Settings[4] = 'strCDA_1_field_0_0'; //The field to search on
aryAjax_Settings[5] = document.getElementById('strCDA_2_field_0_0').value; //The value to limit by
aryAjax_Settings[13] = '-1' //Limit response
aryAjax_Settings[40] = "500"; //Retrieval limit if applicable

//Error management
aryAjax_Settings[15] = 'strCDA_3_field_0_25'; //The id of the destination to which the matching data will be inserted

//Common Functional settings
aryAjax_Settings[6] = 'intCDA_1_Id,strCDA_1_field_0_1'; //The field in the other campaign to be returned order = value, text
aryAjax_Settings[12] = 'id,Name of cust'; //Headings for xml troubleshooting
aryAjax_Settings[17] = aryAjax_Settings[6]; //Tneeds to always be the same as array position [6[]
aryAjax_Settings[28] = ''; //Function to be executed after retrieval

//Function specific settings
//...

//Execute
fn_Ajax_bxp_Process(); //The main execution of the AJAX

//Write URL out (Comment out after testing)
if (document.getElementById('divURL')){
document.getElementById('divURL').innerHTML = "<a href='" + aryAjax_Settings[7] + "' target='_blank'>Constructed AJAX URL</a>";
}
}
}

</syntaxhighlight>

= Troubleshooting =

For any errors messages and troubleshooting AJAX please read here [[AJAX_-_Error_messages_and_troubleshooting]]

= Associated reading =

For all our custom AJAX functions please read here [[AJAX_-_Start_Here]]

For the full array of all possible parameters please read here [[AJAX_-_Full_Array_of_Parameters]]

For how the security engine of AJAX works [[AJAX_-_Security_engine]]

[[Category:Topic:JavaScript]]
[[Category:Topic:AJAX]]

Basic – AJAX – Child Form Mgt

2016-08-30T09:38:58Z

Patrick Jenkins:

= Overview =

Bxp allows for a user when creating or modifying a form to add a question type which allows for the Adding/Updating and Deletion of records in a child database. This Question type is called “Basic – AJAX – Child Form Mgt”.

= Question Settings =

* '''Child Form Id'''
** This is simply the ID of the child form in bxp

* '''Field that store parent link'''
** This is the filed in the child form that contains the intCDA_X_Id of the parent from record i.e. the foreign key
** ''Example -'' strCDA_2_field_0_0

* '''Custom Table CSS'''
** This allows the user to apply their own custom CSS to the DIV that the rendered AJAX table is in. If no custom CSS is required simply add NULL to this option

* '''Fields to render in Data Table'''
** This should be the fields from the child form that you require to be included in the data table, each field should be separated by a | symbol
** ''Example -'' strCDA_2_field_0_1|strCDA_2_field_0_2|strCDA_2_field_0_3

* '''Fields to Insert/Update'''
** This should contain the fields in the child form that will be inserted to and updated, each field should be separated by a | symbol
** ''Example -'' strCDA_2_field_0_1|strCDA_2_field_0_2|strCDA_2_field_0_3|strCDA_2_field_0_4

* '''Management Interface Question headings'''
** This should be the headings that you want to assign to the questions when the Addition/Update interface is displayed on screen, each field should be separated by a | symbol
** ''Example –'' First Name|Surname|D.O.B|Phone Number

* '''Data Table Column Headings'''
** This should be the headings that you want to apply to each column in the data table, each field should be separated by a | symbol
** ''Example –'' First Name|Surname|D.O.B

* '''Management Interface Question types'''
** This should be the types of questions that you want to apply to the Addition/Update interface, each field should be separated by a | symbol
** The following are the allowed question types
*** Text – will render a text box
*** Date – will render a date box
*** Datetime – will render a date time box
*** Yesno – will render a Yes/No drop down list
*** Truefalse – will render a True/False drop down list
*** Number[x] – will render a number list drop down list – replace X with the number to stop at i.e. x=50 will give you a number list of 1-50
*** Custom[x] – will render a custom drop down list of answer values in a child form question – replace x with the strCDA_X_field_X_X of the question you want to get the answer values for.

[[File:ChildMgt_Settings.png|900px]]

= Operation =

== Data Table No Child Records Present ==

[[File:ChildMgt_NoRecords.png|900px]]

== Data Table Child Records Present ==

[[File:ChildMgt_ChildRecords.png|900px]]

== Add a new child record ==

[[File:ChildMgt_AddRecord.png|900px]]

== Update/Delete an existing child record ==

[[File:ChildMgt_ManageRecord.png|900px]]

File:ChildMgt ManageRecord.png

2016-08-30T09:34:51Z

Patrick Jenkins:

File:ChildMgt ChildRecords.png

2016-08-30T09:34:17Z

Patrick Jenkins:

File:ChildMgt AddRecord.png

2016-08-30T09:31:42Z

Patrick Jenkins:

File:ChildMgt NoRecords.png

2016-08-30T09:29:12Z

Patrick Jenkins:

File:ChildMgt Settings.png

2016-08-30T09:25:14Z

Patrick Jenkins:

Basic – AJAX – Child Form Mgt

2016-08-30T09:23:47Z

Patrick Jenkins: Created page with " == Overview == Bxp allows for a user when creating or modifying a form to add a question type which allows for the Adding/Updating and Deletion of records in a child databas..."

== Overview ==

Bxp allows for a user when creating or modifying a form to add a question type which allows for the Adding/Updating and Deletion of records in a child database. This Question type is called “Basic – AJAX – Child Form Mgt”.

== Question Settings ==

* '''Child Form Id'''
** This is simply the ID of the child form in bxp
* '''Field that store parent link'''
** This is the filed in the child form that contains the intCDA_X_Id of the parent from record i.e. the foreign key
** ''Example -'' strCDA_2_field_0_0
* '''Custom Table CSS'''
** This allows the user to apply their own custom CSS to the DIV that the rendered AJAX table is in. If no custom CSS is required simply add NULL to this option
* '''Fields to render in Data Table'''
** This should be the fields from the child form that you require to be included in the data table, each field should be separated by a | symbol
** ''Example -'' strCDA_2_field_0_1|strCDA_2_field_0_2|strCDA_2_field_0_3
* '''Fields to Insert/Update'''
** This should contain the fields in the child form that will be inserted to and updated, each field should be separated by a | symbol
** ''Example -'' strCDA_2_field_0_1|strCDA_2_field_0_2|strCDA_2_field_0_3|strCDA_2_field_0_4
* '''Management Interface Question headings'''
** This should be the headings that you want to assign to the questions when the Addition/Update interface is displayed on screen, each field should be separated by a | symbol
** ''Example –'' First Name|Surname|D.O.B|Phone Number
* '''Data Table Column Headings'''
** This should be the headings that you want to apply to each column in the data table, each field should be separated by a | symbol
** ''Example –'' First Name|Surname|D.O.B
* '''Management Interface Question types'''
** This should be the types of questions that you want to apply to the Addition/Update interface, each field should be separated by a | symbol
** The following are the allowed question types
*** Text – will render a text box
*** Date – will render a date box
*** Datetime – will render a date time box
*** Yesno – will render a Yes/No drop down list
*** Truefalse – will render a True/False drop down list
*** Number[x] – will render a number list drop down list – replace X with the number to stop at i.e. x=50 will give you a number list of 1-50
*** Custom[x] – will render a custom drop down list of answer values in a child form question – replace x with the strCDA_X_field_X_X of the question you want to get the answer values for.

In Browser Signature Capture

2016-08-08T08:04:17Z

Patrick Jenkins: /* Set up */

== Overview ==

bxp now has the ability to allow for in browser signature capture on bxp templates, and also trigger an automatic download of a PDF document containing the signature that was captured.

Please note that older browsers may not be able to render the signature capture tool, but this has been tested as far back as Android 3.0 (honeycomb)

== Set up ==

In order to enable the signature capture option on a bxp template you must first set the ''Enable Signature Capture'' setting to ''True''.

[[File:bxpSig_Template.png|none]]

Once this is set to ''True'' bxp will know to render the ''Capture Signature on PDF'' after the user has saved a record to the database. When creating your bxp template you have two changes that you will need to add to your bxp template, these two changes are to show were to render the signature captured and the data and time of the signature.

In your template simply add ''--bxp_Signature_Capture--'', to wherever you want the signature captured to render. The next replacement you have is ''--bxp_Signature_Capture_DateTime--'', simply add this to wherever you want the date and time of the signature to render.

== In Template Replacements ==

'''--bxp_Signature_Capture--''' = This will be replaced with the first signature captured

'''--bxp_Signature_Capture_DateTime--''' = This will be replaced with the date and time that the first signature was captured

'''--bxp_Signature_Capture_Add1--''' = This will be replaced with the second signature captured

'''--bxp_Signature_Capture_DateTime_Add1--''' = This will be replaced with the date and time that the second signature was captured

'''--bxp_Signature_Capture_Add2--''' = This will be replaced with the third signature captured

'''--bxp_Signature_Capture_DateTime_Add2--''' = This will be replaced with the date and time that the Third signature was captured

== Accessing the Signature tool ==

When saving a record with an outcome that has a bxp template associated with it, and that the record was saved in one of the following modules Inbound, Outbound, Case Management and QA. The user will be presented with three buttons, to navigate to the signature capture page of bxp simply click on the button ''Capture Signature on PDF''

[[File:bxpSig_Buttons.png|none]]

== Signature Capture Page ==

Once the user has successfully navigated to the signature capture page of bxp they will be presented with the contents of the PDF document so they can review the it and decide whether or not they want to sign the document.

[[File:bxpSig_Main_Pre.png|none]]

Once a signature has been added to the signature capture area of bxp, the user must click on the ''Apply and Review Signature'' button. This will reload the same page and contents of the PDF document on screen except this time the captured signature will be applied to the contents so they can be reviewed.

[[File:bxpSig_Main_Post.png|none]]

At this stage there is three options available to the user:

'''1) Submit -''' This will submit the signature to bxp and an automatic download of a PDF will be started, an exact copy of the PDF document including the signature will be stored in the contact history of the record

'''2) Decline -''' This will log a decline to sign against the PDF document, an unsigned version of the file will be downloaded and a copy of the unsigned PDF will be stored in the contact history of the record

'''3) Re Do -''' This allows the user to re-signed the page in the signature capture area and have a new signature applied to the document for review.

[[File:bxpSig_Main_Post_Include.png|none]]

In Browser Signature Capture

2016-05-20T15:29:26Z

Patrick Jenkins: Created page with " == Overview == bxp now has the ability to allow for in browser signature capture on bxp templates, and also trigger an automatic download of a PDF document containing the si..."

== Overview ==

bxp now has the ability to allow for in browser signature capture on bxp templates, and also trigger an automatic download of a PDF document containing the signature that was captured.

Please note that older browsers may not be able to render the signature capture tool, but this has been tested as far back as Android 3.0 (honeycomb)

== Set up ==

In order to enable the signature capture option on a bxp template you must first set the ''Enable Signature Capture'' setting to ''True''.

[[File:bxpSig_Template.png|none]]

Once this is set to ''True'' bxp will know to render the ''Capture Signature on PDF'' after the user has saved a record to the database. When creating your bxp template you have two changes that you will need to add to your bxp template, these two changes are to show were to render the signature captured and the data and time of the signature.

In your template simply add ''--bxp_Signature_Capture--'', to wherever you want the signature captured to render. The next replacement you have is ''--bxp_Signature_Capture_DateTime--'', simply add this to wherever you want the date and time of the signature to render.

== Accessing the Signature tool ==

When saving a record with an outcome that has a bxp template associated with it, and that the record was saved in one of the following modules Inbound, Outbound, Case Management and QA. The user will be presented with three buttons, to navigate to the signature capture page of bxp simply click on the button ''Capture Signature on PDF''

[[File:bxpSig_Buttons.png|none]]

== Signature Capture Page ==

Once the user has successfully navigated to the signature capture page of bxp they will be presented with the contents of the PDF document so they can review the it and decide whether or not they want to sign the document.

[[File:bxpSig_Main_Pre.png|none]]

Once a signature has been added to the signature capture area of bxp, the user must click on the ''Apply and Review Signature'' button. This will reload the same page and contents of the PDF document on screen except this time the captured signature will be applied to the contents so they can be reviewed.

[[File:bxpSig_Main_Post.png|none]]

At this stage there is three options available to the user:

'''1) Submit -''' This will submit the signature to bxp and an automatic download of a PDF will be started, an exact copy of the PDF document including the signature will be stored in the contact history of the record

'''2) Decline -''' This will log a decline to sign against the PDF document, an unsigned version of the file will be downloaded and a copy of the unsigned PDF will be stored in the contact history of the record

'''3) Re Do -''' This allows the user to re-signed the page in the signature capture area and have a new signature applied to the document for review.

[[File:bxpSig_Main_Post_Include.png|none]]

File:bxpSig Main Complete.png

2016-05-20T14:54:27Z

Patrick Jenkins:

File:bxpSig Main Post Include.png

2016-05-20T14:53:41Z

Patrick Jenkins: