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