Modifying how transactions are summarized into payments in the new payment proposal

  • Article

In AX 4.0 the payment proposal has been through a major overhaul and many aspects of the proposal feature has been changed.

In this post I would like to focus on the principles for summarizing several invoice transactions into a single payment.

Most banks I know collect a fee for each payment you make, so when you make your payments you are of course interested in paying as many invoices as possible with the least number of payments.

To figure out which invoice transactions we can pay with a summarized payment and which invoice transactions we can certainly not summarize we must look at some of the fields from the invoice transaction. For several transactions to be paid with only one payment, a number of fields of the transactions most hold the same value. Some of these fields are:

  • Account number (AR or AP)
  • Payment currency
  • Method of payment
  • Payment specification
  • Posting profile
  • Bill Of Exchange or Promissory Note Id
  • Payment date

We call the values of these fields for payment attributes. These are important attributes about the transaction that must be preserved and brought forward to the payment. Transactions with a matching set of payment attributes can be paid through a single payment.

Do not change the above list of payment attributes. It is vital for the integrity of the system. A number of other payment attributes can be controlled by the administrator though. When setting up "Methods of payment" you can choose to activate the following extra payment attributes:

  • Third party bank account (i.e. bank account of the customer or vendor)
  • Payment account (i.e. the account we pay from = offset account in the journal)
  • Payment ID (identification of a single transaction to pay)
  • Belgian structured payment ID (like Payment ID but with some additional logic)

These attributes have the additional behavior that if not selected as a payment attribute, a default value might be set for them, rather than picking up the value from the invoice transaction. This is case for e.g. Payment account and Third party bank account.

If you add new attributes you must start by adding fields for these to the CustVendPaymProposalLine table.

When the payment proposal is executed it uses the class CustVendPaymProposalOrgPropose to setup the payment attributes the payments. If you look into the buildPaymProposalLine method you see can how the attributes are pieced together based on the invoice transactions. If you decide to add new payment attributes to the system this is where you must implement the logic to set the new attribute.

With the payment information in hand the payment proposal now checks if it already holds a payment with the given set of payment attributes. This is done in the findProposalLine method. So you must also add your new payment attributes to this method but this is just a simple addition to a select statement.

If you have ever tried to add a new payment attribute in earlier versions of Dynamics Ax, I am sure you will appreciate how easy this is done in the new payment proposal.

This posting is provided "AS IS" with no warranties, and confers no rights.