Cash and bank management – Cash flow forecasting

You can use the cash flow forecasting tools to analyze upcoming cash flow and currency requirements, so that you can estimate the company’s future need for cash. To obtain a forecast of the cash flow, you must complete the following tasks:

  • Identify and list all the liquidity accounts. Liquidity accounts are the company’s accounts for cash or cash equivalents.
  • Configure the behavior for forecasts of transactions that affect the company’s liquidity accounts.

After you’ve completed these tasks, you can calculate and analyze forecasts of the cash flow and upcoming currency requirements.

Cash flow forecasting integration

Cash flow forecasting can be integrated with General ledger, Accounts payable, Accounts receivable, Budgeting and inventory management. The forecasting process uses transaction information that is entered in the system, and the calculation process forecasts the expected cash impact of each transaction. The following types of transactions are considered when the cash flow is calculated:

  • Sales orders – Sales orders that aren’t yet invoiced, and that result in physical or financial sales.
  • Purchase orders – Purchase orders that aren’t yet invoiced, and that result in physical or financial purchases.
  • Accounts receivable – Open customer transactions (invoices that aren’t yet paid).
  • Accounts payable – Open vendor transactions (invoices that aren’t yet paid).
  • Ledger transactions – Transactions where it’s specified that a future posting will occur.
  • Budget register entries – Budget register entries that are selected for cash flow forecasts.
  • Demand forecasts – Inventory forecast model lines that are selected for cash flow forecasts.
  • Supply forecasts – Inventory forecast model lines that are selected for cash flow forecasts.

Although there is no direct integration with Project management and accounting, there are several ways to include project transactions in the cash flow forecast. Posted project invoices are included in the forecast as part of open customer transactions. Project-initiated sales orders and purchase orders are included in the forecast as open orders after they are entered in the system. You can also transfer project forecasts to a ledger budget model. This ledger budget model is then included in the cash flow forecast as part of the budget register entries.

Configuration

To configure the cash flow forecasting process, use the Cash flow forecast setup page. On this page, you specify the liquidity accounts to track and the default forecasting behaviors for each area.

General ledger

You must first define the liquidity accounts to track through cash flow forecasting. Typically, these liquidity accounts are main accounts that are associated with the bank accounts that will receive and disburse cash. On the Cash flow forecast setup page, on the General ledger tab, select the main accounts to include for forecasting. If a bank account has been associated with the main account on the Bank account page, it’s shown in the Bank account field.

You can set up a dependent cash flow forecast for a main account that contains transactions that are directly related to transactions in another main account. Each line that you add in the In the Dependent accounts section creates a cash flow forecast amount in a dependent main account. This amount is a percentage of the cash flow amounts to the primary main account that you selected.

First, set the Main account field to the primary main account where transactions are expected to initially occur. Set the Dependent main account field to the account that will be affected by the initial transaction against the primary main account. Set appropriate values for the other fields on the line. You can change the value in the Percent field to reflect the effect of the primary main account on the dependent main account. For a sales or purchase forecast, select a Terms of payment value that is typical for most customers or vendors. Set the Posting type field to the expected posting type that is related to the cash flow forecast.

Accounts payable

You can calculate the forecast for purchases by using the setup options on the Accounts payable tab of the Cash flow forecast setup page. Before you can configure cash flow forecasting for Accounts payable, you must configure terms of payment, vendor groups, and vendor posting profiles.

In the Purchasing forecast defaults section, you can select default purchasing behaviors for cash flow forecasting. Three fields determine the time of the cash impact: Time between delivery date and invoice date, Terms of payment, and Time between invoice due date and payment date. The forecast will use the default setting for the Terms of payment field only if a value isn’t specified on the transaction. Use a term of payment to describe the most typical number of days for each part of the process.

The Liquidity accounts for payments field specifies the liquidity account that is most often used for payments. Use the Percentage of amount to allocate to cash flow forecast field to specify whether a percentage of amounts should be used during forecasting. Leave this field blank if the full transaction amounts should be used during forecasting.

