Buckaroo BPE3 Request Generator Engine

1.0

Doc. created

Yes

TBD

To be defined

N/A

Not applicable

This property specifies the Java path for CDRator engine starter. Main class property must be specified in order to start the engine framework.

The -S property is optional, but it is a parameter for the GenericEngineStarter which enables the engine starter to make a sleep just before it stops. The reason for this is that in cases where the engine has nothing to do, it can complete very quickly. The Windows NT Service environment might see this as a possible failure and will do a failure count. When the count reaches a specific number, it will halt completely and the service has to be restarted manually.

Number of seconds engine starter must sleep before it stops.

Specifies that the next parameter is to start the engine.

Specifies the java path of the engine class that the generic engine starter must use to start the engine

Parameter to engine. Specifies the engine name and how it will appear in logs and process monitor. This configuration parameter will make it possible to set a different engine name per brand, if multibrand setup is used. 

Used in the call to the Process Monitor together with the Instance Number.

Examples:  BuckarooBPE3RequestGenerator

Parameter to engine. Specifies engine's instance number.  

Parameter to engine. Specifies the max number of payments that the engine can handle in each run. 

To enable/disable the engine for the given brand.

If set to y/true: the engine will be enabled for the brand to which this parameter is configured for. Otherwise the engine is disabled for that brand.

INTEGRATION.BUCKAROO.BPE3.WEBSITE_KEY

String

Fixed string from Buckaroo portal. Used if WEBSITE_KEY_B2C /WEBSITE_KEY_B2B parameters are not defined. This is the case if same websitekey is used regardless of the type of the customer.

YES, if none of the two parameters: WEBSITE_KEY_B2C , WEBSITE_KEY_B2B are defined

INTEGRATION.BUCKAROO.BPE3.ACCOUNT_PAYMENT_TYPES

String

payment_type_id value of the
account_payment entries used to choose 
what type of account payments are 
picked up by the request
generator engine for creating the 
payment export file.
Ex: 200

YES

INTEGRATION.BUCKAROO.BPE3.DESCRIPTION_PREFIX

String

Prefix for the description field

YES

INTEGRATION.BUCKAROO.BPE3.VAT_VALUE

String

VAT value : 21 for BPE3

YES

INTEGRATION.BUCKAROO.BPE3.CURRENCY

String

Currency Code: EUR

YES

INTEGRATION.BUCKAROO.BPE3.DUE_DATE_OFFSET

String

Payment due date offset

YES

INTEGRATION.BUCKAROO.BPE3.EXPORT_FILE_PREFIX

String

Prefix with which export file name
will start with

YES

INTEGRATION.BUCKAROO.BPE3.EXPORT_FILE_EXTENSION

String

Extension used for export file.
For ex: .CSV

YES

INTEGRATION.BUCKAROO.BPE3.CULTURE_CODE

String

ISO culture code:  nl-NL

YES

INTEGRATION.BUCKAROO.BPE3.PAYMENT_METHODS_ALLOWED

String

Allowed payment methods

NO

machtiging

INTEGRATION.BUCKAROO.BPE3.PAYMENT_METHOD_INVALID_BANK_ACC

String

Allowed payment method if the bank account number is null or zero

NO

ideal

INTEGRATION.BUCKAROO.BPE3.DUMMY_BANK_ACC_NUMBER

String

Dummy bank account number used in case the customer bank account number is either null or zero or in anyway invalid.

NO

<Empty String>

INTEGRATION.BUCKAROO.BPE3.COUNTRY

String

Country code value

NO

NL

Value to be put into the 'startrecurrent' field of the Direct Debit request file.

Possible values are: TRUE , FALSE

The day of month to be used as the collect date for all the Direct debit requests in the Buckaroo request file.

For ex: If the USE_FIXED_SEPA_DD_COLLECT_DATE is set to 'true' and this parameter has the value '20' and the file was generated for May 2014, then the collect_date for all the Direct debit request records in that file is: 2014-05-20

Please be aware that the value of SEPA_FIXED_COLLECT_DATE_DAY_OF_MONTH

must be later than the day of file generation .

Also if Pre-notification is used, the collect date must be at least <NOTIFICATION_SEND_DATE_OFFSET> days after the file generation date to be able to send pre-notification emails to the customers.

Used only when Buckaroo Notification service is used.

 The number of days prior to the collect_date for calculating the pre-notification send-date at which the notification should be sent.. If the collect date is 2014-05-20 and the value of NOTIFICATION_SEND_DATE_OFFSET is 14, then the pre-notification send date is 14 days prior to collect date. i.e notification send date = 2014-05-06.

Used only when Buckaroo Notification service is used.

Indicates whether the srv_notification_senddatetime field should be set to empty value. In that case Buckaroo will decide when to send pre-notification emails.

Used only when Buckaroo Notification service is used.

The type of notification to send. Can be one of the following:

• PreNotification: A pre-notification that is sent some time before performing a scheduled action.
• PaymentComplete: A notification that is sent when a transaction has been completed with success.
  

See Buckaroo Notification service description document for more information

Used only when Buckaroo Notification service is used.

The method used to send the notification. Can be one of the following:

• Email: The notification is sent by email. 

Please note: The communication method determines which fields are mandatory. See Buckaroo Notification service description document for more information

ACCOUNT_PAYMENT_REQUEST

Each record represents a direct debit payment request. The InvoiceHandlerEngine will create an  account payment request record for each invoice that is successfully closed. The Buckaroo Request Generator engine will then read the payment requests in this table that are ready for capture and inserts the required payment data into buckaroo tables mentioned below.
NOTE: For BPE2, the ACCOUNT_PAYMENT records are created during the invoice close process i.e. one ACCOUNT_PAYMENT for every closed invoice and the BPE2 request generator reads the data from the ACCOUNT_PAYMENT table. But for BPE3, a new payment solution is implemented to handled various types of payments (like partial payments, creditnotes, write offs etc..). As per this new solution, the invoice close process will not create ACCOUNT_PAYMENT records. It will create ACCOUNT_PAYMENT_REQUEST records which are used by the Buckaroo BPE3 request generator. The ACCOUNT_PAYMENT records are created by the Buckaroo BPE3 Response reader (Capture) engine when the response file from Buckaroo is processed. For every successfully processed payment response, an ACCOUNT_PAYMENT and an INVOICE_PAYMENT record will be created. So with BPE3 solution, there will be one-to-one relation between InvoicePayments and AccountPayments.

BUCKAROO_REQUEST_HEADER_BPE3

Each record represents a header which holds reference to the record data needed to generate a payment request file. Each header entry can have one or more corresponding request records in BUCKAROO_REQUEST_RECORD_BPE3 table. So for each record (not in ERROR status) in this table, a payment file will be generated and sent to the Buckaroo containing the information like name of the file, status, file generation date, number of records in the file etc.

BUCKAROO_REQUEST_RECORD_BPE3

Each record represents a a payment record in the payment request file. Each record in this table contains actual payment information like amount, VAT, user info like name, bank account info, address etc.

Name:

BUCKAROO_NOTIFICTN_HEADER_BPE3

Description:

Each record represents a header which holds reference to the record data needed to generate a seaparte pre-notification file. Each header entry can have one or more corresponding notification records in BUCKAROO_REQUEST_RECORD_BPE3 table. So for each record (not in ERROR status) in this table, a pre-notification file (containing the information like customer name, email, type of notification used, communication method used and the date of sending the notification) in the file etc.) will be generated and sent to the Buckaroo. Please note that this table will be used only if separate notification files need to be created.