AX2012_ENUS_DEVIV_07.pdf

Chapter 7: Use and Design of the Accounts Receivable and Accounts Payable Modules

7-1

CHAPTER 7: USE AND DESIGN OF THE ACCOUNTS RECEIVABLE AND ACCOUNTS PAYABLE MODULES Objectives

The objectives are:

• Describe the activities and transactions that can be created for customers.

• Review the customer data model. • Describe the activities and transactions that can be created for

customers. • Describe how free text invoices are used. • Review the data model and framework that is used for processing

free text invoices. • Review the various ways that vendor invoices can be generated. • Describe the set up that is required for payments and review the data

model for payment set up. • Describe how customer and vendor payments are made. • Review the customer payment data model and discuss the framework

that is used for making and generating payments. • Describe how collections and interest notes are used. • Review the data model and framework for interest notes. • Describe the functionality that is available for bill of exchanges. • Describe the functionality that is available for promissory notes.

Introduction The Accounts receivable and Accounts payable modules offer similar functionality for customers and vendors. The modules are used to maintain the customer and vendor information and the transactions that occur for each. This chapter reviews the functionality that is available for customers and vendors and the primary transactions that occur for each module.

Microsoft Official Training Materials for Microsoft Dynamics®

Your use of this content is subject to your current services agreement

Development IV in Microsoft Dynamics® AX 2012

7-2

Customers Accounts receivable is used to track customer invoices and incoming payments. You can create customer invoices for a sale that is based on sales orders or packing slips. You can also enter free text invoices that are not related to sales orders. Additionally you can generate customer invoices from a project. You can receive payments by using several different payment types. These include bills of exchange, cash, checks, credit cards, and electronic payments. If your organization includes multiple legal entities, you can use centralized payments to record payments in a single legal entity on behalf of the other legal entities.

You can use the Settle open transactions form to settle invoices with payments or credit notes. You can also enter payments and settle them in the Enter customer payments form. To view customer information, use the All customers list page and related forms. You can manage overdue balances, calculate interest, and generate collection letters by using the Collections list page and related forms.

Accounts Receivable Processes

The main tasks supported by the Accounts receivable module include the following.

• Maintain customers • Free text invoice • Request payment • Register payment • Bill of exchange • Account statement • Collection letter • Interest calculation • Exchange adjustment • Reconciliation




7-3

The following figure shows the Accounts receivable business process.

FIGURE 7.1 ACCOUNTS RECEIVABLE BUSINESS PROCESS

Maintain Customers

Creating new customers and maintaining existing customer information is an ongoing task. Make sure that customer setup is correct to guarantee smooth communication and to avoid calculation errors.

Some customers are transferred from the Prospects form in the Sales and marketing module. However, other customers must be created manually in the Accounts receivable module. The customer forms and list pages are available from the Accounts receivable and the Sales and marketing modules.

Customer sales prices and discounts for items sold should be maintained. Prices can be set up specifically for individual items and customers, for a group of customers or for all customers as one group. The price structure also includes line, multiline, and total discounts.

The actual value of invoices due in a foreign currency can change over time as the result of exchange rate fluctuations. Because an invoice’s value is calculated in the accounting currency when the transaction is posted, you could have to make periodic exchange rate adjustments to revalue foreign currency receivables.




7-4

Reconciliations guarantee that registrations about customer transaction status are correct. The reconciliation process includes different kinds of reporting to analyze open transactions and to make sure that they are reflected correctly in the General ledger module. It is also important that the customer has the same opinion of the current status of the financial relationship.

Accounts Receivable Integrations

The Accounts receivable module helps monitor relationships between the company and its customers. The following figure shows interfaces with other Microsoft Dynamics AX 2012 modules.

FIGURE 7.2 ACCOUNTS RECEIVABLE INTEGRATIONS

The Accounts receivable module handles customer-related transactions. The primary focus of the module is to keep track of open invoices and to register payments.

The Sales and marketing module handles administration of potential customers or prospects. This includes submission of quotations. When a quotation is accepted, it is then transferred to a sales order. At this point, the potential customer is created as an actual customer.




7-5

Trade agreements (terms and conditions) made with the customer are registered and maintained in cooperation with the Inventory and warehouse management module. The customer’s expected sales can be forecast and used in master planning.

When a sales order or project is invoiced, the information is passed to the Accounts receivable module that administers payment collection.

The General ledger module keeps track of all company financial transactions. All customer financial movements are replicated in the General ledger module.

Payment transactions are recorded in the Cash and bank management module that controls the company’s bank accounts.

Customer Data Model

The following figure shows the data model for customers and customer transactions.

FIGURE 7.3 CUSTOMER DATA MODEL

Each transaction (invoice, payment, and so on) is represented by one record in the CustTrans table.




7-6

CustTransOpen contains one or more records for all transactions in CustTrans that are not completely settled against other transactions. The relation between CustTransOpen and CustTrans is made by the RefRecId in CustTransOpen that is a foreign key to the RecId of the related CustTrans. The reason for this design is that one open transaction can be distributed across several due dates by using payment schedules.

CustSettlement contains information about settlement between transactions in CustTrans. The record refers to the two transactions (TransRecId and OffsetRecId) and specifies the amount settled between the two transactions. The information includes the date of the settlement. This makes it possible to backdate or future date a transaction’s settlement status in CustTrans. This data structure allows you to retrieve a customer balance at any point in time as it transitions from the open to the closed state.

Both open and settled parts of a customer transaction can have related cash discount information. This information is stored in a separate table, CustTransCashDisc, because each transaction part can have multiple cash discount specifications.

Vendors Accounts payable is used to track vendor invoices and outgoing expenditures. You can enter vendor invoices manually or receive them electronically through a service, or your vendor can enter the invoices by using a vendor portal. After the invoices are entered or received, you can review and approve the invoices by using an invoice approval journal or the Vendor invoice form. You can use invoice matching, vendor invoice policies, and workflow to automate the review process so that invoices that meet certain criteria are automatically approved, and the remaining invoices are flagged for review by an authorized user.