You can override the default setting for the Time between invoice due date and payment date field for specific vendor groups. The forecast will use the default value from the Purchasing forecast defaults section unless a different value is specified for the vendor group that is related to the vendor on the transaction. To override the default value, select a vendor group, and then set the new value for the Purchasing time field.

You can override the default setting for the Liquidity account field for specific vendor posting profiles. The forecast will use the default value from the Purchasing forecast defaults section unless a different liquidity account is specified for the posting profile that is related to the vendor on the transaction. To override the default value, select a posting profile, and then specify the liquidity account that is expected to be affected.

Accounts receivable

You can calculate the forecast for sales by using the setup options on the Accounts receivable tab of the Cash flow forecast setup page. Before you can configure cash flow forecasting for the Accounts receivable, you must configure terms of payment, customer groups, and customer posting profiles.

In the Sales forecast defaults section, you can select default sales behaviors for cash flow forecasting. Three fields determine the time of the cash impact: Time between shipping date and invoice date, Terms of payment, and Time between invoice due date and payment date. The forecast will use the default setting for the Terms of payment field only if a value isn’t specified on the transaction. Use a term of payment to describe the most typical number of days for each part of the process.

The Liquidity accounts for payments field specifies the liquidity account that is most often used for payments. Use the Percentage of amount to allocate to cash flow forecast field to specify whether a percentage of amounts should be used during forecasting. Leave this field blank if the full transaction amounts should be used during forecasting.

You can override the default setting for the Time between invoice due date and payment date field for specific customer groups. The forecast will use the default value from the Sales forecast defaults section unless a different value is specified for the customer group that is related to the customer on the transaction. To override the default value, select a customer group, and then set the new value for the Sales time field.

You can override the default setting for the Liquidity account field for specific customer posting profiles. The forecast will use the default value from the Sales forecast defaults section unless a different liquidity account is specified for the posting profile that is related to the customer on the transaction. To override the default value, select a posting profile, and then set the liquidity account that is expected to be affected.

Budgeting

Budgets that are created from budget models can be included in cash flow forecasts. On the Budgeting tab of the Cash flow forecast setup page, select the budget models to include in the forecast. By default, new budget register entries are included in forecasts after the budget model has been enabled for cash flow forecasting. Inclusion in cash flow forecasting can be overwritten on individual budget register entries.

Inventory management

Inventory supply and demand forecasts can be included in cash flow forecasts. On the Inventory management tab of the Cash flow forecast setup page, select the forecast model to include in the cash flow forecast. Inclusion in cash flow forecasting can be overwritten on individual supply and demand forecast lines.

Calculation

Before you can view cash flow forecasting analytics, you must run the cash flow calculation process. The calculation process will project the future cash impacts of transactions that have been entered.

Calculate the cash flow forecast by using the Calculate cash flow forecasts page. You can calculate either the full cash flow forecast or an incremental cash flow forecast.

  • To clear all cash flow forecast transactions and recalculate, set the Cash flow forecast calculation method field to Total. We recommend that you use this approach if you haven’t updated the cash flow forecasts for a long time.
  • To update the existing cash flow information for new transactions only, set the Cash flow forecast calculation method field to New. The page will show the date when your cash flow calculation was last run.

You can also use batch processing for your cash flow forecasting. To help guarantee that your forecasting analytics are regularly updated, set up a recurring batch process for cash flow forecast calculation.

Reporting

After the cash flow forecast is calculated, you must refresh the associated entity information for analytical reporting. On the Entity store page, select the LedgerCovLiquidityMeasurement aggregate measurement, and then click Refresh.

There are two workspaces that contain cash flow forecasting data. One workspace has data for all companies, and the other workspace has data only for the current company.

Access to the workspace for all companies is controlled through the View cash flow all companies workspace duty. By default, the Cash overview – all companies workspace is available to the following roles:

  • Chief executive officer
  • Chief financial officer
  • Financial controller

