To invoice customers for the same services on a regular basis, you must define a free text invoice template that can be reused to create the invoices. This template contains the following information:
Header information, such as tax groups, terms of payment, and the method of payment
Line information, such as the service description, revenue accounts, unit price, and invoice amount
Charges for shipping or handling
Accounting distributions together with financial dimension information, such as cost centers and business units
In effect, you’re creating an entire invoice and saving it as a template. You can set up the templates using the Recurring invoices page.
Assign a free text invoice template to a customer and enter recurrence details
After the template is created, you must assign the template to the customers that you want to invoice. Additionally, you must specify when and how often the invoice will be used. You can assign the templates on the Invoice tab of the Customers page. Add the template to the list, and update the following information:
The start date and, optionally, the end date for the recurring billing
The frequency of the recurring billing (for example, every day or once a month)
The maximum billing amount (if this information is required)
A customer can have multiple templates that have different frequencies.
Generate the recurring invoices
On the Recurring invoices page, there is a task that processes recurring invoice templates. You specify the invoice date and the template to generate the invoices from. Invoices will be generated and assigned a single recurrence ID number for each group of invoices that is processed.
Post recurring free text invoices
After recurring invoices are generated, the invoice recurrence IDs appear in a posting task on the Recurring invoices page. You can view all of the invoices for a recurrence ID by clicking the link. During your review of the invoices for the recurrence ID, you can delete individual invoices. The customer’s recurrence settings will be reset for that template, so that it can be regenerated later. You can post one, many, or all of the invoices for a recurrence ID. If workflows are enabled, you must click Submit before you can post the invoices.
Print recurring free text invoices
After recurring invoices are posted, you can print the invoices from the free text invoice list page. You can print the invoices that are selected, or you can select a range of invoices to print.
Workspaces can use rich infographics and visuals that are supported by Microsoft Power BI. These infographics and visuals include many controls that are provided by third parties. Therefore, workspaces can provide a highly visual, interactive experience for users.
Users can interact with data by clicking or touching visuals on the page. They can see cause and effect, and do simple what-if operations without leaving the workspace. Thanks to stunning, interactive visuals, your users will have fun exploring data and discovering hidden trends.
Reporting solutions are often used to capture and communicate the details of business transactions. Therefore, a reporting solution must be able to produce physical manifestations of business data by using existing devices, such as network printers. Examples of business documents include sales invoices, customer statements, and checks.
Electronic reporting (ER) is the tool that you use to configure electronic document formats that comply with the legal requirements of various countries or regions. The applications of electronic reporting include financial auditing, tax reporting, and electronic invoicing.
Standard financial reports are provided that use the default main account categories. You can use the report designer to create or modify traditional financial statements, such as income statements and balance sheets. You can then share the results with other members of your organization. Examples of financial reporting include balance sheets, cash flow, and summary trial balance year over year.
The Revenue recognition module has the following setup options:
Revenue recognition journals
Parameters for revenue recognition
Item groups and released products
Defining revenue schedule
Defining revenue price
Revenue recognition journals
A new journal type has been introduced for revenue recognition. The journal is required and is used in two scenarios.
The first scenario occurs after all the contractual obligations are met, when the deferred revenue is recognized by creating a revenue recognition journal that is based on the details of the revenue schedule. The journal contains an accounting entry that moves the balance from the deferred revenue ledger account to the revenue ledger account.
The second scenario occurs when a journal is created after reallocation occurs. Reallocation occurs when a sales order line is added to a previously invoiced sales order, or when a new sales order is created that includes a line that is part of the original contract. If an invoice was posted before the new sales order line is added, a correcting accounting entry must be created for the posted customer invoice.
The journal is set up on the Journal names page (Revenue recognition > Setup > Journal names). The journal type must be set to Revenue recognition. The revenue recognition journal lets you select the posting layer to post to.
Parameters for revenue recognition
Revenue recognition settings are configured on the Revenue recognition tab of the General ledger parameters page (Revenue recognition > Setup > General ledger parameters). The following settings are available:
Revenue recognition journal name – Select the journal that was created for revenue recognition. The journal is required when revenue is recognized from the revenue schedule, or when you do reallocation for a sales order that has already been invoiced.
Enable discount allocation method – Set this option to Yes to determine the revenue price through allocation of the fair market value that is defined in the revenue price for each released product. This allocation includes allocation of any line discounts across the items. If this option is set to No, the system uses the median price that is defined in the revenue price for each released product. If this option is set to No, but no median price is set up for the released products, allocation of the revenue price doesn’t occur.
Include header discounts – Set this option to Yes to determine the revenue price by allocating header discounts across products. If this option is set to No, the header discount isn’t included in the revenue price allocation.
Disable contract terms – Set this option to Yes if products that have a revenue type of Post contract support can be released even though contract start and end dates aren’t defined for them. Typically, contract start and end dates are required for items of the Post contract support revenue type. When the contract start and end dates aren’t defined, the details of the revenue schedule on the posting are calculated by using the number of occurrences and the invoice date.
Post invoice corrections to Accounts receivable when reallocating – When you do reallocation for invoices that have already been posted, the accounting entry for the posted invoice must be corrected. Use this option to specify how the correction is done.
Set this option to No to limit posting of the correcting transaction to General ledger. When this option is set to No, no additional documents are created in Accounts receivable for the internal accounting correction. When the invoice is paid, the settlement process uses the old accounting entry to post any cash discounts, or any realized gains or losses.
Set this option to Yes to automatically create a reversing document and new invoice for the correcting transaction in Accounts receivable. Because this correction is an internal accounting correction, the new documents aren’t sent or communicated to the customer. The reversing document is settled to the original invoice, and the new corrected invoice is paid by the customer. Note that all three documents are shown on reports, such as the customer statement.
A revenue schedule must be created for each occurrence that revenue can be deferred for. For example, if your organization offers support over six-month, 12-month, 18-month, and 24-month periods, you must create a revenue schedule for each period. The setup of the revenue schedule determines how the revenue price is allocated across the number of periods that you select. It also determines the default dates that are entered for the revenue schedule that is created when the invoice is posted.
If you recognize revenue by milestone, we recommend that you create a revenue recognition schedule for the number of milestones, regardless of the recognition dates. After you create the schedules, you can edit them so that they reflect the expected milestone dates. These records can be put on hold until you’re notified that the milestone has been met and revenue can be recognized.
Revenue schedules are created on the Revenue schedules page (Revenue recognition > Setup > Revenue schedules).
Enter descriptive values in the Revenue schedule and Description fields. The following additional settings are used to create the revenue schedule when the invoice is posted.
Occurrences – Enter the number of months or occurrences for the revenue deferral.
Automatic hold – Select this check box if all lines of the revenue schedule should automatically be put on hold when the invoice is posted. The hold must be manually removed from each line of the schedule before the line’s deferred revenue can be recognized.
Automatic contract terms – Select this check box if the contract start and end dates should automatically be set. These dates are automatically set only for released products of the Post contract support revenue type. The contract start date is automatically set to the sales order line’s requested ship date, and the contract end date is automatically set to the start date plus the number of months or occurrences that is defined in the setup of the revenue schedule. For example, the product on the sales order line is for a one-year warranty. The default revenue schedule is 12M (12 months), and the Automatic contract terms check box is selected for this revenue schedule. If the sales order line has a requested ship date of December 16, 2019, the default contract start date is December 16, 2019, and the default contract end date is December 15, 2020.
Recognition basis – The recognition basis determines how the revenue price is allocated across the occurrences.
Monthly by dates – The amount is allocated based on the actual days in each month.
Monthly – The amount is allocated equally across the number of months that is defined in the occurrences.
Occurrences – The amount is allocated equally across the occurrences, but it can include an extra period if you select Actual start date as the recognition convention.
Recognition convention – The recognition convention determines the default dates that are set on the revenue schedule for the invoice.
Actual start date – The schedule is created by using either the contract start date (for post contract support [PCS] items) or the invoice date (for essential and nonessential items).
1st of month – The date on the first schedule line is the contract start date (or invoice date). However, all subsequent schedules lines are created for the first of the month.
Mid-month split – The date on the first schedule line depends on the invoice date. If the invoice is posted on the first through fifteenth of the month, the revenue schedule is created by using the first day of the month. If the invoice is posted on the sixteenth or later, the revenue schedule is created by using the first day of the next month.
1st of next month – The date on the schedule is the first day of the next month.
Select the Revenue schedule details button to view the general periods and the percentages that are recognized in each period. By default, the Recognize percentage value is equally divided across the number of periods. If the recognition basis is set to either Monthly or Occurrences, the recognition percentage can be changed. As you change the recognition percentage, a warning message notifies you that the total doesn’t equal 100 percent. If you receive the message, you can continue to edit lines. However, the total percentage must equal 100 before you close the page.
You can recognize revenue for released products on sales orders, but not with sales categories on the sales orders or with free text invoices, if no items are included on the document. The selections that you make when you set up released products determine how the item’s revenue is recognized. For example, the selections determine whether the revenue price is allocated, and whether the revenue is deferred by using a revenue schedule.
The setup can begin on the Revenue recognition FastTab of the Item group page (Revenue recognition > Setup > Inventory and product setup > Item group). This page includes several setup fields. These fields are used to set default values only for new released products that are created in the system. As new products are created, the values that you set here are entered by default for the item group. You can override the default values for released products on the Released products page (Revenue recognition > Setup > Inventory and product setup > Released products). The default values that are set for the released products are then carried forward to the sales order.
Item groups and released products
Define the revenue schedule
Revenue on the sales order line is deferred if a revenue schedule is defined for the released product and used by default on the sales order line. If the setting should be used by default for the product, you can define the revenue schedule on the Revenue recognition FastTab of the Item group page (Revenue recognition > Setup > Inventory and product setup > Item group). You can also define the setting for the released product on the Revenue recognition FastTab of the Released products page (Revenue recognition > Setup > Inventory setup > Released products).
In the Revenue schedule field, select the revenue schedule that represents the period that the revenue must be deferred over. The revenue schedule is automatically entered on the sales order line, and the schedule details are created when the sales order invoice is posted.
Define the revenue price
Item groups and released products can be set up by using either the median price method or the discount allocation method. Both methods require various settings on the Released products page:
Is revenue allocation active – Set this option to Yes to include the released product in the revenue allocation calculation. If this option is set to No, the released product uses the median price method if the median price is defined. If the median price isn’t defined, the unit price on the sales order line is used to post to revenue or deferred revenue.
Revenue type – Select the revenue type that defines the released product:
Essential – The item is a primary source of an organization’s revenue. This value is the default setting.
Nonessential – The item isn’t a primary source of an organization’s revenue. When the median price settings are used, the price is ‘carved out’ to the median price and then allocated. For example, an essential item has a fixed price that must be recognized for revenue. If there is a discount, the discount might be carved out of the essential item revenue, but only up to the fixed price amount. The rest of the discount is taken out of the revenue for nonessential items. Alternatively, the discount might not be carved out of the essential item revenue.
Post contract support – The item supports other elements that are included in the sale to the customer. The revenue price is distributed across the essential and nonessential products that are included in the sale. Depending on setup, PCS items might not require that contract start and end dates be defined on the sales order line.
Exclude from carve out – Set this option to Yes to indicate that the item’s median price can’t be adjusted below the minimum percentage that is defined or above the maximum percentage. Any revenue price will be derived from the revenue price of another released product that is included on the sales order. If this option is set to No, the item’s median price can be adjusted or carved out. Note that if you sell more than one item that is set up as median price, at least one released product must be set up where the Exclude from carve out option is set to No. In that way, there is at least one item that any differences in the revenue price can be allocated to.
Median price – Set this option to Yes to indicate that the item’s revenue price should be adjusted so that it equals the median price if it’s below the minimum tolerance that you specify or above the maximum tolerance, and that the carve-out amount should be allocated to lines that have products where the Exclude from carve out option is set to No.
Maximum tolerance – Enter the percentage over the median price that is permitted.
Minimum tolerance – Enter the percentage under the median price that is permitted.
After you’ve finished configuring the settings for the released product, you must manually define the revenue price by entering the fair value price or the median price (if you’re using median price method) on the Revenue prices page (go to Revenue recognition > Setup > Inventory setup > Released products, and then, on the Action Pane, on the Sell tab, in the Revenue recognition group, select Revenue prices).
The revenue price that is manually defined on this page is used to determine the revenue price allocation on each sales order, based on the criteria that are defined. Each criterion is matched to the sales order line to determine the revenue price that should be used in the allocation process.
Item code and Item relation – A revenue price can be defined for an individual product or a group of products. If you select Table in the Item code field, select the released product in the Item relation field. If you select Group in the Item code field, select the item group in the Item relation field.
Account code and Account/Group number – A revenue price can be defined for all customers, an individual customer, or a group of customers. If you select All in the Account code field, the price is used for all customers. If you select Table in the Account code field, select the customer in the Account/Group number field. If you select Group in the Account code field, select the customer group in the Account/Group number field.
Currency – You must enter a separate revenue price for each currency that you enter a sales order in. For example, if you currently sell in U.S. dollars, Canadian dollars, and euros, you must define a revenue price in all three currencies. The revenue price isn’t translated from one currency, such as the accounting currency, to any other transaction currencies that you’re using.
Amount or percent of list – Specify whether the revenue price is set up as an amount or as a percentage of the list price. If you select Percent of list, users can enter the median price as a percentage of the list price instead of an amount. The Percent of list value is used only for released products that are set up as PCS items.
Revenue allocation price – Depending on the value that you selected in the Amount or percent of list field, enter either an amount or a percentage to represent the revenue price that is used to allocate the revenue across the elements on the sales order.
From date and To date – Enter the date range that the revenue price is active for. These fields are optional.
If the Enable discount allocation method option on the General ledger parameters page is set to Yes, and if the Revenue type field for your released product is set to Post contract support, you must also specify the items that are being supported by the released product. This setup is done on the Setup basis page (go to Revenue recognition > Setup > Inventory setup > Released products, and then, on the Action Pane, on the Sell tab, in the Revenue recognition group, select Setup basis).
On the Setup basis page, add a record for each item group that the item is supporting. When the revenue allocation occurs, the revenue price will be distributed across the essential and nonessential parts for the PCS item.
Three additional posting types support the ability to defer revenue. These posting types are set up on the Sales order tab of the Posting page (Revenue recognition > Setup > Inventory and product setup > Posting).
Deferred revenue – Enter the main account for the revenue price that posts to deferred revenue (instead of revenue). The revenue price is deferred if the sales order line has a revenue schedule.
Deferred cost of goods sold – Enter the main account for the cost of goods sold amount that posts to deferred cost of goods sold if the revenue is also deferred.
Partial invoice revenue clearing – Enter the main account for the clearing account that is used either when the sales order is partially invoiced or when reallocation occurs. The balance in this account returns to 0 (zero) when the sales orders are fully invoiced.
Bundle items are unique released products that are set up so that they include components. This setup is done by using the bill of materials (BOM) functionality. When a bundle item is entered on a sales order, the individual components are used to determine the revenue prices and revenue schedules. However, printed documents for the customer, such as the sales order and invoice, reflect the bundle item.
The components that are included in the bundle must be set up on the Released products page (Revenue recognition > Setup > Inventory and product setup > Released products). These components are released products, and they must be set up in the same manner as products that are included in a BOM. For example, a released product can be an item of either the Item type or the Service type, but it must be assigned to an item model group where the Stocked product option is set to Yes. For more information, see the setup documentation for BOM items.
The components must also be set up for revenue recognition, just as if they are products that can be sold individually on a sales order. For example, make sure that the correct revenue price is defined for each component, and that the price basis is set up for PCS items.
When you set up a bundle item, you must set two fields on the Released products page (Revenue recognition > Setup > Inventory and product setup > Released products):
On the Engineer FastTab, in the Production type field, the item must be set up as a BOM item.
On the General FastTab, in the Bundle field, the item must be marked as a bundle item.
The components must be then assigned to the bundle/BOM parent item on the BOM versions page (go to Revenue recognition > Setup > Inventory and product setup > Released products, and then, on the Action Pane, on the Engineer tab, in the BOM group, select BOM versions). For more information, see the setup documentation for BOMs.
If the bundle parent item and bundle components are set to allocate, the bundle revenue price will be distributed to the components, based on their revenue contribution percentages.
Revenue recognition can also be used for sales orders that are created through a Time and materials project. For sales orders that originate from projects, you just have to define the main accounts in the project posting profiles that are used to post project invoices. The main accounts are defined on the Ledger posting setup page (Revenue recognition > Setup > Project setup > Ledger posting setup).
Deferred invoice revenue (under Revenue accounts) – Enter the main account for the revenue price that posts to deferred revenue (instead of revenue). The revenue price is deferred if the sales order line has a revenue schedule.
Deferred cost (under Cost accounts) – Enter the main account for the cost of goods sold amount that posts to deferred cost of goods sold if the revenue is also deferred.
Bills of material (BOM) calculations use data from several sources to calculate the standard costs of a manufactured item. The sources include information about items, bills routings, indirect cost calculation formulas, and the costing version.
The purchased item information that is used in a standard cost BOM calculation includes the following:
Cost − A purchased item’s costs are maintained as site-specific cost records in a costing version for standard costs. Each cost record has an effective date, and the BOM calculation date determines which cost record will be used. For example, a BOM calculation with a future calculation date might use a cost record with a pending status and a future effective date.
Cost group − The cost group that is assigned to a purchased item provides the basis for cost segmentation in the calculated costs of a manufactured item.
Warning conditions that are embedded in the item’s BOM calculation group enable the BOM calculation to identify potential problems. This can be when the purchased item has a zero cost, a zero quantity in a BOM, or an out-of-date cost record. The applicable warning conditions can be overridden when initiating a BOM calculation.
The manufactured item information that is used in a standard cost BOM calculation includes the following:
Standard order quantity for inventory − The item’s standard order quantity for inventory, acts as the default accounting lot size for amortizing constant costs in a BOM calculation. The accounting lot size will also reflect the order quantity multiple if it is specified.
Warning conditions that are embedded in the item’s BOM calculation group enable the BOM calculation to identify potential problems. One example could be that the manufactured item does not have a BOM or route. The applicable warning conditions can be overridden when initiating a BOM calculation.
The bill of material information that is used in a standard cost BOM calculation includes the following:
BOM version − The BOM version that is assigned to the manufactured item has effective from and to dates, and a status for approved and active. The bill version can be company-wide or site-specific, and it can optionally reflect quantity breakpoints.
BOM line item quantity − A component typically has a variable quantity required, but it can be a constant. The component quantity is typically expressed for producing one parent item, but it may be expressed per 100 or per 1000 to handle decimal precision issues. The component quantity can also be calculated based on measurements.
BOM line item scrap − A component can have a variable or constant quantity for planned scrap.
BOM line item valid dates − A component can have valid from and to dates.
BOM line item type of production − The costing lot size for amortizing constant costs will reflect the BOM calculation quantity and a make-to-order explosion mode, because the BOM calculation assumes that the manufactured component will be produced to the exact quantity instead of its standard order quantity.
Sub-BOM for a manufactured component − A manufactured component can optionally have a specified BOM version, which would be used instead of the item’s current active BOM version in a BOM calculation.
Sub-route for a manufactured component − A manufactured component can optionally have a specified route version, which would be used instead of the item’s current active route version in a BOM calculation.
Operation number and the impact of operation scrap percentages − The operation number links a component to a specific operation, and operations can have a scrap percentage. The linkage enables BOM calculations to account for scrap percentages and cumulative scrap percentages across multiple operations on the component’s required quantity.
Ignore BOM line item in cost calculations − A component can be ignored for BOM calculation purposes.
The operations resource information that is used in a standard cost BOM calculation includes:
Hourly costs − The hourly costs that are associated with an operations resource are expressed as cost categories that are assigned to set up time and run time. These cost categories should be identified for resource groups and operations resources. The hourly costs that are associated with a cost category can be site-specific or company-wide.
Per unit costs − Some manufacturing environments assign operations resource costs per unit of output, which would be expressed as a different cost category for quantity. For example, the quantity-related costs can reflect piece rates for labor, or a paint manufacturer may assign operations resource costs per gallon of output.
Overriding operations resource information on routing operations − The resource information about cost categories will be inherited by operations, where it can be overridden. BOM calculations will use the cost category information that is specified on the routing operations.
Cost group for a cost category − The cost group that is assigned to a cost category provides cost segmentation in the calculated costs of a manufactured item. For example, different cost groups might be used to segment the calculated costs that are associated with machines and labor or with setup and run time.
The route information that is used in a standard cost BOM calculation includes:
Route version − The route version that is assigned to the manufactured item has effective from and to dates, and a status for approved and active. The route version must be site-specific, and it can optionally reflect quantity breakpoints.
Routing operation time − The time can be specified for runtime and setup time. The hourly time is typically expressed for producing one parent item, but it may be expressed per 100 or per 1000 to handle decimal precision issues.
Routing operation time for secondary resources − A secondary resource has the same operation number as the primary resource, and the same routing operation time. For example, an operation might require a machine as the primary resource and labor and tools as secondary resources.
Routing operation scrap percentage − BOM calculations will account for scrap percentages and cumulative scrap percentages across multiple operations. This applies to the required time for routing operations and the required quantity for components that are linked to operation numbers.
Cost categories for a routing operation − Operations resource information about cost categories will be inherited by operations, where it can be overridden. BOM calculations will use the cost category information that is specified on the routing operations.
The manufacturing overhead information that is used in a standard cost BOM calculation includes:
Surcharge − A surcharge calculation formula reflects a percentage of value, such as 100 percent, that is tied to a specific cost group, such as labor.
Rate − A rate calculation formula reflects an amount per unit, such as USD 10.00 per hour, that is tied to a specific cost group, such as labor.
Time-based versus material-based overhead − The manufacturing overhead can be tied to routing operations or material components.
The costing version information that is used in a standard cost BOM calculation includes:
Costing type − The costing version must contain standard costs. Several restrictions apply to BOM calculations that use standard costs. For example, these restrictions specify that miscellaneous charges must be included in unit costs and that the BOM calculation explosion mode must be single level.
Mandated fallback principle − The costing version can mandate the use of a fallback principle, such as using a specified costing version or the active cost records. The mandated fallback principle typically applies to a costing version that represents the incremental updates in a two-version approach for cost updates.
Blocking flag for pending costs − A blocking flag can prevent BOM calculations of the pending cost for manufactured items.
Specified from-date − The specified from-date will act as the default calculation date for all BOM calculations that involve the costing version.
Specified site − A specified site will limit BOM calculations to the single site.
Content of the costing version must include costs − The content must include costs. It can optionally include sales prices in order to calculate suggested sales prices for manufactured items.
Organizations that pay vendors on a recurring schedule can now automate the process of generating vendor payment proposals. Vendor payment proposal automations define the following details:
When payment proposals are run
What criteria are used to select the invoices that should be paid
What vendor payment journal the resulting payments are saved in
Payment proposal automations don’t automatically post the payments. Therefore, you can continue to use any validation and workflow processes that you currently use to approve the payments that are created.
Define the occurrence of vendor payment proposals
Vendor payment proposal automations use the Process automation framework. Different business processes use this framework to define the recurrence of a selected process. For vendor payment proposals, the automation can be accessed at Accounts payable > Payment setup > Process automation.
First, use the Create new process automation option, and select Vendor payment proposal. A wizard then guides you through the process of setting up the vendor payment proposal.
On the General page of the wizard, enter the name of the vendor payment proposal that you’re creating. For example, if you pay all domestic vendors by check on Monday, enter a descriptive name such as Domestic_Check. The name that you enter is shown in the process automation weekly view in the Vendor payments workspace.
Next, define the owner of the payment journal that is created. The owner is usually the Accounts payable (AP) payment clerk, who is responsible for the payment journal after it’s created.
The remaining settings on the page are generic and are used to define the occurrence pattern for this version of the vendor payment proposal. For example, if an occurrence is for check payments on Monday, you can define it so that it runs weekly, and you can select Monday as the day of the week when it runs. You can also enter an early schedule time, such as 2:00 AM, so that the process automation will be completed before the start of the next business day.
It’s important that you understand that you’re using the wizard to define when the vendor payment proposal is processed. You aren’t defining when the vendor payments are generated, printed, and posted. In the weekly view, the process automation for vendor payment proposals will appear on the days that are selected in the occurrence pattern.
For more information about the other fields on the General page, see the process automation documentation.
Vendor payment proposal page
The next page in the wizard is the Vendor payment proposal page. It’s used to define the criteria for selecting the vendor invoices that should be paid. In general, the same options are found in the payment proposal in the vendor payment journal. However, there are a few exceptions. For example, all dates on this page must be defined as relative dates, because the payment proposal date changes every time that the proposal is run.
The Journal name field defines the journal name that the vendor payments are created in. The results of the vendor payment proposal automation will create payments in the defined journal, but the journal isn’t posted.
“From” date and “to” date
Instead of defining a “from” date and a “to” date to select invoices based on the due date or cash discount date, you must use the Define to date criteria option and the Number of days adjustment for To date field to define the “to” date. There is no concept of a “from” date in payment proposal automations.
By default, the Define to date criteria option is set to No. If you use this default value, the process will select all invoices for payment when the process is run, because no “to” date has been defined.
If you set the Define to date criteria option to Yes, use the Number of days adjustment for To date field to define the date when invoices are selected as the specified number of days before or after the date when the process runs. The number can be positive, negative, or 0 (zero). The system will then pay invoices where the due dates, or cash discount dates, are the specified number of days before or after the date when the process runs. For example, for all invoices that are due on or before Friday, the payment series creates payments to all vendors by check on Wednesday. In this case, set the Number of days adjustment for To date field to 2. When the occurrence of the payment proposal is run on Wednesday, March 25, all invoices that have a due date or cash discount date on or before March 27 will be selected for payment.
Minimum payment date
The minimum payment date defines the earliest date that is used when payments are created. You must first set the Define minimum payment date criteria option to Yes. This setting lets you use the minimum payment date functionality. If this option is set to Yes, use the Number of days adjustment for minimum payment date field to define the minimum payment date as the specified number of days before or after the date when the process runs. The number can be positive, negative, or 0 (zero). For example, the payment series generates payments on Wednesday to include all payments that have a minimum payment date of the preceding Monday. In this case, set the Number of days adjustment for minimum payment date field to -2.
Here is an example that shows how the fields for the “to” date and the minimum payment date work together. The payment proposal automation is set up to run on Wednesday. The Number of days adjustment for To date field is set to 1 to define the “to” date based on the due date. The Number of days adjustment for minimum payment date field is set to -2. If the payment process automation starts on Wednesday, March 25, all invoices that are due on or before March 26 will be included in the payment proposal. Payment proposals will be generated in the following way:
All invoices that are due on or before March 23 will have a payment date of March 23.
Invoices that are due on March 24 will have a payment date of March 24.
Invoices that are due on March 25 will have a payment date of March 25.
Invoices that are due on March 26 will have a payment date of March 26.
Summarized payment date
The summarized payment date is used only when the Period field is set to Total for the method of payment of the invoices. If the Period field is set to Total for your methods of payment, you must set the Define summarized payment date criteria option to Yes. If this option is set to Yes, use the Number of days adjustment for summarized payment date field to define the summarized payment date as the specified number of days before or after the date when the process runs. The number can be positive, negative or 0 (zero). For example, the series generates payments on Wednesday, and the company wants to create a summarized payment on Wednesday. In this case, set the Number of days adjustment for summarized payment date field to 0.
Records to include
The filter options can still be defined for the payment proposal. If a filter is defined, the filter criteria aren’t shown on the wizard page. However, they can be viewed by reopening the filter.
Some country/region-specific fields, and some Public sector fields, aren’t yet available in vendor payment proposal automations.
We recommend that you evaluate whether the automation will be beneficial to your organization, based on your requirements.
View the results of a vendor payment proposal automation
After the vendor payment proposal automation series is created, the occurrences for each payment are shown in the process automation weekly view. For vendor payments, the process automation weekly view has been added to both the Vendor payments workspace and the Process automation page.
The process automation weekly view in the Vendor payments workspace shows only vendor payment proposal automations. It shows all occurrences of payments for the current week, for all legal entities that the signed-in user has security permissions to. For example, if the AP payment clerk is responsible for payments in the USMF and USSI companies, he or she will see the occurrences of the vendor payment proposal automation for those two companies but not for other companies.
Each occurrence shows the company that the payment journal was or will be created in. If payments are created by using centralized payments, the company that is shown is the company that payments will be created in. The occurrence doesn’t necessarily show which companies’ invoices will be paid.
The name of each occurrence is also shown to help identify the payment proposal.
Additionally, the status of each occurrence is shown. The following statuses are used:
Scheduled – The payment proposal is scheduled, but it hasn’t yet run.
Error – The payment proposal has run, but an error occurred. You can view the errors by selecting the View results button.
Completed – The payment proposal has successfully run. You can view the payments by selecting the View payments link. This link opens the payment journal that was created by the occurrence.
After the payments are created, you can view the payment amounts in the journal. The amounts are shown in the transaction currencies. For example, if the payment journal contains payments in both US dollars and Canadian dollars, the total payments for each currency are shown.
The payment journal can be deleted after it’s created through the process automation. If a payment is completely deleted, the following events occur:
The status of the process automation for the week remains Completed.
The process removes the payment totals, and the View payments link is replaced with a View results button.
When you view the results, you receive a message that states that the original journal was deleted.
After a payment is deleted, the invoices will be open again for payment. A new occurrence can then be created to pay the invoices again.
Edit a vendor payment proposal automation
The Process automation framework lets you edit the payment, the series, and the occurrences that are created for the payment proposal. The series can be edited from either the Process automation page or the process automation weekly view. For example, if the AP manager decides to generate all checks for domestic vendors on Wednesday instead of Monday, he or she can find an occurrence in the weekly view and select View/Edit – Series. If you edit a series, the system prompts you to specify whether the change should be made to all existing occurrences or only to new occurrences. Historical occurrences that already have a status of Completed, or that ended in an Error status won’t be changed.
You can also add a new occurrence or change an existing occurrence. For example, the next payment proposal occurrence is scheduled to run Wednesday, January 1, but this date is a holiday. You can change the occurrence from either the process automation weekly view or the Process automation page. A page is opened that shows the schedule details and payment proposal criteria. Here, you can edit the scheduled time and date. You can also edit the payment proposal criteria, if changes are required. For example, if you change the scheduled date of the payment occurrence from January 1 to January 2, you might also want to change the relative dates for the “to” date.
You can also disable an occurrence or a series. To disable an occurrence and suspend processing for it, select it in the process automation weekly view, and then select Disable. You can disable a series on the Process automation page.
Security for payment proposal automations
The following duties and privileges have been added for vendor payment proposal automations. These duties and privileges are the default security settings, but they can be changed based on your organization’s requirements. For example, if not only the AP manager but also the AP payment clerk can edit and create schedule recurrence, assign the Maintain schedule occurrences duty to the person in the AP payment clerk role.
Maintain schedule series
Accounts payable manager
This duty grants the rights to create and maintain the payment proposal automation series and occurrences through the following privileges:Maintain schedule occurrencesMaintain schedule seriesProcessScheduleOccurrenceListMaintainView the occurrences weekly view