After vendor invoices are approved, you can pay vendors. If your organization includes multiple legal entities, you can use centralized payments to pay all invoices from a single legal entity. Multiple payment formats are supported. These include checks, promissory notes, and Single Euro Payments Area (SEPA) electronic payments. You can settle invoices with payments or credit notes by using the Settle open transactions form. To view vendor information, use the All vendors list page and related forms.

Accounts Payable Processes

The main tasks supported by the Accounts payable module include the following.

• Maintain vendors • Register invoice • Invoice approval • Payment proposal • Register payment • Promissory notes




7-7

• Exchange adjustment • Reconciliation

The following figure shows the Accounts payable business process.

FIGURE 7.4 ACCOUNTS PAYABLE BUSINESS PROCESS

Maintain Vendors

Creating new vendors and maintaining existing vendor information is an ongoing task. Make sure that vendor setup is correct to guarantee smooth communication and to avoid calculation errors.

Purchase prices and discounts for items purchased should be maintained. Prices can be set up specifically for individual items and vendors, for a group of vendors, or for all vendors as one group. The price structure also includes line, multiline, and total discounts.




7-8

Accounts Payable Integrations

The Accounts payable module helps monitor relationships between the company and its suppliers. The following figure shows interfaces with other Microsoft Dynamics AX 2012 modules.

FIGURE 7.5 ACCOUNTS PAYABLE INTEGRATIONS

The Accounts payable module handles vendor-related transactions. The primary focus of the module is to keep track of invoice approval and payment processing.

Trade agreements (terms and conditions) made with vendors are registered and maintained with the Inventory and warehouse management module. Expected purchases can be forecast and used in master planning.

When a purchase order invoice is recorded, the information is passed to the Accounts payable module that administers invoice approval and payment processing.

The General ledger module keeps track of all company financial transactions. All vendor financial movements are replicated in the General ledger module.

Payment transactions are recorded in the Cash and bank management module that controls the company’s bank accounts.

The data model for vendors and vendor transactions resembles the customer data model. Therefore, the data model for vendors is not reviewed. The primary difference between the data models is that the vendor data model tables begin with Vend... and the customer data model tables begin with Cust.




7-9

Free Text Invoices The Accounts receivable module has its own invoice function. Although sales order invoices are integrated with the Inventory and warehouse management module, free text invoices are not related to inventory items.

This lack of integration makes the use of free text invoices simpler and creates fewer database records. Therefore, free text invoices are a good option when integration to other functions is required.

Implementing free text invoices as the primary invoice engine will typically require some additional programming, because the standard application only handles basic scenarios.

Free text invoices in Microsoft Dynamics AX 2012 introduce a new recurring free text invoice feature. With recurring free text invoices you can create templates that are linked to one or more customers to be invoiced at set intervals. Then you can run a simple job to create the invoice, and another job to post the invoices. A new corrections feature and workflow for free text invoices is also introduced. Additionally, the free text invoice includes source document support and subledger journal distributions.

Free Text Invoice Data Model

A free text invoice is an invoice that is not attached to a sales order. A free text invoice contains a header and one or more lines for items or services that are not tracked in inventory. Use a free text invoice for sales that do not require a sales order and packing slip. For example, you can use a free text invoice for a consulting fee or services fee, or for a miscellaneous fee for an event reimbursement.




7-10

The following figure shows the free text invoice data-model.

FIGURE 7.6 FREE TEXT INVOICE DATA MODEL

The CustInvoiceTable contains invoice headers, whereas CustInvoiceLine contains details about invoice lines. When an invoice is posted, its information is copied to the invoice journal with the header in CustInvoiceJour and the lines in CustInvoiceTrans.

CustInvoiceJour and CustInvoiceTrans also contain invoices posted in the Sales and marketing module. The invoice report is shared with the Sales and marketing module. This means that the journal and the invoice report already contain quantity and price fields.

TIP: Project related invoices go into the ProjInvoiceJour and ProjInvoiceTrans tables instead of the CustInvoiceJour and CustInvoiceTrans tables.

The CustRelatedInvoice table contains the relationship between the original, parent, corrected and adjusting invoice.

Printing setup and copies can be specified individually for each customer. This setup can be overridden in a specific Free Text Invoice. The setup is included in the tables PrintMgmtDocInstance, PrintMgmtSettings and PrintMgmtIdentificationText.




7-11

Recurring Free Text Invoice Data Model

The following figure shows the recurring free text invoice data model.

FIGURE 7.7 RECURRING FREE TEXT INVOICE DATA MODEL

Each free text invoice template record is stored in the CustInvoiceTemplate table. The lines of the templates are stored in the CustInvoiceLineTemplate table. Each free text invoice template must be linked to one or more customers. The CustRecurrenceInvoice table contains the information about the templates that are assigned to a customer. One template can be assigned to multiple customers, and each customer can have multiple templates assigned.

Periodically, you must run the Generate recurring invoices job to create the recurring free text invoices for each customer. When the job runs the CustInvoiceTemplate table records are copied into the CustInvoiceTable as a standard free text invoice. The lines are copied from the CustInvoiceLineTemplate table to the CustInvoiceLine table.

Every time that the Generate recurring invoices job is run, a new record is inserted into the RecurrenceInvoice table. This record serves as a batch or "journal" header type record for the free text invoices that are created. The CustRecurrenceInvoiceGroup table contains information about each of the free text invoices that are created from the batch.

When the recurring free text invoices are posted, the transactions are copied to the CustInvoiceJour and CustInvoiceTrans tables in the same manner that a regular free text invoice is processed.




7-12

CustPostInvoice Classes

CustPostInvoice

The CustPostInvoice class handles the posting of a single free text invoice specified by one record in the CustInvoiceTable and one or more records in the CustInvoiceLine.

The posting includes the generation of the following data.

