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

Accounts Payable – Invoice matching and intercompany purchase orders

The purchasing legal entity that is involved in an intercompany trade transaction might be set up to use accounts payable invoice matching. When the Post invoice with discrepancies field in the Accounts payable parameters form is set to Require approval, invoice matching validation will be performed. In this case, the posting requirements for both intercompany trade and accounts payable invoice matching must be met before intercompany vendor invoices can be posted.

The examples in this topic use the following setup for intercompany trade:

  • Fabrikam Purchase is the purchasing legal entity.
  • Fabrikam Sales is the selling legal entity.
  • Customer 4020 exists in Fabrikam Sales.
  • Vendor 3024 exists in Fabrikam Purchase.
  • In Fabrikam Purchase, intercompany information is specified for vendor 3024. Fabrikam Sales is specified as the customer company, and customer 4020 is specified as the customer account that corresponds to the Fabrikam Purchase legal entity.
  • In Fabrikam Sales, intercompany information is specified for customer 4020. Fabrikam Purchase is specified as the vendor company, and vendor 3024 is specified as the vendor account that corresponds to the Fabrikam Sales legal entity.

The examples use the following setup for accounts payable invoice matching for Fabrikam Purchase:

  • On the Accounts payable parameters page, the Enable invoice matching validation option is selected.
  • On the Accounts payable parameters page, the Post invoice with discrepancies field is set to Require approval.
  • The price tolerance percentage for the legal entity is 2 percent.

Example: Price matching and intercompany trade

The net amounts for the intercompany vendor invoice and the intercompany customer invoice must be equal. This requirement overrides any invoice matching approvals or price tolerance percentages that apply. For example, you follow these steps.

  1. In Fabrikam Purchase, create sales order SO888 for customer 4020. Intercompany purchase order ICPO222 is automatically created for vendor 3024 in Fabrikam Purchase, and sales order ICSO888 is automatically created in Fabrikam Sales.
  2. In Fabrikam Sales, register that the items have been received, and post a packing slip. The status of ICSO888 changes to Delivered. The status of ICPO222 changes to Received.
  3. In Fabrikam Sales, perform an invoice update for ICSO888. The unit price is 0.45, and 100 items are updated.
  4. In Fabrikam Purchase, create an invoice for ICPO222. You accidentally change the net price from 45.00 to 54.00. An icon is displayed to indicate that the price exceeds the allowable price tolerance of 2 percent.
  5. On the Invoice matching details page, select the option to approve posting with matching discrepancies. On the Vendor invoice page, click OK. If the vendor invoice was not an intercompany vendor invoice, posting would be successful. However, because you are working with an intercompany vendor invoice, posting is unsuccessful. For intercompany trade, the invoice totals on the intercompany sales order must equal the invoice totals on the corresponding intercompany purchase order. To resolve this issue, you must correct the net price on the invoice by changing the net price back to the default amount, 45.00.

Example: Quantity matching with intercompany trade

The quantities on the intercompany purchase order and the intercompany sales order must be equal. This requirement overrides any invoice matching approvals that apply. This example uses the following additional setup for intercompany trade:

  • In Fabrikam Purchase, the purchase order action policy for vendor 3024 is set up to automatically post both the original customer invoice and the intercompany vendor invoice.

This example uses the following additional setup for accounts payable invoice matching for Fabrikam Purchase:

  • On the Item model groups page for the model group that is used by item B-R14, the Receiving requirements option is selected.
  • The on-hand quantity for item B-R14 is 0 (zero).

For example, you follow these steps.

  1. In Fabrikam Purchase, create sales order SO999 for customer 4020. The order contains one line item: 100 batteries (item B-R14) at a unit price of 1.00 each. Intercompany purchase order ICPO333 is automatically created for vendor 3024 in Fabrikam Purchase, and sales order ICSO999 is automatically created in Fabrikam Sales.
  2. In Fabrikam Sales, perform an invoice update for ICSO999. Posting is unsuccessful, because the item is out of stock and has not yet been received. Therefore, the financial information cannot be updated.
  3. In Fabrikam Sales, register that the items have been received, and post a packing slip for ICSO999. A product receipt for ICPO333 is automatically posted in Fabrikam Purchase. In Fabrikam Purchase, the received quantity for item B-R14 changes to 100.
  4. In Fabrikam Sales, perform an invoice update for ICSO999. Posting is successful in both legal entities. In Fabrikam Purchase, the quantity that is purchased for item B-R14 changes to 100.

You can find original article here