Commission & Broker Management (CBM) for Microsoft® Dynamics BC is an extension designed to simplify the calculation, recognition of liabilities, and payments of all incentive-based compensation programs. The system was created as a stand-alone granule within Microsoft Dynamics BC and has almost no impact on the core application. This approach significantly simplifies installation and ongoing upgrades to the core Dynamics BC system. CBM is fully integrated with the General Ledger, Accounts Payable, and Accounts Receivable, enabling commissions to be posted to the General Ledger and paid through Accounts Payable or converted to Receivable or GL.
At the heart of CBM is ‘Commission Rules’, a robust, rules-based commission management window where users can easily create and manage different commission programs. All commission rules include effective dates, allowing users to schedule the commencement and completion of any commission program. Users can indicate whether the rule applies to invoices or credit memos. Users also control the basis and timing for each commission. For example, a commission can be based on the total amount of an invoice or for specific items within an invoice. Further, payments can be triggered once the invoice has been processed or only after the customer has been paid-in-full.
During normal processing, users simply run the ‘Calculate Commissions’ routine to have the system query eligible transactions. System-generated commission entries are displayed in the Commission Journal for review and approval. If necessary, users can create manual adjustments within the Commission Journal to record any special circumstances. Approved commission entries are posted to the Commission Ledger. Commission Ledger entries can be converted to Accounts Payable for payment or to GL or Accounts Receivables to be paid from other sources. Behind the scenes, CBM automatically records commission expense and liability to the General Ledger.
CBM is a powerful tool for businesses that empowers managers to quickly respond to market changes by providing the right incentives for their employees to maximize profitability.
A complete installation of CBM involves 2 steps.
- Install the CBM .FOB file – CBM was created exclusively in C/SIDE. Installing the system involves importing the CBM .FOB file into the standard Dynamics BC application.Most of the functionality for CBM is contained within unique, registered objects. As such, these objects can be imported without affecting standard objects or other customizations within the Dynamics BC system. All objects are defined in the Object List. An explanation of the change(s) to standard objects is provided under Notes in the Object List. You should carefully consider the impact on standard objects or existing customizations before importing any objects.
- Install the Commissions Permission Set – Within Dynamics BC, select Configuration Packages under the RapidStart Services for Microsoft Dynamics BC. Choose the ‘Import Package…’ option and import the PackageCOMMISSIONS.rapidstart file. Highlight the newly imported Commissions configuration package and select ‘Apply Package’. The system will create a Permission Set entitled Commissions with permissions assigned for CBM-specific tables. This Permission Set should be assigned to any user that is responsible for managing CBM.
CBM offers a variety of user-definable options to provide maximum flexibility in processing commissions.
Before using CBM, these options must be set. These settings are accessed directly from the Commission menu or under the Setup submenu.
CREATE NEW ROLE
Under Tools / Security / Roles, users will need to create a new Role for processing commissions. Because the person(s) responsible for processing commissions may have diffrent responsibilites within each organization, there is no universal role that will work in all company settings.
The Commission Setup window contains several global options.
The following options can be set from the Commission Setup window:
Expense Account Dimensions From – This field tells CBM which dimension code values should be used when commissions are posted to the General Ledger. The possible options are:
None – no dimensions will be posted
Sales Transaction – dimensions will be copied from the sales transaction used as the source of CBM (if commissions are calculated from the header then document dimensions will be used, if commissions are calculated from lines then dimensions associated with the document line will be used).
Salesperson – dimensions will be copied from the salesperson record.
Calculate Commission – Remember Date From – This field is considered when users run the ‘Calculate Commission…’ procedure. If a company wants CBM to consider any eligible sales transaction, regardless of the age of the sales document, it can set a global beginning date for all commission calculations. This is particularly useful if the company only pays commissions for sales transactions that are paid in full by the customer. By using a broad date range, i.e. old Date From, users can be assured that all sales transactions will be considered regardless of whether the customer was delinquent in paying the sales document. One suggested value for this field would be the date that the CBM was installed at the company. In this case, CBM would review all sales transactions, regardless of creation date, to see if the status of any transaction has recently changed, making it eligible for commission payment.
Commissions Editing – This field specifies the permission level for users to manually edit commission rates on sales orders. For this option to have any meaning, the .FOB file containing all commission objects must be installed. Specifying any option besides ‘Not Allowed’, enables users to enter salesperson(s) and rate(s) through the Edit Commissions option under the Function menu on the Sales Order window. If a commission rule has been defined to consider manually entered commission rates on the sales order, the calculation will utilize any manually entered values and ignore the standard rates included with the rule. The possible options are:
Not Allowed – Users are prevented from manually entering any rates
All – One screen – Users can enter manual commission entries for either the sales header or any individual sales line. All entries are displayed in one window, allowing users to quickly process commission entries for the entire order. This option requires users to understand how Dynamics BC assigns unique line numbers. It is recommended that the Line No. field be displayed in the Sales Order window.
Convert Commissions to Pay Option – allows users to choose between converting all the commissions generated or only converting commissions after the source invoice has been fully closed. This option should only be used when rules are configured to always calculate commissions. The combination of always calculate commissions and convert only completely paid allows to recognize commissions expenses immediately but pay them only after invoices have been paid.
Generate One Entry Per SP – checking this check box allows users to generate one AP/AR/GL Entry per salesperson per run.
Convert Pos. AP Document Type – corresponding document type (for example Invoice) will be generated when commissions are converted to AP. The standard choice for this is field is Invoice.
Convert Pos. AR Document Type – corresponding document type (for example Refund) will be generated when commissions are converted to AR. The standard choice for this is field is Payment.
Convert Pos. GL Document Type – corresponding document type (for example – none) will be generated when commissions are converted to GL.
Convert Neg. AP Document Type – corresponding document type (for example Invoice) will be generated when commissions are converted to AP. The standard choice for this is field is Payment.
Convert Neg. AR Document Type – corresponding document type (for example Refund) will be generated when commissions are converted to AR. The standard choice for this is field is Invoice.
Convert Neg. GL Document Type – corresponding document type (for example – none) will be generated when commissions are converted to GL
COMMISSION POSTING GROUP
Commission Posting Groups define the G/L accounts used when
commissions are posted to the General Ledger. Two G/L Accounts (commission expense and commission liability) can be defined for each group.
The window contains the following fields:
Posting Group Code – This is a user-definable, alpha-numeric field that allows users to add a descriptive name to eDOCach posting group that is created. The values in this field must be unique.
Commission Expense Account – This is a lookup field that enables a user to select a G/L account value. Typically, this is an expense account from the G/L that represents the commission expense.
Commission Liability Account – This is a lookup field that enables a user to select a G/L account value. Typically, this is a liability account from the G/L that represents the commission payable.
If a company pays commissions to internal and external (non-employee) salespeople, one suggested approach is to create at least two posting groups, mapping to different G/L accounts. For example, commissions to internal salespeople might be recorded under a G/L account called ‘Commissions Expense’ and commissions to external entities, e.g. sales reps, might be recorded under a G/L account called ‘Broker Fees’. See Salesperson Setup topic for more information about Posting Groups.
Commission Groups define subsets of salespeople that can be associated with Commission Rules to determine eligibility for a particular
commission. For example, a company might create a Commission Group called ‘Reps’ that includes all external sales entities and another group called ‘Sales staff’ that includes all internal salespeople.
Once defined, Commission Groups can be re-used when constructing different commission rules.
The following fields can be configured:
Commission Group – This is a user-definable, alpha-numeric field that allows users to add a descriptive
name to each Commission Group. The values in this field must be unique.
Description of the group
Calculation Method – This is an optional field that sets a default Commission Calculation method for all members of the group. Commission Calculations determine how a commission is calculated and can be set per Commission Rule, Commission Group, or Salesperson, depending on the specific needs. If a value is selected in this field for the group, it can still be overwritten for an individual member of the group under the Group Setup button. See the Commission Calculation Method topic for more information about Commission Calculation methods.
Salesperson – This is an optional field that instructs CBM to use the standard Salesperson field on the source sales document. In some situations, it may not be possible to set a universal policy for determining which salesperson is eligible to receive a particular commission. (One example of a universal policy is saying that one salesperson is responsible for all sales to a specific Customer Posting Group.) If the eligible salesperson is the one that is listed as the Salesperson Code on the source sales document, then this field should be selected. This option is useful when individual transactions may have different salespeople. If this field is unchecked, the salespeople defined in the Group Setup will be used.
After Commission Groups have been defined, salespeople can be added to the group using the Group Setup button (optional if ‘Use Transaction Salesperson’ has been checked for the group). For each salesperson in the group, users can specify individual Calculation Methods and Allocation Codes (see picture below).
Salesperson Code – This field adds a Salesperson to the current group. A salesperson can be a member of multiple groups, in which case, he/she may get multiple commissions.
Commission Calculation Method – Leave this field blank if the same method (specified on the group level) should be used for all the members of the group. Otherwise Commission Calculation Methods can be attached to the individual group members.
Commission Allocation Code – A Commission Allocation Code can be used if commissions calculated for the salesperson need to be shared with one or more additional people (for example, a sales assistant).
COMMISSION SOURCE CODE
Commission Source Codes allow users to specify what transactions should be used when creating a commission rule. After configuring the Commission Source Codes, they can be associated with specific rules to tell CBM which sales transactions to consider when applying that commission rule.
The source code offers two broad types of filters. The first filter, Source Transaction Type, tells CBM whether to consider both invoices and credit memos or some subset of these transaction types.
The second filter, Include Trans. Status, evaluates the payment status of the transaction in determining whether to include the transaction when processing commissions. For example, users can limit the commission rules to only consider transactions that have been paid in full (closed).
Commission Source Code – This is a user-definable, alpha-numeric field that allows users to add a descriptive name to the Commission Source. The values in this field must be unique.
Source Transaction Type – This field tells CBM which type of sales transactions should be considered in the commission calculation. Options:
Invoice Only – Only invoices are used
Invoice and Credit Memo – All invoices and credit memos
Credit Memo Only – Only credit memos
Invoice and Corrected Credit Memo – Invoices and credit memos marked as corrected. This option only considers those credit memos that are created to correct an erroneous invoice. The Correction flag on the Posted Credit Memo record is used as an indicator.
Include Transaction Status – This field determines the status of the transactions that CBM should use when calculating commissions. This field determines the timing and conditions under which commissions are eligible to be paid. This filter does not determine when a commission should be paid but rather when to recognize the expense and liability for the commission. By delaying transactions from the calculation process based on their status, the filter is delaying when the commission should be posted to the commission ledger and, subsequently, the general ledger. To control the timing of payment for a commission, see the Commission Setup section. For most commission plans, it is necessary to recognize the commission when the sales invoice is posted to be GAAP-compliant. Therefore, ‘Any Status’ should be selected. Please consult your CPA to determine which status is correct for your situation. Options:
Any status – Any posted sales transaction that matches the ‘Source Transaction Type’ is eligible to be paid.
Only Completely Closed – This option only considers documents that match the ‘Source Transaction Type’ and have been completely paid or applied in full. This option should be used if a company only pays commission on sales that have been paid in full by the customer. Commission entries will not be processed until the original sales document has been closed.
Partly Closed – This option considers documents that match the ‘Source Transaction Type’ and either have some payment or application activity (e.g. credit memo was applied to it). In other words, as soon as there has been any activity against the sales document, all commission entries will be processed.
Use Closed Portion – This option only considers that portion of any sales document that has been paid or had application activity. This allows companies to pay a proportional share of the total commissions for a sales transaction. For example, if the customer pays 50% of the total amount due for a sales document, the salesperson will receive 50% of the total commission amount. When the customer pays the remaining amount, another commission entry will be generated for the salesperson.
COMMISSION CALCULATION METHOD
A Commission Calculation Method defines the logic that is used to calculate a commission. Calculation Methods can be based on the revenue for a sale or the quantity of an item that is sold. The methods also contain a number of additional option fields to determine the amount that is paid. For example, users can control whether the commission is a percentage of the sale or fixed $ amount and includes/excludes related sales charges such as sales tax, credit card fees, and discounts.
Calculation Method – This is a user-definable, alpha-numeric field that allows users to add a descriptive name to the Calculation Method. The values in this field must be unique.
Amount Calculation Base – This field defines whether commissions should be calculated as a percent of the transaction amount or a fixed amount based on the quantity sold. Values:
Amount – Calculation will be based on the transaction $ amount
Quantity – Calculation will be based on quantity sold (If commissions are calculated based on the whole transaction (header) and this field is set to “Quantity”, a fixed $ amount will be paid per transaction.)
Commission Percent – This is the percent used if Amount Calculation Base field is set to “Amount”. If the ‘Manual Commissions’ option has been checked for the commission rule and the transaction is a sales order, CBM will check to see if a user(s) has manually entered any commission rates for the sales order and utilize those rates instead of this rate.
Commission Per Base UOM – This is the $ amount used if Amount Calculation Base field is set to “Quantity”.
Base Includes Discount – Checking this box instructs CBM to include any header or line discounts in determining the amount eligible for commission. Selecting this option will reduce the commissionable amount.
Include Tax – Checking this box instructs CBM to include any taxes in determining the amount eligible for commission. Selecting this option may increase the commissionable amount.
Payment Method Adj. – This lookup field allows the user to make adjustments to the commissionable amount based on the standard Dynamics BC payment method associated with the sales document. Depending on how the Payment Method Adjustment code is defined, using this field may either increase or decrease the commissionable amount. This enables companies to encourage or discourage the use of certain payment types, e.g. credit cards. See Commission Payment Method Adjustment for more information.
Limit Trans. Amount – This field is a numeric field that sets a maximum $ amount for a commission paid per one invoice.
Source Amount Base – This field has two options:
Gross – The base amount for commissions is the total transaction amount
Net – The base amount for commissions is net revenue (profit)
COMMISSION PAYMENT METHOD ADJUSTMENT
Commission Payment Method Adjustments is used when the commission
amount depends on the payment method used. Users can define any number of Payment Method Adjustment Codes and a corresponding list of standard Dynamics BC Payment Methods. In turn, the users can specify commission increases or decreases for each Payment Method (see picture below). The adjustment can be either a fixed amount or percentage of the transaction.
Payment Method Adjustment Details fields:
Payment Method Adjustment Code – This is a user-definable, alpha-numeric field that allows users to create a descriptive name. The values in this field must be unique.
Description – Description of the Payment Method Adjustment.
Payment Method Code – Code defined in the Payment Method Table that is used to calculate adjustments
Adjustment Type – Users can choose from two options:
Fixed Amount – fixed dollar amount per transaction
Percent – percent of transaction amount
Adjustment Amount – The amount of adjustment (either percent or fixed amount). The sign of the amount tells the system whether adjustment should be positive or negative.
Commission allocation is used to allocate a portion of the commission amount to another person. For example, it can be used to allocate a portion of the commissions to the salesperson’s assistant or an employee of the brokerage firm involved in marketing the product. Two types of allocation (dynamic and percent) are supported by the system. Dynamic Allocation is based on custom rules specific to the customer (requires custom coding). The Percent Allocation utilizes the Allocation Details to specify a list of people and corresponding percentage of the total commission allocated for each person. The main person used to calculate commissions must be included in the list in order to get commission.
Commission Allocation Code – This is a user-definable, alpha-numeric field that allows users to create a descriptive name. The values in this field must be unique.
Dynamic Allocation Calculation – (Optional) Code matching the custom calculation function
Allocation Detail Record. This field requires custom programming.
Salesperson Code – Salesperson for whom commissions will be allocated. This may be an actual salesperson or another employee within the organization that is entitled to a portion of a commission. (Note, for someone to receive a commission, he/she will need to be defined as a Salesperson in the Salesperson Setup window.)
Allocation Percent – The percent of the total commission amount calculated based on Commission Rules to be allocated to the salesperson
Each person that gets paid commissions must be added and configured in the Salesperson Setup Table. Only individuals that are first created in the standard Dynamics BC Salesperson/Purchaser table can be configured in the Salesperson Setup. The following properties of the salesperson can be defined:
Salesperson Code – This code is identical to the standard Dynamics BC Salesperson table.
Commission Posting Group – The posting group associates the salesperson with the Expense and Liability Accounts used to post commissions to the General Ledger.
Salesperson Type – (Optional) This field is utilized to tell the system under which module (AP) the salesperson will be paid. Values are required in this field if a company has purchased and is using the ‘Convert Commissions to AP/PR’ granule. The options are:
Employee – if the salesperson is an employee of the company
Vendor – if the salesperson is an outside rep or broker and commissions need to be converted to AP
G/L Account – this type is used if the organization wants to record a commission in the general ledger without transferring the liability to either Payroll or A/P. By combining this option with the Commission Posting Group code, users are able to utilize CBM in nonstandard ways. Rather than entering traditional expense and liability accounts in the Commission Expense Account and Commission Liability Account fields, users can record any GL journal entry by filling in a debit and credit account (Commission Expense = Debit, Commission Liability = Credit).
Customer – this type is used if organization wants to pay royalty back to their customers.
No. – This field is used in conjunction with Salesperson Type and links the salesperson with the specific Employee or Vendor record (based on the Salesperson Type). The association is used when commissions are converted to the Accounts Payable or GL. (Note, the Vendor can either be an individual or an organization. For example, if a company utilizes a manufacturer’s rep firm for sales, the salesperson may be an individual within the firm and the Vendor may be the firm itself. This approach enables companies to track the performance of individual sales reps but cut one check to the firm for many salespeople.)
Balance– This balance represents the amount of commissions that have been approved but not yet paid for each salesperson. This balance is increased after commission entries have been created and posted and is reduced when commissions are converted to AP and GL.
COMMISSION RULES SETUP
Commission Rule Setup is where a user defines the rule(s) for calculating commissions. For each rule that is defined, users essentially answer 3 general questions: What sales documents should be considered when evaluating this rule? Who is eligible for a commission under this rule? How should the commission be calculated under this rule? The following properties can be defined:
Commission Rule Code – This is a user-definable, alpha-numeric field that allows users to add a descriptive name to the Rule. The values in this field must be unique.
Description – The description for the rule.
Active – This checkbox allows a user to quickly activate or inactivate a rule without deleting the rule from the system.
Rule Type – There are two options: Sales or Service. This indicates whether the rule applies to sales documents or service documents. The documents for these modules are stored in different tables within standard Dynamics BC. Therefore, the rules for the modules must be defined separately.
Calculation Base – This field indicates where within a sales document CBM should look to find the matching criteria to determine whether a sales transaction should be included in the calculation of this rule. This field is used in conjunction with Header Source Type, Header Source Value, Line Source Type and Line Source Value fields to define the filter. There are thee options available:
Header – when this option is used then the combination of Header Source Type and Header Source Value defines the sales transactions that should be included in the calculation. For this option, the commission calculation will be based on the total amount of the sales transaction regardless of the number of sales lines within the document.
Line – when this option is used then the combination of Line Source Type and Line Source Value defines the sales transaction line that should be included in the calculation. For this option, the commission calculation will be based on an individual sales line.
Header/Line Combination – when this option is used then the combination of Header Source Type, Header Source Value, Line Source Type and Line Source Value defines the transaction lines that would be calculated based on the current rule. For this option, while information from the sales Header will be used in the filtering process, the commission calculation will be based on an individual sales line.
Header Filter Set – If the Calculation Base is either Header or Header/Line Combination, the system will look to this filter set to determine which field(s) from the sales or service document header should be utilized as filters. If no filter is set, all sales or service transactions will be included in this rule. To edit the Header Filter Set, select the Set Rule Header Filter button on the ribbon bar to open the filter editor.
Within the editor, simple or complex filters can be created using any fields from the Sales Header table, including custom fields. Selecting the ‘Add Filter’ button on the page adds a new row to the Show Results section. Selecting the drop-down pointer next to displays a list of the data elements within the Sales Header table. Highlight the appropriate field and click on it to insert it into the filter row. Next, click on Enter A Value to enter the filter values. You may either enter a simple value or a complex equation using any of Dynamics BC’s supported filter symbols, e.g. >,<,..,|@, etc. After you have entered the filter criteria, select OK to close the window. You will be prompted with a message confirming that you want to save and apply any changes to the filter.
Line Filter Set – if the Calculation Base is either Line or Header/Line Combination, the system will look to this field to determine which field(s) from the sales document line(s) should be utilized as filters. If no filter is set, all sales transactions will be included in this rule. To edit the Line Filter Set, select the Set Rule Line Filter button on the ribbon bar to open the filter editor.
Within the editor, simple or complex filters can be created using any fields from the Sales Line table, including custom fields. Selecting the ‘Add Filter’ button on the page adds a new row to the Show Results section. Selecting the drop-down pointer next to displays a list of the data elements within the Sales Line table. Highlight the appropriate field and click on it to insert it into the filter row. Next, click on Enter A Value to enter the filter values. You may either enter a simple value or a complex equation using any of Dynamics BC’s supported filter symbols, e.g. >,<,..,|@, etc. After you have entered the filter criteria, select OK to close the window. You will be prompted with a message confirming that you want to save and apply any changes to the filter.
Commission Calc. Source – this field contains the CBM Source Code created in the CBM Source Table (see corresponding topic for more information). This field further defines the sales transactions that should be included with this rule.
Commission Group – this field contains the Commission Group (defined in the Commission Group record) that should be included with this rule. The Commission Group defines the individual(s) eligible to receive a commission for this rule.
Default Comm. Calc. Method – The Commission Calculation Method determines how the commission for this rule should be calculated. If the calculation is the same for most or all individuals associated with this rule, then a default value can be entered in this field. This field can be overridden within the Commission Group by selecting a different per individual(s).
Document Date From – This field allows users to set a date range for this rule. The rule will be applied to the transaction only if transaction’s document date is within the defined date range.
Document Date To – This field allows users to set a date range for this rule. The rule will be applied to the transaction only if transaction’s document date is within the defined date range.
Manual Commissions – (Optional Feature) If a company has installed the full suite of CBM objects including objects related to ‘Manually editing commissions’, users can select this option to instruct CBM to consider manually edited commissions when calculating the commission for this rule. Users can manually edit commissions from within the Sales Order window to create special commissions which cannot be covered under standard commission rules. By selecting this field, users tell CBM to check if there are any special commission terms associated with the Sales Order. If CBM finds such terms, it will utilize them in the calculation and ignore the default methods and groups associated with the commission rule.
Execution Sequence – (Optional Advanced Feature) The default value for this field is ‘0’. Generally, users will accept the default value when setting up rules. A value of ‘0’ indicates that the commission rule operates independently of any other rule when the ‘Calculate Commissions’ process is run. The ‘Calculate Commissions’ process will always include the rule in its processing. Therefore, if two active commission rules have an Execution Sequence of ‘0’ and have overlapping filter settings, the system can, and will, generate more than commission entry for the same sales transaction. In some instances, a company may desire to pay more than one commission per transaction in which case the rules should share some of the same filter criteria for selecting the sales documents. For example, in some organizations, a sale may generate a commission to a salesperson and a smaller commission to his/her sales manager. Conversely, if the company intends to pay only 1 commission per transaction, the filter criteria for each rule should be unique to prevent 2 rules from overlapping each other.
While this type of ‘parallel processing’ is the most common approach, there may be some instances where a commission rule is dependent upon the outcome of another commission rule. For example, assume that a bicycle manufacturer normally pays the same commission percentage for all bicycles within the same product category. However, one of the models within that category is being discontinued and the manufacturer would like to offer a higher commission rate to clear out any remaining inventory. The company could create two commission rules to represent this situation. The first rule would set a standard commission rate for all models within the product category. The second rule would set a different rate for the discontinued model. If both rules had an Execution Sequence of ‘0’, the system would pay two commissions for each sale of the discontinued model since it is also a member of the product category. However, if the Execution Sequence for the discontinued model’s rule is changed to ‘1’ and the Execution Sequence for the product category’s rule is changed to ‘2’, the system will evaluate the rules in a serialized manner starting with ‘1’ and only proceeding to ‘2’ if no commission was created in the first rule. In other words, when the system found a sale that contained the discontinued model, it would generate only one commission and skip the remaining rules.
The Execution Sequence works in conjunction with the Calculation Base field to determine which rules should be grouped into an Execution Sequence. The order of processing for rules within an Execution Sequence is determined by the number in the field where ‘1’ is the first rule to be evaluated.
Processing commissions in CBM is a simple process requiring only a few steps to complete. Commissions can be reviewed and processed at any desired time interval. The user starts in the ‘Commission Journal’ and queries the system to find any eligible sales
transactions. Based on the rules that have been defined, CBM automatically retrieves all eligible sales transactions and
calculates the appropriate commissions.
The user is able to review and approve all calculated commissions. Modifications to calculated commissions can be manually entered directly into the commission journal as a separate entry to maintain a full audit trail.
Once the user is satisfied with all entries in the worksheet, he/she completes the process by posting the journal. Posting the commission journal creates commission ledger entries that are maintained for historic tracking and reporting purposes. In addition, CBM makes all necessary liability and expense entries in the General Ledger and updates the related sales documents.
The final step in the commission process is to run the ‘Convert to AP/PR’ procedure under Periodic Activities to automatically setup
the commissions to be paid using other standard Dynamics BC procedures.
WORKING IN THE COMMISSION JOURNAL
Commissions can be entered into the Commission Journal either manually or using the ‘Calculate Commissions…’ procedure.
The Commission Journal contains the following fields:
Journal Template Name – This field is not displayed by default.
Journal Batch Name – This field is not displayed by default.
Line No. – This field is not displayed by default.
Document No. – Journal Document Number. This field can be auto-populated by CBM by entering a No. Series in the No. Series field with the Batch Name.
Posting Date – This is the commission posting date.
Salesperson Code – This is the individual eligible for the commission.
Commission Posting Group – This field is not displayed by default.
Description – This field is supports automatic and manual entries.
Source Type – This field is only populated when commissions are calculated by the system. The options are:
Source No. – This field is only populated when commissions are calculated by the system and represent the source document number (e.g. posted invoice number).
Source Line No. – This field is only populated when commissions are calculated by the system and represent the line number of the source document if the calculation was based on posted document lines.
Source Amount – This field is only populated when commissions are calculated by the system and represent the amount of transaction used as a source for the calculation
Trans. Amount Used – This field is only populated when commissions are calculated by the system and represents the portion of the amount of the transaction used for the current journal line calculation. This is relevant when only a portion of the source amount is eligible for processing.
Commission Base Amount – This is the actual amount of the transaction before the commission percent is applied. It can be different from the Source Amount.
Commission Percent – This is the percent used to calculation the commission.
Commission Amount – This is the commission amount. If an entry is manually made in the commission journal, this field is editable and can either be positive or negative.
Commission Source Code – This field is only populated when commissions are calculated by the system and contains the Commission Source Code for the corresponding rule.
Commission Calculation Method – This field is only populated when commissions are calculated by the system and displays the Calculation Method for reference purposes.
Commission Allocation Group – This field is only populated when commissions are calculated by the system and represents the Allocation Code used to calculate the commission amount.
Source Code – This field is not displayed.
Entry Type – This field has two options, Earned and Paid. Earned commissions have been approved. Paid commission entries are generated to offset Earned commissions when the commissions are transferred to AP or GL for payment.
Entry Generated By – This field has two options, System and User. If an entry was created by the Calculate Commission process, it is flagged as a System entry. If an entry was manually entered into the Commission Journal, it is flagged as a User entry.
RUNNING THE ‘CALCULATE COMMISSIONS…’ PROCESS
‘Calculate Commissions…’ is a procedure that queries eligible sales transactions and suggests commission payments based on the active commission rules. The option is located within the Commission Journal page and populates the Commission Journal with journal entries to be reviewed and approved by a user.
After the calculation completes, if the system finds any transaction matching the filters and active commission rules, the calculated commissions are entered into the Commission Journal. Users can manually create adjusting entries or delete the lines completely. Note: if a system-generated line is deleted, it may be regenerated the next time the ‘Calculate Commissions…’ process is run unless the appropriate commission rule is changed to exclude that sales transaction or a different set of filters (e.g. date range) is entered in the ‘Calculate Commissions…’ option window.
Under the options tab, users can specify the date range for the calculation and whether the commissions should be calculated for both invoices and credit memos or for only one transaction type. The date range always defaults to the current month (unless the Calculate Commission – Remember Date From flag is set to True. In which case, the calculation considers all eligible sales transactions from a set starting date). In addition, users can set filters to run the calculation against a subset of sales transactions, e.g. only documents related to a specific customer.
ENTERING MANUAL COMMISSIONS & ADJUSTMENTS
Users can directly enter commission entries into the Commission Journal to record special commissions that are not supported by the Commission Rules or to record any other adjustments. The ability to manually enter commission entries is useful for correcting miscoded sales documents, re-assigning a commission to a different salesperson(s), and adjusting the earned commission amount for special situations.
The Commission Amount on manual commission entries can either be positive or negative. A positive entry will increase the earned amount for a salesperson while a negative amount will reduce the earned amount and can be used to reverse a previously posted erroneous commission ledger entry.
To start a manual commission, the user selects a blank line in the Commission Journal. CBM will automatically set the Entry Generated By field to ‘User’. This flag is non-editable and will remain on the posted commission ledger entry as an audit trail and to indicate that this entry was not the result of a standard commission rule.
The user manually enters a Document No. (if the Batch has not automatically assigned one), a Posting Date, Salesperson Code, and a Commission Amount. Optionally, the user can enter an explanation for the entry in the Description field. Further, the user can have the system calculate the Commission Amount by entering a Commission Base Amount and Commission Percent.
Once entered, manual commissions are posted and processed like standard commission entries. In addition, manual entries may be entered and processed in the same batch as commission entries that were generated by commission rules.
Once all commission journal entries have been reviewed and approved, users complete the process by selecting the Post button on the Posting menu in the Commission Journal. Posting commissions creates a non-editable commission ledger record and creates the appropriate entries in the general ledger to record the commission liability and expense. In addition, the source sales documents are updated to reflect that commission entries have been recorded against them.
General Ledger records are created using the Expense and Liability Accounts specified by the Commission Posting Group associated with the salesperson and copied to the Commission Journal. Depending on the value in Expense Account Dimensions From column in Commission Setup, the dimension values may be copied to the G/L Entries generated for the Expense Account.
Commission Ledger Records are created for each line of the Commission Journal.
Source Documents (Posted Invoices or Posted Credit Memos) are also updated. The system enters the amount of the transaction used for commission (which can be either the full amount or part of the transaction amount) and closes the transaction for the CBM if the full amount is used.
From a processing point of view, the commission entries have been reviewed, approved, and are ready to be paid. If the company intends to pay the commissions within Dynamics BC, the next step in the process is to convert the commission to the appropriate ledger, e.g. A/P, G/L, etc., depending on the salesperson’s classification. It is not necessary to run the ‘Convert Commissions…’ procedure after posting each commission journal. The ‘Convert Commission…’ procedure can be run at any time and may include one or more batches of posted commission entries.
Note: While it is not necessary to run the ‘Convert Commissions to Pay’ process if the company pays commissions through an external process, e.g. through a 3rd party payroll system, the step is still recommended to complete the commission cycle and close the open, unpaid commission entries.
CONVERTING COMMISSIONS TO AP OR GL
Records posted to Commission Ledger can be converted into and paid from Accounts Payable. It is also possible to convert commissions to GL Entries (for example if commissions are paid by outsourced processing companies such as ADP or to Customer Transactions (if royalties are paid back to customers).
It is not necessary to run the ‘Convert Commissions to Pay’ procedure after posting each commission journal. The ‘Convert Commissions to Pay’ procedure can be run at any time and may include one or more batches of posted commission
entries. For example, commissions can be reviewed, approved, and posted on weekly basis while the ‘Convert Commissions to Pay’ process is run as part of the company’s payroll procedures.
In order to convert commissions, each salesperson needs to be associated with an existing Vendor, Employee, GL Account or Customer. The association is done in the Salesperson Setup (see Salesperson Setup Topic for more information).
The conversion process is initiated by selecting ‘Convert Commissions to Pay’ under Commission Processing. A request page opens where users can enter both Options and filter criteria.
Users can preview and print the projected results of conversion routine by not checking the Post check box on the Option tab.
If the Post check box is checked, the routine will do the following:
1. Create “Paid” type records in Commission Ledger.
2. Close the original “Earned” type records by applying the related “Paid” type records.
3. Generate and post either AP Journal transactions.
At this point commissions can be paid by running the Suggest Vendor Payment from the Payment Journal (for the commissions converted to AP) or submitting the commission amounts to a third party payroll processor (for the commissions converted to a G/L Account).
All of the entries created are designed to look and perform like ‘native’ transactions within their respective ledger, e.g. A/P transactions are constructed like vouchered invoices.
MANUALLY SETTING COMMISSION RATES WHEN CREATING A SALES ORDER
Under normal processing, commission rates should be incorporated into CBM’s commission rules. If, however, there are no standard business rules for setting commission rates, users can manually set commission rates when they enter a sales order. (Note, this feature is only available if the full suite of CBM objects has been installed.)
Under the Functions menu in the Sales Order window, the Edit Commissions option opens a window that allows users to associate one or more salespeople and their corresponding commission rates with the sales document. This information is stored with the document and is used when the sales document becomes eligible for commission processing.
Global Option “Commission Editing” is used to allow commissions to be edited in Sales Order or not. See Commission Setup/Commission Editing description for more information.
When you start commission editing feature system calculates expected commissions for the specific document based on currently active rules and enters them in the commission editing form. From here you can change either change commission percent, change the Salesperson, delete any of automatically generated lines or add new lines with new salesperson. All the entries created or changed by user will be saved in the system and will be re-associated with Posted Invoice after order gets posted.