Access to the workspace for the current company is controlled through the View cash flow current company workspace duty. By default, the Cash overview – current company workspace is available to the following roles:

  • Accountant
  • Accounting manager
  • Accounting supervisor
  • Accounts payable manager
  • Accounts receivable manager

The Cash overview – all companies workspace shows cash flow forecasting analytics in the system currency. The system currency and the system exchange rate type that are used for the analytics are defined on the System parameters page. This workspace shows an overview of cash flow forecasting and bank account balances for all companies. A chart of cash inflows and outflows gives an overview of future cash movements and balances in the system currency, together with detailed information about the forecasted transactions. You can also see the forecasted currency balances.

The Cash overview – current company workspace shows cash flow forecasting analytics in the company’s defined accounting currency. The accounting currency that is used for the analytics is defined on the Ledger page. This workspace shows an overview of cash flow forecasting and bank account balances for the current company. A chart of cash inflows and outflows gives an overview of future cash movements and balances in the accounting currency, together with detailed information about the forecasted transactions. You can also see the forecasted currency balances.

For more information about the cash flow forecasting analytics, see the Cash overview Power BI content topic.

Additionally, you can view cash flow forecasting data for specific accounts, orders, and items on the following pages:

  • Trial balance: Select Cash flow forecasts to view the future cash flows for the selected main account.
  • All sales orders: On the Invoice tab, select Cash flow forecasts to view the forecasted cash impact of the selected sales order.
  • All purchase orders: On the Invoice tab, select Cash flow forecasts to view the forecasted cash impact of the selected purchase order.
  • Supply forecast: Select Cash flow forecasts to view the future cash flows that are associated with the selected item supply forecast.
  • Demand forecast: Select Cash flow forecasts to view the future cash flows that are associated with the selected item demand forecast.

You can found the original article here

Inventory management – Set up an item arrival overview profile

This topic focuses on the setup of an arrival overview profile. The arrival overview profile is a collection of rules that will be applied when the Arrival overview page is opened by a user. You can use this procedure in demo data company USMF. This procedure would typically be carried out by a receiving clerk.

  1. In the navigation pane, go to Modules > Inventory management > Setup > Distribution > Arrival overview profiles.
  2. Select New. Because you will almost always work in the same warehouse offloading full truck loads, you should create an arrival overview profile to simplify the process of registering received items.
  3. In the Arrival overview profile name field, type a value.
  4. In the Show lines field, select an option. Select which lines to show for the receipts:
    • All – Show all lines, regardless of status.
    • In progress – Show lines for receipts in which the progress is Complete or Partly. This means that for each line, either the full quantity or part of the quantity has been registered in an arrival journal.
    • Not complete – Show lines for receipts in which the progress is None or Partly. This means that for each line, nothing or only part of the quantity has been registered in an arrival journal.
  5. Expand or collapse the Arrival options section.
  6. In the Days forward field, type a value. This sets a filter to show the receipt lines expected to be received within the next few days (depending on the number you set).
  7. In the Days back field, type a value. This sets a filter to show the receipt lines expected to be received a number of days before today.
  8. In the Warehouses field, type a value. Filter on one or more warehouses.
  9. In the Mode of delivery field, select a value. This sets a filter to show only the receipt lines with this Mode of delivery.
  10. In the Name field, select WHS.
  11. In the Warehouse field, select warehouse 24. This is the default warehouse that will be used for registered receipt lines that use this profile.
  12. In the Location field, select Baydoor. This is the default location that will be used for registered receipt lines that use this profile.
  13. Expand or collapse the Arrival query details section.
  14. In the Restrict to site field, select site 2. This sets a filter to show only the receipt lines with this site.
  15. Set the Purchase orders option to Yes. Select receipt lines from purchase orders.
  16. Set the Transfer orders option to Yes. Select receipt lines from transfer orders.
  17. Select Save.
  18. Close the page.

The original article can be found here

Account Receivable – Set up and process recurring invoices

Create a recurring free text invoice template

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.

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.

The original article can be found here

Reporting and analytics with Power BI