• Ledger transactions by using the LedgerVoucher class. • Customer transactions by using the CustVoucher class. • Tax transactions by using the CustInvoiceCalcTax class. • Invoice journal and lines (CustInvoiceJour and -Trans). • Printing of the invoice report by using the FormLetter framework

classes.

CustPostInvoiceJob

The CustPostInvoiceJob class handles the selection of which records in the CustInvoiceTable to post. It also handles the printing of the invoices if it is specified. The class extends from the RunBase-framework.

Vendor Invoices Invoices can originate from purchase orders. However, if an invoice is created in another system, or for products and services that are not recorded in a purchase order, then it can be recorded manually in Microsoft Dynamics AX, by using the General journal or an Invoice journal in the Accounts payable module. When you manually enter a vendor transaction and specify a vendor account and an invoice number, the transaction will be recorded as an invoice.

The company receives invoices from its vendors. To make sure that received invoices are correct and valid, incoming invoices are typically sent through an approval workflow.

It is important to register invoices as quickly as possible. You do this with a status that displays that the invoice is awaiting approval. This status is changed when the invoice is approved.

Invoicing Methods

Purchase Order Invoicing

A vendor invoice for a purchase order is an invoice that is attached to a purchase order. It contains a header and one or more lines for items or services. A vendor invoice finishes the purchase order, product receipt, and vendor invoice cycle. You can also enter vendor invoices that are not associated with purchase orders.




7-13

Invoice Journal

The procedure for handling invoices varies from company to company, depending on the company's size, structure and organization. The invoices are typically one of the following:

• Registered • Approved • Paid

Consider the following about Microsoft Dynamics AX.

• It supports several methods of managing incoming invoices to cater to different company procedures.

• It has a different invoice journal depending on the need of the company.

The following types of invoices are available.

• Invoice Register • Invoice Approval Journal • Invoice Pool excluding Posting • Invoice Journal

Invoice Journal Types

Invoice Register

The purpose of the invoice register journal is to pre-register invoices when they arrive at the company and transfer them to an invoice pool for approval. In the invoice register journal, an employee registers the following information.

• Vendor account • Invoice number • Amount • Person who approves the invoice

The same employee validates and posts the journal to the accounts specified in the posting profile. Usually the accounts are pending accounts where the amounts require the manual approval and reclassification by the person specified in the journal line.




7-14

Invoice Approval Journal

After you post the lines of the invoice register, the postings display in the invoice pool. To view the postings in the invoice pool click Accounts Payable, click Inquiries, and then click Invoice pool. The following applies to the invoice pools.

• The invoice pool displays the relevant information about the invoices awaiting approval.

• The invoice pool holds invoices originating from a purchase order that originate from an invoice register. Click the Purchase order button to select and approve the purchase orders.

Vendor Invoice Pool Excluding Posting Details

Invoice pools excluding posting have the following characteristics:

• The invoice register excluding posting is another kind of journal available in the Accounts payable module.

• By using the invoice journal represents another procedure for handling incoming invoices, although it resembles the invoice register with posting. The difference is that you cannot post the lines. The lines go directly into the invoice pool.

• To post the lines, create a new invoice journal, and then click Functions. Select Invoice pool and accept the individual invoices in the pool after you approve them.

• If you activate the invoice pool by accessing the invoice pool exclude posting item in the Accounts Payable menu, the invoices shown on the window are registered, unapproved invoices. Although the invoices are unposted, they are registered in the system.

• Use the invoice journal to transfer the invoices for approval and posting.

Invoice Journal

A third option for processing incoming invoices is to enter them directly into the invoice journal.

• By default, the user who is logged on and enters the journal lines approves the invoices.

• The invoice journal is designed for users to enter the invoices they receive from vendors without entering them into the approval journal. As soon as the user enters the incoming invoices, the user can post.




7-15

Invoice Journal Data Model

Invoice journals use the LedgerJournalTable and LedgerJournalTrans tables in the same manner that a general journal is created. The posting logic is also handled through the LedgerJournalCheckPost framework. However, there are small differences in the validation that occurs for an invoice journal versus a general journal. For this reason the details of the data model and posting framework are not reviewed here. For more information about the journal and posting framework, refer to the Use and Design of the Ledger Module chapter in this course.

Payments The collection of customer payments and generation of vendor payments is one of the most important tasks in the finance process. They control the flow of cash into and out of your business.

If you do not receive payments from your customers, you might not have cash to make payments to vendors and keep your business running. Similarly, if you do not make payments to your vendors for the items that you purchase, your vendors could stop sending you items that keep your business running.

Before any payments can be made or received, several system setups must be completed. Most of the payment setup is shared between the Accounts receivable and Accounts payable modules, and there are many similarities in the processing of payments for each module.

Payment Set Up

Microsoft Dynamics AX offers extensive functionality for setting up different vendor payment options. These global payment options are used in the Accounts payable and Accounts receivable modules, and include the following.

• Payment schedules: Use payment schedules to pay invoices in installments. You must define the following to set up a payment schedule. o Number of installments o Amount of each installment o Due date of each installment

• Payment days: Use payment days to define the payment day used

for calculating the due date. The due date always is rounded up to the nearest specified date. Payment days can be specified for one of the following. o Day in the week o Day in the month




7-16

• Terms of payment: Use a term of payment for the calculation of a due date based on the date of the invoice.

• Cash discounts: Use cash discounts to accrue and reward discounts if a company meets the vendor payment terms on time, or give them to customers when they pay their invoices in a specified period.

• Payment fees: Use payment fees to specify if any additional charges are added to the vendor invoice. For example, a vendor might add a fee for issuing a promissory note or a company might be charged a vendor bank remittance fee.

• Methods of payment: Methods of payment are used to define how payments should be summarized and posted. Many companies offer several methods to pay due invoices, such as the following. o Credit o Cash in advance o Bill of exchange o Check and electronic payments




7-17

Payment Set Up Data Model

The following figure shows the data model for setting up customer payment information.

FIGURE 7.8 PAYMENT SET UP DATA MODEL

VendPaymFormat contains payment formats that are selected by using the Setup button on the File formats tab page (in the form used for setting up payment methods).

VendPaymModeTable contains defined payment methods. These include related file formats that are represented by an ID of the class implementing the format. Each payment method can be related to other information.




7-18

VendPaymMethodVal contains validation rules for the payment method. It determines which information should be specified to process the payment.

VendPaymModeSpec contains specifications of different record formats in the file that is used for requesting payments (Export format).

VendPaymModeFee specifies fees related to the payment method. The different kinds of fees that include the setup of ledger postings are set up in the table VendPaymFee. VendPaymModeFeeInterval specifies fee amounts as a function of the number of days between a remittance and a bill of exchange’s due date.

Similar tables that begin or end with Cust are used for customer payment set up. The following tables are shared between Accounts receivable and Accounts payable.

• PaymSched and PaymSchedLine: These tables are used to store the payment schedules. Payment schedules can be linked to terms of payments, customers, or vendors.

• PaymDay and PaymDayLine: These tables are used to store payment days. Payment days can be linked to terms of payment, customers, or vendors.

• PaymTerm: This table stores each of the terms of payment. Terms of payment can be linked to customers or vendors.

• CashDisc: This table is used to store the definition of cash discount terms. Cash discounts can be linked to customers or vendors.

Customer Payments

Request Payments

Some companies request customer payment by submitting electronic information to a bank. This requires agreement with the customer, because payments are drawn automatically without the customer’s individual approval.

Banks typically respond with corresponding electronic information, specifying whether the individual payments are processed or canceled.

This automatic approach to customer payment is typically used by companies with high sales volumes to regular customers, such as subscriptions.

Payment Journals

Payment registration is one of the Customer module’s main tasks. The payment journal, a variant of the general journal used in the General ledger module, is used to register customer payments. You can do this manually by entering information into the payment journal.




7-19

Some companies receive payment information electronically from banks. This requires that customer invoices contain payment information that must be attached to the customer’s bank payment. This payment information, when it is received by the company from the bank, is imported to the same kind of journal that is used for manual payment entry.

Key tasks related to payment registration are to match invoices with their specific payment, and to recognize outstanding invoices to be able to calculate interest charges and submit collection letters. By doing this, the electronic payments received from the bank, should settle and pay the appropriate invoices. Some payments have related fees that customers should pay to the bank. Registration of these fees is an integrated part of payment registration.

Vendor Payments

Payment Proposal

Open vendor invoices are reviewed periodically to select specific invoices to pay. You do this by entering the payments in a journal with the specifications for those invoices that will be settled. The Accounts payable module includes a function for automatic proposals of those invoices that have to be paid.

When the payment proposal is reviewed and approved, payments are then typically generated. The payment generation process is different, depending on the method of payment. For check payments, a physical check must be printed and mailed, whereas other types of payments require the generation of a file that is transferred electronically to a bank.

Payment Journals

Payment registration is usually performed by posting the payment proposals entered in the journal.

Some banks deliver a response to electronic payments as a receipt. Delaying journal posting until arrival of the bank receipt is optional.




7-20

Payment Journal Data Model

The following figure shows the data model for the customer payment journal.

FIGURE 7.9 PAYMENT JOURNAL DATA MODEL

LedgerJournalName contains different journal names, based on how they are set up in the General Ledger module. Each journal name is related to one specific type of journal. One of the journal types is customer payments.

LedgerJournalTable contains records that are headers for individual journals. A new record is created in this table every time that the user creates a new journal in the form that displays the list of journals.

LedgerJournalTrans contains individual journal lines. Each payment can have related fees.

The fees are stored in the CustVendPaymJournalFee table. Each payment fee can generate a new record in LedgerJournalTrans that will contain the fee. To post payment fees, this design uses the usual ledger journal posting. Fee transactions cannot be viewed or edited in LedgerJournalTrans, because this is replicated from the information in CustVendPaymJournalFee.




7-21

When a payment is entered in the journal, the desired transaction settlement can be specified when it is posted. The settlement is stored in the SpecTrans table, and will be reflected in the CustSettlement table when the journal is posted. Each record in SpecTrans defines a settlement between a line in the payment journal and an open transaction part in CustTransOpen. SpecTrans can contain information other than settlements from the customer payment journal. The same table is used for other settlement specifications in the Customer and Vendor modules.

The CustVendPaymProposalLine table contains the payments that are proposed by the payment proposal creation and edit processes. The payment proposals are removed from this table at the end of the process, and inserted into the LedgerJournalTrans table.

CustInPaym Class

The CustInPaym class forms a framework for the import of payments from customers. The file is typically received from the company bank. The function involves reading the file and creating a new journal that contains the payments. The information in the received file will usually contain a reference to the invoice covered by the payment, and the import should make a settlement against the open invoices while generating the payment journal.

When a payment method is set up, it can be related to an import file format. This function will display all classes extending from CustInPaym.

CustOutPaym and VendOutPaym Classes

The CustOutPaym and VendOutPaym classes form a framework for exporting payment information to a file. This file is typically sent to the company bank for processing.

CustOutPaym is used to generate a file of payments to be collected from the customers. This typically requires a form of agreement with the customer and the banks involved.

VendOutPaym is used to generate a file of payments to be sent to the vendors.

CustOutPaymRecord and VendOutPaymRecord

The files generated can contain different types of records to handle several ways of processing the payment. The individual types of records in the file are implemented by creating a class extending from CustOutPaymRecord/VendOutPaymRecord. If multiple record types will be implemented, they should be implemented as extensions from one root class extending from CustOutPaymRecord/VendOutPaymRecord.

This root class is associated to the class extending from CustOutPaym/VendOutPaym by overriding the method custVendOutPaymRecordRootClassId.




7-22

The following classes form a tutorial that displays an implementation of an arbitrary format.