This topic points you to resources that you can use to learn more about the business intelligence (BI) and reporting tools that are available.

Get started

Analytical workspaces

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.

Example of Power BI in a workspace

To learn more, see the following topics:

Business documents and printing

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.

Example of business documents

To learn more, see the following topics:

Electronic reporting

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.

Electronic reporting example

To learn more, see the following topics:

Financial reporting

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.

Financial reporting example

The original article can be found here

Account Receivable – Revenue recognition setup

The Revenue recognition module has the following setup options:

  • Revenue recognition journals
  • Parameters for revenue recognition
  • Revenue schedules
  • Inventory setup
    • Item groups and released products
    • Defining revenue schedule
    • Defining revenue price
      • Posting profiles
      • Bundles
    • Bundle components
    • Bundle item
  • Project setup

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.
Setup information

Revenue schedules

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).

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.

Revenue schedule details

Inventory setup

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).

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.

Posting profiles

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.

Bundles

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.

Bundle components

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.

Bundle 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.

Released products, BOM schedules

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.

Project setup

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.

The original article can be found here

Cost management – Information used in BOM calculations with standard costs

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.

The original article can be found here

Account Payable – Automate vendor payment proposals

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.

General page

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.

Journal name

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.

The remaining fields for the proposal work just as they work for the payment proposal in the vendor payment journal. For information about the other fields, see Create vendor payments by using payment proposal.

Note

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.

Process automation weekly view in the Vendor payments workspace

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.

Process automation weekly view for the USMF and USSI 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.

DutyRolePrivileges
Maintain schedule seriesAccounts payable managerThis 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
Inquiry into schedule occurrencesAccounts payable payment clerk, Accounts payable Centralized payment clerkThis duty grants the rights to view the payment proposal automation occurrences through the following privileges:View schedule occurrencesView the occurrence weekly view
Inquire into schedule seriesNoneThis duty grants the rights to view the settings of the series and occurrences through the following privileges:View schedule occurrencesView the occurrences list pageView the occurrence weekly view
Maintain schedule occurrencesNoneThis duty grants the rights to create and maintain an occurrence through the following privileges:Maintain schedule occurrencesView the occurrence weekly view

The Original article can be found here

Cost accounting – Financial dimensions

This topic explains the various types of financial dimensions and how they are set up.

Use the Financial dimensions page to create financial dimensions that you can use as account segments for charts of accounts. There are two types of financial dimensions: custom dimensions and entity-backed dimensions. Custom dimensions are shared across legal entities, and the values are entered and maintained by users. For entity-backed dimensions, the values are defined somewhere else in the system, such as in Customers or Stores entities. Some entity-backed dimensions are shared across legal entities, whereas other entity-backed dimensions are company-specific.

After you’ve created the financial dimensions, use the Financial dimension values page to assign additional properties to each financial dimension.

You can use financial dimensions to represent legal entities. You don’t have to create the legal entities in Dynamics 365 Finance. However, financial dimensions aren’t designed to address the operational or business requirements of legal entities. The interunit accounting functionality in Finance is designed to address only the accounting entries that are created by each transaction.

Before you set up financial dimensions as legal entities, evaluate your business processes in the following areas to determine whether this setup will work for your organization:

  • Inventory
  • Sales and purchases between financial dimensions and legal entities
  • Sales tax calculation and reporting
  • Operational reporting

Here are some of the limitations:

  • You can use sales tax functionality only with legal entities, not with financial dimensions.
  • Some reports don’t include financial dimensions. Therefore, to report by financial dimension, you might have to modify the reports.

Custom dimensions

To create a user-defined financial dimension, in the Use values from field, select Custom dimension.