• VendOutPaym_Format1 • VendOutPaymRecordFormat1 • VendOutPaymRecordFormat1Spec1 • VendOutPaymRecordFormat1Spec2

You can make a duplication of these classes, when you implement a new specific format.

CustPaym and VendPaym

The details of a payment can be retrieved from many tables in the Vendor module. The VendPaym class contains a payment’s consolidated information. All information is available by calling corresponding methods. The methods can be grouped into three categories.

• The first group of methods describes payment senders (the company exporting payments). All these methods have the prefix “senders.”

• The second group of methods describes payment receivers. All these methods have the prefix “receivers.”

• The last group of methods describes payments. All these methods have the prefix “paym.”

CustVendCreatePaymJournal Class

The CustVendCreatePaymJournal class is used to generate journals with payments or journals handling bills of exchange and promissory notes.

The class searches for open invoices that will be paid by using a cash discount and due date criteria. The data fetched is controlled by a query on the CustTransOpen/VendTransOpen table and the payments generated are saved in a ledger journal (LedgerJournalTrans).

The generated journal can be exported to a file by using the Cust-/VendOutPaym classes described earlier.

CustVendSettle Class

The CustVendSettle class handles the update of a settlement between an invoice and a payment. The processing is complex because the settlement can include some of the following tasks.

• Read open transaction editing information in SpecTrans table • Calculation and posting of cash discount • Reversal of posted tax on cash discount • Calculation and posting of conditional tax




7-23

• Calculation and posting of exchange rate adjustment • Handling of over/underpayment • Update information in CustSettlement/VendSettlement • Centralized Customer /Vendor payments

The processing is automatically activated when you post customer or vendor transactions in the ledger journal.

If the journal transaction is created by X++ the open transaction editing can be controlled by creating records in SpecTrans as illustrated earlier. Suppose that the amount in the journal transaction must be settled against a specified tableId (Cust-/VendTransOpen) and recId. The following method will create the information in SpecTrans.

protected void createSpecTrans( LedgerJournalTrans _ledgerJournalTrans, TableId _tableId, RecId _recId) {

SpecTransManager specTransManager; ; specTransManager = SpecTransManager::construct(ledgerJournalTrans); specTransManager.insert(_ledgerJournalTrans.DataAreaId, _tableId, _recId, _ledgerJournalTrans.amount(), _ledgerJournalTrans.CurrencyCode);

}

If the task is to settle several open transactions without creating a new transaction, you can do this by using the following code sample.

SpecTransManager specTransManager CustTable custTable; CustTransOpen custTransOpen;

specTransManager = SpecTransManager::construct(custTable);

specTransManager.deleteAll();

custTransOpen = …; specTransManager.insert(custTransOpen.DataAreaId, custTransOpen.tableId,




7-24

custTransOpen.recId, custTransOpen.AmountCUR, custTransOpen.custTrans().currencyCode);

custTransOpen = …; specTransManager.insert(custTransOpen.DataAreaId, custTransOpen.tableId, custTransOpen.recId, custTransOpen.AmountCUR, custTransOpen.custTrans().currencyCode);

CustTrans::settleTransact(custTable);

This resembles the manual transaction editing that can be controlled by the end-user.




7-25

Lab 7.1 - Export Vendor Payments This lab demonstrates how to use the framework to implement a specific file format related to the exchange of payment information between the company and their bank.

This lab is designed for self-study. Completing this lab takes approximately 45 minutes.

Scenario

The solution should contain a function for exporting payments to a file. The file should contain one record for each payment, and the records should have a fixed length.

The file can consist of two kinds of records. One record is used for bank transfers and another record layout is used for checks.

The length of each record is 198 bytes. Each record is separated by Carriage Return Line Feed (CR LF). The total size of the file is 200 bytes for each transaction.

The record layout for a bank transfer is as follows.

Field Description Start End Length

Type 001 1 3 3

Bank Reg. Bank Registration (routing) ID 4 7 4

Bank Acc. Bank account number 8 17 10

Payment ID

Payment identification 18 37 20

Date YYYYMMDD 38 45 8

Currency ISO 46 48 3

Amount 2 decimals, no separator, right adjusted, zero fill

49 63 15

Filler Spaces 64 198 135




7-26

The record layout for a check payment is as follows.

Field Description Start End Length

Type 002 1 3 3

Name Name of receiver 4 33 30

Address 1 Address line 1 34 63 30



Reference Payment reference 124 143 20

Date YYYYMMDD 144 151 8

Currency ISO 152 154 3

Amount 2 decimals, no separator, right adjusted, zero fill

155 169 15

Filler Space 170 198 29

Technical Issues

VendOutPaym

The VendOutPaym class defines the framework used to implement individual formats for exporting vendor payments.

All classes extending from VendOutPaym will be available when you set up export formats related to payment methods.

The extension should implement the following methods.

• interfaceName • open • close • custVendOutPaymRecordRootClassId • dialog • pack • unpack • validate • ::description (Scope resolution operator determines the method is

static)

The interfaceName method should return a string (type PaymInterfaceName) that describes the format. The method is used in the user interface to represent the payment method. Use the following code sample to guide you.




7-27

The open method should initialize data member files that are defined in the super class. Use the following code sample to guide you.

public PaymInterfaceName interfaceName() { return "AXA export"; }

public void open() { file = CustVendOutPaym::newFile(filename, this.codepage()); if (!file || file.status() != IO_Status::OK) { throw error(strFmt("@SYS73665",filename)); } file.outFieldDelimiter(''); file.outRecordDelimiter('\r\n'); }

Codepage

Codepage is a list of selected character codes in a certain order. Codepages are usually defined to support specific languages or groups of languages that share common writing systems. For example, codepage 1252 provides character codes required in the Latin writing system.

The LocalCodePage macro lists code pages defined.