You can also specify an account mask to limit the amount and type of information that can be entered for dimension values. You can enter characters that remain the same for each dimension value, such as letters or a hyphen (-). You can also enter number signs (#) and ampersands (&) as placeholders for characters that will change every time that a dimension value is created. Use a number sign (#) as a placeholder for a number and an ampersand (&) as a placeholder for a letter. The field for the format mask is available only when you select Custom dimension in the Use values from field.

Example

To limit the dimension value to the letters “CC” and three numbers, enter CC-### as the format mask.

Entity-backed dimensions

To create an entity-backed financial dimension, in the Use values from field, select a system-defined entity to base the financial dimension on. Financial dimension values are then created from that entity. For example, to create dimension values for projects, select Projects. A dimension value is then created for each project name. The Financial dimension values page shows the values for the entity. If those values are company-specific, the page also shows the company.

Activating dimensions

When you activate a financial dimension, the table is updated so that it includes the name of the financial dimension. Deleted dimensions are removed. You can enter dimension values before you activate a financial dimension. However, a financial dimension can’t be consumed anywhere until it’s activated. For example, you can’t add a financial dimension to an account structure until the financial dimension has been activated. When you select Activate, all dimensions are updated and show status changes.

Translations

On the Text translation page, you can enter text for the selected financial dimension in various languages. On the Main account translation page, you can enter text for the main account in various languages.

Not all dimensions are valid for all legal entities. Additionally, some dimensions might be relevant only for a specific period. In these cases, you can use the Legal entity overrides section to specify the companies that the dimension should be suspended for, the owner, and the period when the dimension is active.

Deleting financial dimensions

To help maintain referential integrity of the data, financial dimensions can rarely be deleted. If you try to delete a financial dimension, the following criteria are evaluated:

  • Has the financial dimension been used on any posted or unposted transactions, or in any type of dimension value combination?
  • Is the financial dimension used in any active account structure, advanced rule structure, or financial dimension set?
  • Is the financial dimension part of a default financial dimension integration format?
  • Has the financial dimension been set up as a default dimension?

If any of the criteria are met, you can’t delete the financial dimension.

Default dimension values

You can use values from master records, such as customer and vendor, as default values in new dimensions. When the new dimensions are created, the master record ID is entered in the dimension values for those master records. For example, when you create a new customer, the customer ID is entered in the customer dimension. When you create sales orders, invoices, or other documents that require a customer ID, the existing defaulting rules are used, and the customer ID is added to the document.

This feature is controlled by a setting in the dimension. This setting is named Copy values to this dimension on each new DimensionName created, where DimensionName is the name of the dimension. By default, the feature is turned off. However, it can be turned on at any time.

If records already exist for the dimension, the master records are updated when you turn the feature on. However, existing documents and transactions aren’t updated.

If you are using a template to create a master record, make sure that the template value for the master dimension is blank. For example, if you’re creating customers from a template, make sure that the customer dimension in the template is blank. The customer dimension value will default from the new customer number when you create the new customer.

Derived dimensions

You can configure a dimension so that information for other dimensions is automatically entered when you enter that dimension in a document. For example, if you enter cost center 10, a value of 20 can be automatically entered in the department dimension.

You can set up derived values on the dimensions page.

  1. Select a dimension and then select Derived dimensions. The Derived dimensions page includes a grid. The selected dimension segment is the first column in this grid.
  2. Add the segments that should be derived. Each segment appears as a column.

Enter the dimension combinations that should be derived from the dimension in the first column. For example, to use the cost center as the dimension that the department and location are derived from, enter cost center 10, department 20, and location 30. Then, when you enter cost center 10 in a master record or on a transaction page, department 20 and location 30 are entered by default.

Overriding existing values with derived dimensions

By default, the derived dimension process doesn’t override existing values for derived dimensions. For example, if you enter cost center 10, and no other dimension is entered, department 20 and location 30 are entered by default. However, if you change the cost center, the values that have already been established aren’t changed. Therefore, you can establish default dimensions on master records, and those dimensions won’t be changed by derived dimensions.

You can change the behavior of derived dimensions to override existing values by selecting the Replace existing dimension values with derived values check box on the Derived dimensions page. If this field is selected, you can enter a dimension with derived dimension values and those derived dimension values will override any values that already exist. Using the previous example, if you enter cost center 10, and no other dimension is entered, department 20 and location 30 are entered by default. However, if the values were already department 50 and location 60, the values will now be changed to department 20 and location 30.

Derived dimensions with this setting do not automatically replace the existing default dimensions values when dimension values are defaulted. Dimension values will only be overridden when you enter a new dimension value on a page and there are existing derived values for that dimension on the page.

Preventing changes with derived dimensions

When you use Add segment” on the Derived dimensions page to add a segment as a derived dimension, an option is provided at the bottom of the Add segment page that allows you to prevent changes to that dimension when it is derived on a page. The default setting is off so it does not prevent the derived dimension values from being changed. Change the setting to Yes if you want prevent the dimension from being changed after it has been derived. For example, if the value for the Department dimension is derived from the value of the Cost center dimension, the Department value cannot be changed if the Prevent changes setting is Yes.

The setting does not prevent changes if the dimension value is valid but it is not listed in the derived dimensions list. For example, if Department 20 is derived from Cost center 10 and you enter Cost center 10, then you will not be able to edit Department 20. However, if you enter Cost center 20 and it is not in the list of derived dimensions for Cost center, then you can edit the Department value.

In all cases, the account value and all dimensions values will still be validated against the account structures after the derived dimensions values have been applied. If you use derived dimensions and they fail validation when used on a page, you must change the derived dimensions values on the derived dimensions page before you can use them in transactions.

When you change dimensions on the Financials dimensions FastTab, the dimension that is marked to prevent changes will not be editable. If you are entering an account and dimensions into the segmented entry control on a page, the dimensions are editable. However, when you move the highlight off the segmented entry control and move to another field or take an action, the account and dimensions will be validated against the derived dimensions list and the account structures to ensure that you have entered the appropriate values.

Derived dimensions and entities

You can set up the derived dimensions segments and values by using entities.

  • The Derived dimensions entity sets up the driving dimensions and the segments that are used for those dimensions.
  • The Derived dimensions value entity lets you import the values that should be derived for each driving dimension.

When you use an entity to import data, if that entity imports dimensions, the derived dimension rules are applied during the import unless the entity specifically overrides those dimensions.

The original article can be found here

Set up vendor invoice policies

This topic explains how to set up vendor invoice policies. Vendor invoice policies are run when you post a vendor invoice by using the Vendor invoice page and when you open the vendor invoice Policy violations page. You can also configure the vendor invoice workflow to run vendor invoice policies every time that you submit an invoice to workflow.

  • Vendor invoice policies do not apply to invoices that were created in the invoice register or invoice journal.
  • Invoice matching validation does not use vendor invoice policies, but is instead set up in the Accounts payable parameters page.
  • This recording uses the USMF demo company. The accounts payable manager or accounting manager role would perform these steps. Before you begin, make sure that the Invoice matching configuration key is selected.

Prepare to create vendor invoice policies

  1. Go to Navigation pane > Modules > Accounts payable > Setup > Accounts payable parameters.
  2. Select the Invoice validation tab.
  3. Select or clear the Automatically update invoice header status check box.
  4. Select OK.
  5. In the Post invoice with discrepancies field, select an option.
  6. Close the page.
  7. Go to Navigation pane > Modules > Accounts payable > Policy setup > Vendor invoice policies.
  8. Select Parameters.
  9. Select Add.
  10. Close the page to return to the home page.

Create policy rule types for vendor invoices

  1. Go to Navigation pane > Modules > Accounts payable > Policy setup > Vendor invoice policy rule types.
  2. Select New.
  3. In the Rule name and Description fields, type values.
  4. In the Query name field, select the drop-down button to open the lookup, then select the desired record.
  5. Select Save.
  6. Close the page to return to the home page.

Define a vendor invoice policy

  1. Go to Navigation pane > Modules > Accounts payable > Policy setup > Vendor invoice policies.
  2. Select New.
  3. In the Name and Description fields, type values.
  4. Expand or collapse the Policy organizations section.
  5. In the tree, select Contoso Entertainment System USA.
  6. Select Add.
  7. Expand or collapse the Policy rules section.
  8. Select Create policy rule.
  9. In the Policy rule description field, type a value.
  10. Select Filter.
  11. Select Add. Select the desired record.
  12. In the Table, Derived table, and Field fields, select or enter options from the drop-down menus.
  13. Close the page.
  14. In the Criteria field, type a value.
  15. Select OK.
  16. Select OK.
  17. Close the pages to return to the home page.

The original article can be find here

Cost accounting – Fiscal calendars, fiscal years, and periods

This article discusses fiscal calendars, fiscal years and periods and how to utilize them for legal entities, fixed assets and budgeting.

Fiscal calendars provide a framework for the financial activity of an organization. Each fiscal calendar contains one or more fiscal years, and each fiscal year contains multiple periods. Fiscal calendars can be based on a January 1 to December 31 calendar year, or on any dates that you select. For example, some organizations select a fiscal calendar that starts on July 1 of one year and ends on June 30 of the following year.

There is no limit to the number of fiscal calendars that you can create, and no limit to the number of fiscal years that can be created for a fiscal calendar. Each fiscal calendar is independent of your organization, and can be used by multiple legal entities in the organization. For example, an organization has eight departments and each department is a separate legal entity. Five of them share the same fiscal calendar and three use different fiscal calendars. You can create one fiscal calendar for the five legal entities that share the same fiscal calendar, and then create separate fiscal calendars for the other legal entities.

Create fiscal calendars, fiscal years, and periods

You can create and delete fiscal calendars, fiscal years, and periods on the Fiscal calendars page. You can also divide existing periods and create closing periods that can be used to close a fiscal year.

A closing period is used to separate general ledger transactions that are generated when a fiscal year is closed. When the closing transactions are in one fiscal period, it is easier to create financial statements that either include or exclude different types of closing entries. If a fiscal year is divided into 12 fiscal periods, the closing period is usually the 13th period. However, a closing period can be created from any period that has a status of Open.

When you create a closing period, select a period that has a status of Open and that has the dates that you want to use. The new closing period will copy the starting and ending dates from the existing period. The original period will continue to exist. For example, you select Period 12, which is the last period in the fiscal year, and that has dates of August 1 through August 31. You enter a name for the closing period, such as Close. After you create the new closing period, you now have the original period and the closing period. Both have dates that start on August 1 and end on August 31.

Select fiscal calendars for ledgers, fixed assets, and budget cycles

Fiscal calendars are used with fixed asset depreciation, financial transactions, and budget cycles. When you create a fiscal calendar, you can use it for multiple purposes. You can select a fiscal calendar for a fixed asset book to make it a fixed asset calendar. You can select a fiscal calendar for a ledger to make it a ledger calendar. And you can select a fiscal calendar for a budget cycle to make it a budget calendar. You can use the same fiscal calendar for all of these.

Select the fiscal calendar that you want to use for the ledger for your legal entity in the Ledger form. A fiscal calendar must be selected on the Ledger page for every legal entity. After a fiscal calendar is selected, you can set up period statuses and permissions on the Ledger calendar page for any of the periods that are part of a fiscal year.

Select a fiscal calendar for fixed assets

You can select a fiscal calendar for a fixed asset book, and that fiscal calendar will be used by the fixed assets that use the selected book. You can select from any fiscal calendar that is defined on the Fiscal calendars page.

Define budget cycle time spans

Budget cycles are the length of time during which a budget is used. Budget cycles can include part of a fiscal year or multiple fiscal years, such as a biennial budget cycle of two years or a triennial budget cycle of three years. The budget cycle time span defines the number of periods that are included in the budget cycle. To specify the budget cycle time span, use the Budget cycle time spans page.

Maintain periods for your organization

You can use the Ledger calendar page to view the details of the fiscal calendar, fiscal years, and periods used by your organization. You can also change the status of the periods and select which users can post accounting transactions to periods. For example, at the start of a new period, you might want a group of users to finish posting financial transactions in the previous period, while other groups work only in the new period.

You can find original article here