private int codepage() { #Localcodepage ; return #cp_1252; }

The close method is called when all payments are exported to the file. If the last record should be followed by a record delimiter, then an additional empty call to file.write() can be included in this method. The method can also send information to the created file’s infolog.

The custVendOutPaymRecordRootClassId method returns the ID of the root class implementing the different record types. This class is described in the following text. Use the following code sample to guide you.

classId custVendOutPaymRecordRootClassId() { return classNum(VendOutPaymRecord_AXA); }




7-28

The dialog method is overridden to specify those fields to include in the dialog box. If the only field is the name of the file, then the method should be such as this.

protected Object dialog(DialogRunbase _dialog = null, boolean _forceOnClient = false) { DialogRunbase dialog; ;

dialog = super(_dialog, _forceOnClient);

this.dialogAddFileName(dialog); this.dialogAddPrintDocument(PaymDocumentType::ControlReport, dialog, true); return dialog; }

Notice that the method also adds functionality to print a control report.

The pack and unpack methods should be implemented by using the usual contents. The CurrentVersion and CurrentList macros are defined in the super class.

The validate method should, as a minimum, contain validation of the specified file name.

The method, ::description is a static method that returns the same information as the object method interfaceName. The following is a sample of this method.

client server public static ClassDescription description() { return new VendOutPaym_AXA().interfaceName(); }

VendOutPaymRecord

The VendOutPaymRecord class defines the framework for implementing individual record types in an export file.

Each payment format extending from VendOutPaym should be associated with a class extending from VendOutPaymRecord. Each record type is implemented as an extension of the class that is specified as the root in the custVendOutPaymRecordRootClassId method described earlier.

You can use “abstract” classes in the hierarchy with the purpose of sharing code between some record formats. The rule is that you should only implement the interfaceName method on classes that implement an actual record type.




7-29

Each record type should implement the following methods.

• interfaceName • checkValues • output

The interfaceName method will return a string (type PaymInterfaceName) that describes the type of record. The method is used in the user interface to represent payment specification. An example of the method follows.

public PaymInterfaceName interfaceName() { return "Bank transfer"; }

The checkValues method implements record type validation. Among other things, it verifies that mandatory information is present. If the validation fails, then the method returns false and errors will be reported to the infolog. This is achieved by using the usual “return checkFailed()” pattern.

The output method writes the record type to the file. You can do this by calling file.write() or file.writeExp().

Both methods checkValues and output methods are called automatically for each record to export. All information about the payment will be available through the data member custVendPaym, based on the VendPaym class described in the following text.

Implementation

Perform the following steps to export the vendor payments to a file of a fixed length as it is specified in the “Scenario” section of this lab.

TIP: The code samples for this lab can be found in the AX2012_ENUS_DEVIV_07_01_LAB_CODE.txt file. You can copy and paste these code samples into the correct methods.

1. Create a new class called VendOutPaym_AXA that extends the VendOutPaym class. Implement the following methods as described in the "Technical Issue" section of this lab. Use the code samples provided in the sample file to guide you. a. classDeclaration (declare variables as required for the class) b. interfaceName c. open d. close e. custVendOutPaymRecordRootClassId f. dialog




7-30

g. pack h. unpack i. validate j. description

2. Create a new class called VendOutPaymRecord_AXA that extends

the VendOutPaymRecord class. This class should override the checkValues method and contain logic to validate that the payment specification is entered, and that credit amounts are not allowed.

3. Create two new classes that extend the VendOutPaymRecord_AXA class. The first class is for checks, and the second class is for bank transfers. Each class should implement the following methods. a. interfaceName b. output (This method should build the fixed length string as

defined in the "Scenario" section of this lab.

4. To test the implementation, complete the following steps. a. Create a new method of payment that uses the new export

format. b. Create two payment specifications and relate them to the

corresponding classes. c. Create a new payment journal. d. Export the payments.

TIP: You can import the AX2012_ENUS_DEVIV_07_01_LAB_SOL.xpo file to verify and compare your solution.

Test

To test the implementation, complete the following steps.

1. Create a new payment method by using the path Accounts payable > Setup > Payment > Methods of payment. a. Specify the account type (Bank) b. Set the payment account (USA OPER).

2. Click the Setup button on the File formats FastTab. Locate the new

AXA export format in the list of available formats and move it to the left (Selected). Close the form. Select the file format in the Export format field on the File formats tab page and save the record.

3. Click the Payment specification button and create two records related to the two record formats (Bank transfer and Check) implemented. Remember to specify the Export format for each record type. Close the forms.




7-31

4. Create a new payment journal by using the path Accounts payable > Journals > Payments > Payment journal. Open the journal lines by clicking Lines.

5. Create a payment for vendor, “8500” with a debit amount of 766.50 using the United States dollar (USD). Specify the payment method and record format in the Method of payments and Payment specification fields.

6. Manually create another payment for vendor “8500” with a debit amount of 474.86 USD. Specify the payment method and record the format in the Method of payments and Payment specification fields. Select the other record format compared to the line earlier.

7. Click the Functions > Generate payment button and select the implemented Export format in the dialog box. Click the Dialog button and specify the name of the file to be generated. Specify the bank account “USA OPER”.

NOTE: You will receive an error about credit amounts when you generate the file. This error is expected, because you added validation to check for credit amounts. To correct the error you can change the credit amount in the journal line to a debit amount and then generate payments again.

TIP: If you want to repeat the test, set the status of the lines back to None by selecting Payment status and clicking the None button.

Collections and Interest The account statement provides credit to customers on invoices. Customers usually receive periodic account statements.

If account statements are to specify those invoices that are outstanding, then transaction open-editing must be up to date. Account statement printouts are followed by a reconciliation to make sure that they are correct.

When customer invoices are overdue, reminders could be in order. Submitting collection letters is a supported process that includes the status registration of individual open invoices, and typically involves the progression through predefined steps. Submission of a collection letter frequently includes a related fee to be paid by the customer.

An alternative to submitting collection letters is the calculation of interest on unpaid invoices. This is usually done periodically. The calculated interest can be printed on an interest note that is submitted to the customer. The interest note can also have a related fee to be paid by the customer.




7-32

Interest Data Model

The following figure shows the data model covering setup and the calculation of interest.

FIGURE 7.10 INTEREST DATA MODEL

The CustInterest table defines the different interest codes that have the related specification of the interest calculation that includes the percentages and accounts that are used for posting.

The interest code used for each customer is determined by the posting profile that can be accessed by the path Accounts receivable > Setup > Posting profiles > Setup.

The CustInterestFee table is used to specify a fee that will be included in the interest calculation. The reason for this separate table is the need to specify a specific fee for each currency. The table is also used to specify a minimum interest that should be calculated. The CustInterestRange table contains information about the interest that is applicable by the ranges of an overdue balance or the time on the customer transactions and is specific to a customer currency.

Each calculated interest note has a header in the CustInterestJour table. The calculation is specified in CustInterestTrans that contains a record for each original transaction that has contributed to the interest calculation.




7-33

Even though the relation between CustTrans and CustInterestTrans is not specified on an extended data type or as a relation on the CustInterestTrans table, there is a conceptual relation between the two tables.

The printing and posting of the interest note updates information in the CustInterestJour. When the interest is posted one or more new interest transactions are created in the CustTrans table.

The CustInterestWriteOffUnPostedJournal journal is used when write-off transactions are created in the Collections form.

The CustInterestVersion and CustInterestVersionDetail tables contain the versions of interest codes that are charged and paid.

CustInterestCreate and CustInterestPost Classes

The CustInterestCreate class handles how to create an interest note. The class has two important methods.

• checkOpenTrans • checkSettlement

They evaluate whether an open or closed transaction should be included in the interest calculation.

The CustInterestPost class handles the posting of an interest note. This includes the creation of ledger and customer transactions.

Bills of Exchange A bill of exchange, also known as a draft, is an instrument used to administer agreements to make payments. The document is created by the selling company. However, it resembles a check written from the buyer to the seller.

Administration of bills of exchange can be divided into the following steps.

• Draw • Protest • Redraw • Remittance • Settlement

Separate journals for each step handle registration. These different kinds of journals are collected in the submenu Journals > Bills of exchange.




7-34

Draw

This step creates the document. Invoice transactions are selected when you enter information into the journal.

When the journal is posted, the customer transaction that originated the invoice, is settled and replaced by a new, open transaction represented by the bill of exchange.

Protest

A bill of exchange is created by the selling company. A buyer can protest the bill of exchange if he or she does not accept it.

For a protest, the transaction representing the drawn bill of exchange is selected when you enter the information into the journal. When the journal is posted, the bill of exchange’s status is changed from Drawn to Protested.

The customer transaction that originated the drawn bill of exchange is settled and replaced by a new, open transaction represented by the protested bill of exchange.

Redraw

A protested bill of exchange can be re-drawn.

To do this, the transaction representing the protested bill of exchange is selected when you enter the information into the journal. When the journal is posted, the bill of exchange’s status is changed from Protested to Redrawn.

The customer transaction that originated the protested bill of exchange is settled and replaced by a new, open transaction representing the redrawn bill of exchange.

Remittance

One of the purposes of bills of exchange is for sellers to use them to obtain bank credit.

The transaction representing the drawn or redrawn bill of exchange is selected when you enter the information into the journal. When the journal is posted, the bill of exchange’s status is changed from Drawn/Redrawn to Remitted.

The customer transaction that originated the drawn or redrawn bill of exchange is settled and replaced by a new, open transaction representing the remitted bill of exchange.




7-35

Settlement

Final settlement of a bill of exchange ends the payment workflow. This step represents the customer’s final payment of the invoice that is the basis for the bill of exchange.

The transaction representing the remitted bill of exchange is selected when you enter the information into the journal. When the journal is posted, the status of the bill of exchange is changed from Remitted to Honored.

The customer transaction that originated the remitted bill of exchange is settled and replaced by a new, open transaction representing the honored bill of exchange.

Promissory Notes A promissory note is an instrument used to administer agreements to make payments. The document is created by the buying company and states that the buyer has agreed to make a payment in the future.

Administration of promissory notes can be divided into the following steps.

1. Draw 2. Redraw 3. Remittance 4. Settlement

Each of the steps are handled and registered by using a journal dedicated to each step. The different kinds of journals are collected in the submenu Journals > Promissory notes.

Draw

This step creates the document. Invoice transactions are selected when you enter information into the journal.

When the journal is posted, the customer transaction that originated the invoice is settled and replaced by a new, open transaction represented by the promissory note.

Redraw

A settled promissory note can be re-drawn.

The transaction representing the honored promissory note is selected when you enter the information into the journal. When the journal is posted, the promissory note status is changed from Honored to Redrawn.




7-36

The vendor transaction that originated the honored promissory note is settled and replaced by a new, open transaction representing the redrawn promissory note.

Remittance

A drawn or redrawn promissory note can be remitted.

The transaction representing the drawn or redrawn promissory note is selected when you enter the information into the journal. When the journal is posted, the promissory note status is changed from Drawn/Redrawn to Remitted.

The vendor transaction that originated the drawn or redrawn promissory note is settled and replaced by a new, open transaction representing the remitted promissory note.

Settlement

Final settlement of the promissory note ends the payment workflow. This step represents the vendor’s final payment of the invoice that is the basis for the promissory note.

The transaction representing the remitted promissory note is selected when you enter the information into the journal. When the journal is posted, the promissory note status is changed from Remitted to Honored.

The vendor transaction that originated the remitted promissory note is settled and replaced by a new, open transaction representing the honored promissory note.




7-37

Lab 7.2 - Transfer Balances This lab demonstrates how to update open transactions editing information directly from X++.

Estimated time to complete: 45 minutes

Scenario

The business relations, used as vendors, and the customers, are recorded in the accounts payable table. If the company is buying from and selling to the same business relation, this will be created in both tables.

An invoice is usually settled by a payment, but when buying from and selling to the same business relation, the invoices from the purchase and sales order could be set off one another.

A new function should find customers and vendors related to one another (the same business relation). If both the customer and vendor have open invoices, they should be set off one another. Only invoices in the same currency can be settled against one another.

Implementation

To find and settle customer and vendor open invoices of the same currency, follow these steps.

TIP: The code samples for this lab can be found in the AX2012_ENUS_DEVIV_07_02_LAB_CODE.txt file. You can copy and paste these code samples into the correct methods.

1. Import the project AX2012_ENUS_DEVIV_07_02_LAB.xpo. The project contains a framework for the class AXACustVendTransferBalance.

2. Do not be concerned about the dialog and so on. This is already implemented so that you can focus on the Accounts receivable and Accounts payable modules.

3. Implement the method run, to find and create the settlements. For each customer who has a related vendor, follow these steps.

a. Find an open customer transaction and calculate the remaining amount.

b. Find an open vendor transaction with the same currency and calculate the remaining amount.

c. Calculate the settlement between the two transactions as the minimum amount of the two.

d. Create two lines in a ledger journal and update the related settlement specifications.




7-38

TIP: You can import the AX2012_ENUS_DEVIV_07_02_LAB_SOL.xpo file to verify and compare your solution.

Test

To test the implementation, follow these steps.

1. Create a reference between customer 3001 and vendor 3004, by using the path Accounts receivable > Customers > All customers in the Vendor account field on the Miscellaneous details FastTab in the Customer details form.

2. Create a number sequence by using the path Organization administration > Common > Number sequences > Number sequences. This number sequence should not be marked as manual, but is should be marked as continuous.

3. Create a journal name by using the path General ledger > Setup > Journals > Journal name. The journal type should be daily, and select the number sequence that you created in step 2 for the voucher series.

4. Run the class by right-clicking selecting Open. On the dialog box, in the Name field, select journal name that you created in step 3, and select the number sequence that you created in step 2, in the Voucher series field. Click OK.

5. To view the journal, open General ledger > Journals > General journal. Select the journal number that was created in the infolog message, and then click Lines. To view the settlements that were created, click Functions > Settlement on each line, and then click No to not remove the settlements.

NOTE: You may receive warnings that the number sequence you created does not allow reservations. This message can be ignored.

TIP: If you want to repeat the test, you should delete the journal generated.




7-39

Summary The Accounts receivable module is used to track customer invoices and incoming payments. The Accounts payable module is used to track vendor invoices and outgoing expenditures.

The Accounts receivable module has functionality for free text invoices. Free text invoices are useful because they are not related to inventory items and provide a simple invoice mechanism.

The Accounts payable module uses invoice journals to process invoices that are not related to inventory. The following types of invoice journals are available.

• Invoice Register • Invoice Approval Journal • Invoice Pool excluding Posting • Invoice Journal

The collection of customer payments and the generation of vendor payments is one of the most important tasks in the finance process. They control the flow of cash into and out of your business. After the payment set up is complete, you can use payment journals in both modules to propose, create, generate, and post payments.

The Accounts receivable module offers functionality for collection letters, interest notes, and bill of exchanges. The Accounts payable module offers functionality to create and process promissory notes.




7-40

Test Your Knowledge Test your knowledge with the following questions.

1. Categorize the following items.

_____ 1. Used to make a payment on a specific day. _____ 2. Used to pay invoices in installments. _____ 3. Used to calculate due dates of transactions. _____ 4. Used to add more charges to a transaction. _____ 5. Used to define how payments are summarized and posted. _____ 6. Used to accrue and reward discounts when payment terms are met.

a. Payment Schedulesb. Cash Discount c. Terms of Payment d. Payment Fees e. Method of

Payment f. Payment Days

2. What is the primary difference between free text invoices and sales order invoices?

3. Which tables are used for vendor invoice journals?

( ) CustInvoiceTable and CustInvoiceTrans ( ) VendInvoiceTable and VendInvoiceTrans ( ) LedgerJournalTable and LedgerJournalTrans ( ) VendJournaTable and VendJournalTrans

4. Which of the following transactions are supported in the Accounts receivable module for customers? (Select all that apply)

( ) Free text invoice ( ) Payment journals ( ) Promissory notes ( ) Bill of exchanges




7-41

5. Which of the following frameworks and classes are used by the free text invoice generation process? (Select all that apply)

( ) CustVoucher ( ) LedgerVoucher ( ) CustInvoiceCalcTax ( ) FormLetter framework




7-42

Quick Interaction: Lessons Learned Take a moment and write down three key points you have learned from this chapter

1.

2.

3.




7-43

Solutions Test Your Knowledge

1. Categorize the following items.

f 1. Used to make a payment on a specific day. a 2. Used to pay invoices in installments. c 3. Used to calculate due dates of transactions. d 4. Used to add more charges to a transaction. e 5. Used to define how payments are summarized and posted. b 6. Used to accrue and reward discounts when payment terms are met.

a. Payment Schedulesb. Cash Discount c. Terms of Payment d. Payment Fees e. Method of

Payment f. Payment Days

2. What is the primary difference between free text invoices and sales order invoices?

MODEL ANSWER:

Free text invoices cannot be related to inventory items, and sales order invoices can be related to inventory items.

3. Which tables are used for vendor invoice journals?

( ) CustInvoiceTable and CustInvoiceTrans ( ) VendInvoiceTable and VendInvoiceTrans (•) LedgerJournalTable and LedgerJournalTrans ( ) VendJournaTable and VendJournalTrans

4. Which of the following transactions are supported in the Accounts receivable module for customers? (Select all that apply)

(√) Free text invoice (√) Payment journals ( ) Promissory notes (√) Bill of exchanges

5. Which of the following frameworks and classes are used by the free text invoice generation process? (Select all that apply)

(√) CustVoucher (√) LedgerVoucher (√) CustInvoiceCalcTax (√) FormLetter framework




7-44



Documents

AX2012_ENUS_DEVIV_07.pdf